aptos-core
aptos-core copied to clipboard
aptos-labs
[Framework] Publicize `account::create_account_if_does_not_exist()`
@davidiw introduced account::create_account_if_does_not_exist() here ( https://github.com/aptos-labs/aptos-core/commit/507791c#diff-ef8a70cd4b03dc7b8b6dfd8306886d480c155211d8c472b59585471e4c60c427 ), but it is private and no other functions depend on it
Publicize the function, a useful helper
⏱️ 13s total CI duration on this PR
| Job | Cumulative Duration | Recent Runs |
|---|---|---|
| permission-check | 4s | 🟥 |
| permission-check | 3s | 🟥 |
| permission-check | 3s | 🟥 |
| permission-check | 3s | 🟥 |
settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io
![trunk-io[bot] avatar](https://avatars.githubusercontent.com/in/120106?v=4 "Published by a pub.dev verified publisher"){kind=small}
I think I didn't want this because there's no other way to create an account at arbitrary addresses. The only way currently is by having the object signer or a private key that maps to a public auth key. By introducing this, we open up a new set of behaviors that isn't well studied.
we open up a new set of behaviors that isn't well studied.
@davidiw The main behavior that this enables is creating an account without erroring out
There are as yet no other short-circuit methods for simply creating an account if it doesn't exist, and I've noticed in conversations/code review with plenty other devs the difficulties of having all the other happy paths in the repo abort if an account exists
This just makes it easier to ensure someone has an account
we open up a new set of behaviors that isn't well studied.
@davidiw The main behavior that this enables is creating an account without erroring out
There are as yet no other short-circuit methods for simply creating an account if it doesn't exist, and I've noticed in conversations/code review with plenty other devs the difficulties of having all the other happy paths in the repo abort if an account exists
This just makes it easier to ensure someone has an account
Examples, please?
Why do people want these accounts to exist?
This becomes even a lesser issue once we get to fungible assets.
Forge is running suite realistic_env_max_load on 52363012063c03ade43b23daa7530037ca8b128d
- Grafana dashboard (auto-refresh)
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Forge is running suite compat on 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d
- Grafana dashboard (auto-refresh)
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
Forge is running suite framework_upgrade on 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d
- Grafana dashboard (auto-refresh)
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
Examples, please?
Why do people want these accounts to exist?
@davidiw
account::Account is required for GUID, txn submission, and auth key rotation
:white_check_mark: Forge suite compat success on 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d
Compatibility test results for 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d (PR)
1. Check liveness of validators at old version: 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411
compatibility::simple-validator-upgrade::liveness-check : committed: 6536.437412988778 txn/s, latency: 4712.84990438247 ms, (p50: 4800 ms, p90: 5400 ms, p99: 7800 ms), latency samples: 251000
2. Upgrading first Validator to new version: 52363012063c03ade43b23daa7530037ca8b128d
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 3362.1148156065933 txn/s, latency: 9274.853322235089 ms, (p50: 9400 ms, p90: 13900 ms, p99: 14200 ms), latency samples: 138160
3. Upgrading rest of first batch to new version: 52363012063c03ade43b23daa7530037ca8b128d
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 3383.95295676215 txn/s, latency: 9172.648356263577 ms, (p50: 9400 ms, p90: 13900 ms, p99: 14200 ms), latency samples: 138100
4. upgrading second batch to new version: 52363012063c03ade43b23daa7530037ca8b128d
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 4674.510686724304 txn/s, latency: 6928.631591602159 ms, (p50: 5400 ms, p90: 13200 ms, p99: 18700 ms), latency samples: 170520
5. check swarm health
Compatibility test for 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d passed
Test Ok
- Grafana dashboard
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
:white_check_mark: Forge suite realistic_env_max_load success on 52363012063c03ade43b23daa7530037ca8b128d
two traffics test: inner traffic : committed: 8087.717512626003 txn/s, latency: 4838.101119059727 ms, (p50: 4800 ms, p90: 6000 ms, p99: 10200 ms), latency samples: 3500260
two traffics test : committed: 100.05371748195063 txn/s, latency: 1797.0190217391305 ms, (p50: 1800 ms, p90: 2000 ms, p99: 2600 ms), latency samples: 1840
Latency breakdown for phase 0: ["QsBatchToPos: max: 0.213, avg: 0.205", "QsPosToProposal: max: 0.228, avg: 0.218", "ConsensusProposalToOrdered: max: 0.429, avg: 0.383", "ConsensusOrderedToCommit: max: 0.365, avg: 0.346", "ConsensusProposalToCommit: max: 0.747, avg: 0.729"]
Max round gap was 1 [limit 4] at version 1756703. Max no progress secs was 5.032381 [limit 15] at version 1756703.
Test Ok
- Grafana dashboard
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
:white_check_mark: Forge suite framework_upgrade success on 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d
Compatibility test results for 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d (PR)
Upgrade the nodes to version: 52363012063c03ade43b23daa7530037ca8b128d
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1336.2101002222855 txn/s, submitted: 1339.5478440196769 txn/s, failed submission: 3.337743797391221 txn/s, expired: 3.337743797391221 txn/s, latency: 2343.840990840966 ms, (p50: 1800 ms, p90: 4500 ms, p99: 7800 ms), latency samples: 120100
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1194.8923568718935 txn/s, submitted: 1197.6261430077302 txn/s, failed submission: 2.7337861358365534 txn/s, expired: 2.7337861358365534 txn/s, latency: 2596.3036796949477 ms, (p50: 1800 ms, p90: 4800 ms, p99: 8000 ms), latency samples: 104900
5. check swarm health
Compatibility test for 3ffe0986b5fe4acb76544ae7ae85d73b91a6a411 ==> 52363012063c03ade43b23daa7530037ca8b128d passed
Upgrade the remaining nodes to version: 52363012063c03ade43b23daa7530037ca8b128d
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1104.19752862975 txn/s, submitted: 1105.2929626859304 txn/s, failed submission: 1.0954340561803075 txn/s, expired: 1.0954340561803075 txn/s, latency: 2704.9827976190477 ms, (p50: 2100 ms, p90: 4700 ms, p99: 8900 ms), latency samples: 100800
Test Ok
- Grafana dashboard
- Humio Logs
- Axiom Logs
- Validator CPU Profile
- Fullnode CPU Profile
- Test runner output
- Test run is land-blocking
Examples, please? Why do people want these accounts to exist?
@davidiw
account::Accountis required for GUID, txn submission, and auth key rotation
What operation are you trying to perform and in which context?
- txn submission -> sponsored transaction? you need apt
- auth key rotation -> who is rotating it?
- GUID -> when? we're moving away from using GUIDs for events in the next couple of releases
we open up a new set of behaviors that isn't well studied.
@davidiw The main behavior that this enables is creating an account without erroring out
There are as yet no other short-circuit methods for simply creating an account if it doesn't exist, and I've noticed in conversations/code review with plenty other devs the difficulties of having all the other happy paths in the repo abort if an account exists
This just makes it easier to ensure someone has an account
Can't people currently call:
account::exists_at(addr)aptos_account::create_account(addr)
The problem is it creates a CoinStore<AptosCoin>
well I'll be damned... you win... @movekevin already exposed the function...