Burn illegal token and Frozen configuration #250
Conversation
… determinations, mainly when publishing packages and executing transactions.
…n signer parameter
| use StarcoinFramework::Config; | ||
| use StarcoinFramework::Signer; |
| strategy: u8, | ||
| exec_delay: u64) { | ||
| let consensus_config = ConsensusConfig::new_consensus_config(uncle_rate_target, | ||
| public entry fun propose_update_consensus_config( |
sources/StdlibUpgradeScripts.move
Outdated
| } | ||
|
|
||
| public entry fun do_upgrade_from_v12_to_v13(sender: signer) { | ||
| CoreAddresses::assert_genesis_address(&sender); |
| const ERR_ADD_CANNOT_BE_CORE_ADDRESS: u64 = 103; | ||
| const ERR_REMOVE_ACCOUNT_FAILED: u64 = 102; | ||
|
|
||
| public entry fun initialize(sender: signer) { |
There was a problem hiding this comment.
这里iniialize不用entry，一般是放在Genesis.move里面
| FrozenConfig::initialize(&sender, frozen_list_v1()); | ||
| } | ||
|
|
||
| public entry fun add_account(sender: signer, account: address) { |
There was a problem hiding this comment.
It's kinda dangerous. The entry function can be called directly in transaction.
…age_txn_prologue_v2 will be called in TransactionManager::prologue, and the freeze assertion decision has been made before it
| StdlibUpgradeScripts::do_upgrade_from_v12_to_v13(&genesis_account); | ||
|
|
||
| // Initialize Frozen strategy | ||
| FrozenConfigStrategy::do_initialize(&association); |
There was a problem hiding this comment.
这个可以直接放到do_upgrade_from_v12_to_v13里面吧
There was a problem hiding this comment.
When doing stdlib upgrading, make sure every vm doing the same work. The balances of accounts when upgrading stdlib could be different according to the upgrading height. In that situation, different node might has different balances, the burning operation might cause inconsistent problem.
| public entry fun upgrade_from_v12_to_v13(sender: signer) { | ||
| do_upgrade_from_v12_to_v13(&sender); | ||
| } | ||
| public fun do_upgrade_from_v12_to_v13(sender: &signer) { |
There was a problem hiding this comment.
We could do a proper initialization when upgrading stdlib, like pushing_new_config then set the address list. Then we could burn the balances in a block triggered by executing a DAO proposal.
| ); | ||
| } | ||
|
|
||
| public fun set_account_list(sender: &signer, frozen_account_list: ACL::ACL) { |
There was a problem hiding this comment.
We can add spec to set_account_list/set_global_frozen to make sure it can be executed properly like the initialize function
| } | ||
|
|
||
| spec initialize { | ||
| aborts_if !Timestamp::is_genesis(); |
There was a problem hiding this comment.
if we try to initializing frozen config through stdlib upgrading, it should not be a genesis block.
| assert!(!ACL::contains(&new_acl, account), Errors::invalid_state(ERR_REMOVE_ACCOUNT_FAILED)); | ||
| } | ||
|
|
||
| public entry fun set_global_frozen(sender: signer, frozen: bool) { |
There was a problem hiding this comment.
It could be better to add spec to each function.
Pull request type
Please check the type of change your PR introduces:
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Other information