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

[AIP-3][Discussion] Governance Multi-Step Proposal #3

Closed
0xchloe opened this issue Nov 18, 2022 · 11 comments
Closed

[AIP-3][Discussion] Governance Multi-Step Proposal #3

0xchloe opened this issue Nov 18, 2022 · 11 comments
Labels

Comments

@0xchloe
Copy link
Contributor

0xchloe commented Nov 18, 2022

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 script script_a. By voting yes on script_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
Screen Shot 2022-11-15 at 12 54 08 PM
When we produce the execution scripts, we start from the last script (let's say it's the xth proposal), hash it, and pass the hash to the x-1th 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:

  • When creating a proposal, the proposer will only pass in the first script in the execution_hash parameter.
  • When voting on a proposal, voting yes / no on the first script indicates that the voter approves / rejects the entire chain of execution scripts.

Resolving Multi-Step Proposals

In our proposed multi-step proposal design, when resolving a multi-step proposal,
Screen Shot 2022-11-15 at 3 17 24 PM

  • 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 the proposal.execution_hash on-chain with the next_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

  • Smart Contracts Security & Audit

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.

  • Validation

We are mostly concerned about two types of validation:

  1. validate that all scripts are present;
  2. validate that executing them one by one in order works (chain and replay are good).

We will support CLI tooling for the above validations.

  • Decentralization & Governance

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

  • publish draft AIP for community feedback.
  • design review and preliminary security review for the multi-step proposal design.

11/22 - 11/30

  • formalize AIP
  • flesh out draft PR, add unit tests, and get the PR landed.
  • deploy Move changes on Devnet.

11/30 - 12/14

  • add CLI support.
  • operational testing.
  • deploy Move changes on Testnet.

12/15 - 12/20

  • e2e testing.
  • potentially deploy Move changes on Mainnet.
@limper89
Copy link

nice

@tie-creator
Copy link

Looking good

@babadura
Copy link

Lets improve tooling

@Nurzhas1
Copy link

would be if you add TL DR at the end

@Mus156
Copy link

Mus156 commented Nov 29, 2022

That's interesting

@wilta2020
Copy link

That's great 👍

@OlyushaVibe
Copy link

Why not? I think is for better!

@VooDoo087
Copy link

Think it should be done!

@sirouk
Copy link

sirouk commented Dec 1, 2022

Very good! I think it should be done too :)

@sherry-x sherry-x changed the title AIP: Governance Multi-Step Proposal [AIP-3][Discussion] Governance Multi-Step Proposal Dec 7, 2022
@mathiyarasu65
Copy link

That is exciting.

@michelle-aptos
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests