-
Notifications
You must be signed in to change notification settings - Fork 98
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
[AIP-3][Discussion] Governance Multi-Step Proposal #3
Labels
Comments
nice |
Looking good |
Lets improve tooling |
would be if you add TL DR at the end |
That's interesting |
That's great 👍 |
Why not? I think is for better! |
Think it should be done! |
Very good! I think it should be done too :) |
sherry-x
changed the title
AIP: Governance Multi-Step Proposal
[AIP-3][Discussion] Governance Multi-Step Proposal
Dec 7, 2022
That is exciting. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
The Aptos on-chain governance is a process by which the Aptos community can govern operations and development of the Aptos blockchain via proposing, voting on, and resolving proposals.
Currently, an on-chain proposal can only contain one script. Because the MoveVM applies changes to the VM at the end of a script, we cannot include changes that are dependent on previous changes in the same script. This means that we oftentimes need multiple scripts to complete an upgrade.
When we have any upgrade that involves multiple scripts, we need to make multiple single-step proposals, have voters vote on each of them, and resolve each of them manually. We would like to simplify this process by supporting multi-step proposals - this will allow multiple scripts within one on-chain proposal and will execute the scripts in order if the proposal passes.
Motivation
With multi-step proposals, we will be able to create an on-chain proposal that contains multiple steps, have voters vote on it, and execute all scripts in order at once. This will save effort from the community, as well as enforce that the scripts will be executed in order.
Alternatives Considered
Alternative Solution I: Keeping the Status Quo
Currently, proposing an upgrade with multiple scripts using single-step proposals is time-consuming, manual and likely error-prone if only part of the scripts get executed. We think adding support for multi-step proposals is better because it will save time for proposers, voters, resolvers, and ensures that we execute the steps in the right order.
Alternative Solution II: Making a change to the MoveVM
Because the MoveVM applies all changes at the end of the script, we cannot include all upgrades within one single script when some changes are dependent on the other ones in the same script.
We could make a VM-level change to apply changes to the VM at the end of each transaction - this would allow executing all upgrades within one single script. However, it will be a much larger change that will take more than multiple months and affects more parts of the system. We think the smart contracts change essentially achieves the same thing, and is simpler than a VM-level change.
Specification
To support multi-step proposals, we introduce the concept of a chain of scripts. The voter approves / rejects the entire chain of scripts by voting yes / no on the first script of the chain. There is no partial yes / no.
For example, if we have a multi-step proposal that contains
<script_a, script_b, script_c, script_d>
, the user will only vote on the first scriptscript_a
. By voting yes onscript_a
, they say yes to the entire chain of scripts<script_a, script_b, script_c, script_d>
.When a multi-step proposal passes, we will use CLI to resolve the chain of scripts sequentially.
Chain of Scripts
When we produce the execution scripts, we start from the last script (let's say it's the
x
th proposal), hash it, and pass the hash to thex-1
th proposal. The on-chain proposal will only contain the first script, but the content and order of the entire chain is implicitly hashed in the first script. We will provide CLI toolings for generating the chain of scripts and verifying that all scripts are present and are in the right order.Creating and Voting on Multi-Step Proposals
The flow will mostly stay the same for creating and voting on proposals:
execution_hash
parameter.Resolving Multi-Step Proposals
In our proposed multi-step proposal design, when resolving a multi-step proposal,
aptos_governance::resolve_multi_step_proposal()
returns a signer and replaces the current execution hash with the hash of the next script.voting::resolve()
checks that the hash of the current script is the same as the proposal’s current execution hash, update theproposal.execution_hash
on-chain with thenext_execution_hash
, and emits an event for the current execution hash.voting::resolve()
marks that the proposal is resolved if the current script is the last script in the chain of scripts.Security
The implementation will go through security audit with a respectable third-party audit firm to ensure the safety and correctness of the code and the operations.
We are mostly concerned about two types of validation:
We will support CLI tooling for the above validations.
This proposal changes the mechanism of what the content of a proposal includes (multiple scripts vs. single scripts), and does not change the powers of the on-chain governance. There is no impact on decentralization or governance abilities.
Tooling
We will add CLI and governance UI support for creating, voting on, and resolving multi-step proposals.
Reference Implementation
Draft PR:
aptos-labs/aptos-core#5445
Risks and Drawbacks
Decentralization - no impact or changes.
Security - the added governance code will go through strict testing and auditing.
Tooling - CLI support only covers Aptos governance but the multi-step mechanism can be reused for general-purpose DAO/governance. In the near future, the Aptos team and community can improve CLI/tooling to be more generic.
Tentative Implementation Timeline
11/07 - 11/22
11/22 - 11/30
11/30 - 12/14
12/15 - 12/20
The text was updated successfully, but these errors were encountered: