Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Spec] Add the initial specs for ed25519 and multi_ed25519 #5677

Merged
merged 1 commit into from
Dec 5, 2022

Conversation

junkil-park
Copy link
Contributor

@junkil-park junkil-park commented Nov 22, 2022

Description

  • modeled the native functions with uninterpreted functions
  • added functional specifications
  • the axioms of the uninterpreted functions will be added when needed.

Test Plan

aptos move prove

@movekevin
Copy link
Contributor

Can you remove output.bpl?

@junkil-park
Copy link
Contributor Author

Can you remove output.bpl?

I just removed it. Good call!


spec new_validated_public_key_from_bytes(bytes: vector<u8>): Option<ValidatedPublicKey> {
aborts_if false;
let cond = len(bytes) % INDIVIDUAL_PUBLIC_KEY_NUM_BYTES == THRESHOLD_SIZE_BYTES
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come you don't do the length / INDIVIDUAL_PUBLIC_KEY_NUM_BYTES > MAX_NUMBER_OF_PUBLIC_KEYS check here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alinush , cond is here to model the condition in this line: https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-stdlib/sources/cryptography/multi_ed25519.move#L123

Does the Move function new_validated_public_key_from_bytes actually need the additional check you're mentioning?

Copy link
Contributor

@alinush alinush Nov 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see: That check is done in the public_key_validate_internal native, which new_validated_public_key_from_bytes calls. I guess that's why I didn't replicate it.

A bit confusing now reading my own code 🤦 ...

Would you mind adding a comment at line 123 (which you linked to) that says:

// Note that `public_key_validate_internal` will check that `vector::length(&bytes) / INDIVIDUAL_PUBLIC_KEY_NUM_BYTES <= MAX_NUMBER_OF_PUBLIC_KEYS`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Added the comment.

Copy link
Contributor

@alinush alinush Dec 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @junkil-park, I was taking another look, and now I noticed that you added the length / INDIVIDUAL_PUBLIC_KEY_NUM_BYTES > MAX_NUMBER_OF_PUBLIC_KEYS check here too.

But, as per my new comment below, this abort will never happen because the native called by new_validated_public_key_from_bytes would only returns false, not abort.

- modeled the native functions with uninterpreted functions
- added functional specifications
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 5, 2022

✅ Forge suite land_blocking success on 594878f1b0f389b5cc981953149259fe212cf804

performance benchmark with full nodes : 6630 TPS, 5971 ms latency, 9600 ms p99 latency,(!) expired 440 out of 2831720 txns
Test Ok

@github-actions
Copy link
Contributor

github-actions bot commented Dec 5, 2022

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 594878f1b0f389b5cc981953149259fe212cf804

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 594878f1b0f389b5cc981953149259fe212cf804 (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7628 TPS, 5203 ms latency, 7000 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 594878f1b0f389b5cc981953149259fe212cf804
compatibility::simple-validator-upgrade::single-validator-upgrade : 4789 TPS, 8217 ms latency, 11400 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 594878f1b0f389b5cc981953149259fe212cf804
compatibility::simple-validator-upgrade::half-validator-upgrade : 5102 TPS, 7977 ms latency, 10300 ms p99 latency,no expired txns
4. upgrading second batch to new version: 594878f1b0f389b5cc981953149259fe212cf804
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6744 TPS, 5789 ms latency, 9500 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 594878f1b0f389b5cc981953149259fe212cf804 passed
Test Ok

@junkil-park junkil-park merged commit 621f2c9 into main Dec 5, 2022
@junkil-park junkil-park deleted the jpark/spec-ed25519 branch December 5, 2022 10:05
@Markuze Markuze mentioned this pull request Dec 5, 2022
pragma opaque;
aborts_if len(bytes) / INDIVIDUAL_PUBLIC_KEY_NUM_BYTES > MAX_NUMBER_OF_PUBLIC_KEYS;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @junkil-park, I see this says that the native aborts upon this condition, but the native never aborts.
See

Copy link
Contributor

@alinush alinush Dec 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my initial reply in the discussion above made it seem like the native aborts upon this condition, but it merely returns false.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

areshand pushed a commit to areshand/aptos-core-1 that referenced this pull request Dec 18, 2022
…-labs#5677)

- modeled the native functions with uninterpreted functions
- added functional specifications
@Markuze Markuze mentioned this pull request Dec 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants