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] Added specs for module aggregator & aggregator_factory & optional_aggregator & staking_config & version & event & guid & timestamp #5653

Merged
merged 23 commits into from
Dec 8, 2022

Conversation

0xOutOfGas
Copy link
Contributor

Description

This is a part of spec work for Aptos Framework from MoveBit, we updated below files/modules in this PR:

aggregator/aggregator.spec.move
aggregator/aggregator_factory.spec.move
aggregator/optional_aggregator.spec.move
configs/staking_config.spec.move
configs/version.spec.move
event.spec.move
guid.spec.move
timestamp.spec.move

Test Plan

aptos move prove --package-dir ./aptos-framework

@@ -6,20 +6,24 @@ spec aptos_framework::aggregator {
spec add {
// TODO: temporary mockup.
pragma opaque;
aborts_if false;
Copy link
Contributor

Choose a reason for hiding this comment

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

This native function can actually abort. Please refer to the comment in aggregator.move. (cc: @georgemitenkov )

Copy link
Contributor

Choose a reason for hiding this comment

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

Remove aborts if false does not affect the validation.

Copy link
Contributor

@junkil-park junkil-park Nov 28, 2022

Choose a reason for hiding this comment

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

Remove aborts if false does not affect the validation.

I didn't get this. Could you elaborate what you mean?

According the comment in aggregator.move, this function "Aborts on overflowing the limit."

}

spec sub {
// TODO: temporary mockup.
pragma opaque;
aborts_if false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as the above. This native function can actually abort. Please refer to the comment in aggregator.move.

Copy link
Contributor

Choose a reason for hiding this comment

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

Already updated.

Copy link
Contributor

Choose a reason for hiding this comment

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

What is updated?

According to the comment in the code, this function "Aborts on going below zero.".

Copy link
Contributor

Choose a reason for hiding this comment

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

The specs of add and sub have been redone.

}

spec read {
// TODO: temporary mockup.
pragma opaque;
aborts_if false;
Copy link
Contributor

Choose a reason for hiding this comment

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

@georgemitenkov , can there be any cases where read and destroy may potentially abort?

Copy link
Contributor

Choose a reason for hiding this comment

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

destroy never aborts, and so should read. Say you have an aggregator with an overflow limit of 10. And some transaction does this:

a = Aggregator(limit=10) // actual storage value is 5 already, but this transaction doesn't know
a.add(7)
a.read() // aborts the transaction since we read 5+7 > 10

So technically read aborts because it checks if previous deltas made sense. At the same time,

a = Aggregator(limit=10) // actual storage value is 5 already, but this transaction doesn't know
a.add(7)

equally aborts because at the end of the transaction we check if it should have been aborted (e.g. in sequential execution this means read the value, in parallel execution it is a bit more convoluted).

So, in my opinion, this shows that read never aborts, but rather catches an abort in add/sub. Not sure how you would qualify this for the prover?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at native implementation, we can abort if aggregator value is not found in storage, do we count this is as well? Technically should never happen...

Copy link
Contributor

Choose a reason for hiding this comment

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

@georgemitenkov @junkil-park read never aborts. But destroy indeed abort.

    ┌─ aptos-framework/sources/aggregator/optional_aggregator.move:105:9
    │
105 │         aggregator::destroy(aggregator);
    │         ------------------------------- abort happened here with code 0x0
    │
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:100: switch_to_integer_and_zero_out
    =         optional_aggregator =
    =           &optional_aggregator.OptionalAggregator{
    =             aggregator =
    =               option.Option{
    =                 vec =
    =                   vector{
    =                     aggregator.Aggregator{
    =                       handle = 0x6784,
    =                       key = 0x18be,
    =                       limit = 18467u128}}},
    =             integer = option.Option{vec = vector{}}}
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:103: destroy_optional_integer
    =     at <internal>:1
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:103: destroy_optional_integer
    =         optional_aggregator =
    =           &optional_aggregator.OptionalAggregator{
    =             aggregator = option.Option{vec = vector{}},
    =             integer = option.Option{vec = vector{}}}
    =         aggregator =
    =           aggregator.Aggregator{
    =             handle = 0x6784,
    =             key = 0x18be,
    =             limit = 18467u128}
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:104: destroy_optional_integer
    =     at aptos-framework/sources/aggregator/aggregator.move:80: limit
    =         aggregator =
    =           aggregator.Aggregator{
    =             handle = 0x6784,
    =             key = 0x18be,
    =             limit = 18467u128}
    =     at aptos-framework/sources/aggregator/aggregator.move:81: limit
    =         result = 18467u128
    =     at aptos-framework/sources/aggregator/aggregator.move:82: limit
    =         limit = 18467u128
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:105: switch_to_integer_and_zero_out
    =     at <internal>:1
    =     at aptos-framework/sources/aggregator/optional_aggregator.move:105: switch_to_integer_and_zero_out
    =         ABORTED

{
  "Error": "Move Prover failed: exiting with verification errors"
}

Copy link
Contributor

Choose a reason for hiding this comment

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

@qpb8023 I am a bit confused with the error log and the inputs that lead to abort -- why there is a line ...optional_aggregator.move:103: destroy_optional_integer?

Is it possible to reproduce an error? This abort is not expected.

Copy link
Contributor

Choose a reason for hiding this comment

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

'not implemented: Not yet supported constant vector type: Vector(Primitive(U64))'

This seems a separate issue. Do you still have the same problem when using the latest move-cli?

Copy link
Contributor

Choose a reason for hiding this comment

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

@junkil-park The code you gave will still abort. By using the latest move cli.

Copy link
Contributor

Choose a reason for hiding this comment

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

@rahxephon89, we support the constant vector type like Vector(Primitive(U64)), right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just to unblock this PR from the constant vector issue, can you use this spec and proceed?

spec destroy(aggregator: Aggregator) {
        pragma opaque;
        // TODO: this aborts_if condition is a temporary mockup, which needs to be refined.
        aborts_if false;
    }

Copy link
Contributor

Choose a reason for hiding this comment

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

@junkil-park I have solved this.

aborts_if exists<SetVersionCapability>(@aptos_framework);
}

/// Only for test
Copy link
Contributor

Choose a reason for hiding this comment

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

Test functions don't need to be specified. Could you remove this spec?

Copy link
Contributor

Choose a reason for hiding this comment

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

Removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we add spec for initialize_for_test and set verify = false, because we opened aborts_if_is_strict in spec module, if we remove spec for initialize_for_test, prover will not let it pass.

spec aptos_framework::version {
    spec module {
        pragma verify = true;
        pragma aborts_if_is_strict;
    }

Two solutions from us:
1 keep the spec and add a comment like "no need to add spec for test functions, just because the module turns on aborts_if_is_strict".(which we preferred)
2 remove the spec, and turn aborts_if_is_strict to false.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK. The current way looks fine.

Copy link
Contributor

@junkil-park junkil-park left a comment

Choose a reason for hiding this comment

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

I left a few question and comment. Other than that, it looks good to me.

@junkil-park
Copy link
Contributor

There is a CI check failure: https://github.com/aptos-labs/aptos-core/actions/runs/3645474643/jobs/6155656855#step:6:864. I am not sure why.

Could you try to rebase it and regenerate the doc (cargo test -p framework) if you didn't recently? Let's see if that resolves the error.

@rahxephon89 rahxephon89 self-requested a review December 8, 2022 17:38
@junkil-park junkil-park enabled auto-merge (squash) December 8, 2022 17:39
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2022

✅ Forge suite land_blocking success on 3756a3b65315371cd0ab54274bb939a0267313ea

performance benchmark with full nodes : 6718 TPS, 5907 ms latency, 10800 ms p99 latency,(!) expired 80 out of 2869080 txns
Test Ok

@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2022

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 3756a3b65315371cd0ab54274bb939a0267313ea

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 3756a3b65315371cd0ab54274bb939a0267313ea (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7172 TPS, 5418 ms latency, 7700 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 3756a3b65315371cd0ab54274bb939a0267313ea
compatibility::simple-validator-upgrade::single-validator-upgrade : 4855 TPS, 8777 ms latency, 11800 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 3756a3b65315371cd0ab54274bb939a0267313ea
compatibility::simple-validator-upgrade::half-validator-upgrade : 4692 TPS, 8628 ms latency, 11200 ms p99 latency,no expired txns
4. upgrading second batch to new version: 3756a3b65315371cd0ab54274bb939a0267313ea
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6406 TPS, 6114 ms latency, 10700 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 3756a3b65315371cd0ab54274bb939a0267313ea passed
Test Ok

@junkil-park junkil-park merged commit cc19be9 into aptos-labs:main Dec 8, 2022
areshand pushed a commit to areshand/aptos-core-1 that referenced this pull request Dec 18, 2022
…nal_aggregator & staking_config & version & event & guid & timestamp (aptos-labs#5653)

* add aggregator_factory & optional_aggregator.move spec

* Updated specs for module event & guid & timestamp & staking_config & version.

* Documentation updated.

* add ensures for sub_integer & add_integer function

* replace tab to spaces

* remove add & sub aborts_if false

* update aggregator.spec.move

* remove version.move test fun spec

* make fun initialize_for_test verify false

* [spec] added comments for test functions

* Updated aggregator.move spec

Co-authored-by: tiutiutiu <qiu971009@gmail.com>
Co-authored-by: yoyoping <zhangping_ymd@outlook.com>
@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.

6 participants