From 1d63e3366550bda33af5548848c047c190c1c5c9 Mon Sep 17 00:00:00 2001 From: Richard Melkonian Date: Wed, 6 Nov 2024 09:49:47 +0100 Subject: [PATCH 1/8] feat: aptos-governance for Goverened Gas Pool --- MIP/mip-0/README.md | 113 +++++++++++++++++++++++++++++++++----------- 1 file changed, 86 insertions(+), 27 deletions(-) diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md index 614b41bd..ee2e3806 100644 --- a/MIP/mip-0/README.md +++ b/MIP/mip-0/README.md @@ -1,60 +1,119 @@ -# MIP-0: MIPs -- **Description**: Movement Improvement Proposals standardize and formalize specifications for Movement technologies. -- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) -- **Desiderata**: [MD-0](../MD/md-0) +# MIP-\: use `aptos_governance` for Goverened Gas Pool +- **Description**: ???? +- **Authors**: [Richard Melkonian](mailto:richard@movementlabs.xyz) ## Abstract -Movement Improvement Proposals (MIPs) serve as a mechanism to propose, discuss, and adopt changes or enhancements to Movement technologies. By providing a standardized and formalized structure for these proposals, MIPs ensure that proposed improvements are well-defined, transparent, and accessible to the wider community. +The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to be subject to onchain governance by a governing body that holds the +`$L2-MOVE` token. In [MIP-44] governance mechanisms and roles are proposed, such as `Proposers` and `Executors` so that the collected gas can be used +for the good of the network. + +The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid +directly to attestors as `$L1-MOVE` for rewards. + +To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. ## Motivation -Movement technologies continually evolve, and there's a need to ensure that the process of proposing and adopting changes is both organized and standardized. By establishing MIPs, we aim to facilitate the introduction of new features or improvements, making sure they are well-vetted, discussed, and documented. This ensures the integrity of Movement technologies, making it easier for third parties to adopt and adapt to these changes. +This MIP proposes an implementation of the governance mechanism proposed in [MIP-44] by using the `aptos_governance.move` module. We think this has several benefits. +1. `aptos_governance.move` is fully audited and battle tested. +2. `aptos_governance.move` is currently in use on the Aptos Blockchain. +3. Using aptos governance prepares us for extendeding it and using it for future proposals to upgrade or migrate the network, this will be a fairly common necessity post-mainnet. +4. It strenghtens the utility of `$L2-MOVE` as this becomes the governance token. ## Specification -A Movement Improvement Proposal (MIP) is a design document that provides information to the Movement community, describing a new feature or improvement for Movement technologies. - -- **Structure**: Each MIP must adhere to the given template, which requires details like title, description, author, status, and more. A MIP also includes sections like Abstract, Motivation, Specification, Reference Implementation, Verification, Errata, and Appendix. +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +##### 1. Fix the Potential Supply + +As described in the [Abstract](#abstract), the sum of the token supply of `$L1MOVE` and `$L2MOVE` is equal to `MOVE_MAX`. Since the bridge is the sole point of creation (or release) of `$L2MOVE` token, the L2 contract MUST monitor the `$L2MOVE` supply. The L2 bridge contract MUST not release more `$L2MOVE` than the maximum supply `MOVE_MAX`. + +##### 2. Native Bridge rate limitation + +The total amount of bridge transfers should be rate limited to $(X, T)$ where $X$ is the maximum transferable amount per time period $T$. I.e. the bridge should not allow more than $X$ total transaction value in any $T$ period. + +To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. - - An md-template is provided in the [MIP Repository](https://github.com/movemntdev/MIP) which further specifies this structure. This MIP is an example of said structure. - -- **Lifecycle**: An MIP starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MIP can also be deprecated if it becomes obsolete. -- **Storage**: MIPs should be stored in the MIPs directory at [MIP Repository](https://github.com/movemntdev/MIP). -- **Definitions** : Provide definitions that you think will empower the reader to quickly dive into the topic. +##### 3. Relayer key protection + +The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. + +[This article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7) describes some of the considerations that have to be taken into account: + + **Multisigs**: + > It’s likely that the bridge is controlled by one or more multisigs —wallets that require multiple individuals to sign before a transaction is executed. Multisigs add an element of security by ensuring that a single signer can’t control the bridge. Multisigs might be used to enable the bridge contracts to be upgraded or paused. While multisigs are an essential security control for bridges, they are not foolproof and require proper management. In fact multisigs have been targeted in some major bridge exploits. + +**Contract Exploits**: +> Multisigs are implemented as smart contracts and are thus potentially vulnerable to exploits. Many of the popular multisig contracts have been used to store billions in assets over time and are somewhat battle tested. Nonetheless, these contracts do represent additional attack surface. + +**Signers are People**: +> Multisigs are controlled by a group of signers; you must trust that the private keys of those signers are kept secure. Any individual that is a singer on a multisig must be trusted to not be an adversary of course, but also must be trusted to adhere to basic security practices. Multisig signers are ripe targets for phishing and malware attacks. ## Reference Implementation -A reference implementation or a sample MIP following the MIP template can be provided to guide potential proposers. This MIP (MIP-0) serves as a practical example, aiding in understanding the format and expectations. + ## Verification -1. **Correctness**: Each MIP must convincingly demonstrate its correctness. +##### 1. Fix the Potential Supply + +Since the maximal released supply of `$L1MOVE` is `MOVE_MAX` the maximum *Potential Supply* (of the sum of the supply of `$L1MOVE` and `$L2MOVE`) is 2 $\times$ `MOVE_MAX`, even in the case of a compromised relayer and a maximum exploit. -This MIP is correct insofar as it uses a structure established by Ethereum for Improvement Proposals which has hitherto been successful. +##### 2. Native Bridge rate limitation -2. **Security Implications**: Each MIP should be evaluated for any potential security risks it might introduce to Movement technologies. -The primary security concern associated with this MIP is the exposure of proprietary techologies or information via the ill-advised formation of an MIP which the MIP process might encourage. +Eigenlayer AVS does suggest a similar model and provides the following Definition on Strong Economic Security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf): -3. **Performance Impacts**: The implications of the proposal on system performance should be analyzed. +> *Formal Definition of Strong Cryptoeconomic Security* +If [a bridge] acquires more [cryptoeconomic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong cryptoeconomic security, i.e.
+>         *[Economic]-security ≥ Harm-from-corruption [..] in $T_{redeem}$ slots* -The primarry performance concern associated with this MIP is its potential for overuse. Only specifications that are non-trivial and very high-quality should be composed as MIPs. +> [..] consider a [..] bridge [..] for a rollup, which has a $(X, T)$-rate-limit [..]. Now if [$T + +Needs discussion. + +--- ## Errata -Post-publication corrections, if any, to the MIPs should be documented in this section. This ensures transparency and provides readers with accurate and up-to-date information. ## Appendix -The Appendix should contain references and notes related to the MIP. Materials referenced in the MIP should be marked with specific labels (e.g., ⟨R1⟩) for easy tracking and understanding. + +### A1 +Nothing important here. + +--- +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 7f34b59751571585fd5bbfc190765c10ec555801 Mon Sep 17 00:00:00 2001 From: Richard Melkonian Date: Wed, 6 Nov 2024 09:58:47 +0100 Subject: [PATCH 2/8] update: improve language --- MIP/mip-0/README.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md index ee2e3806..bae2d62f 100644 --- a/MIP/mip-0/README.md +++ b/MIP/mip-0/README.md @@ -9,7 +9,8 @@ The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to b for the good of the network. The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid -directly to attestors as `$L1-MOVE` for rewards. +directly to attestors as `$L1-MOVE` for rewards. For all these activities a dispersal of funds is required, this MIP proposes concrete ways to manage dispersal events +in a safe immutable and secure manner. To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. @@ -36,7 +37,6 @@ The total amount of bridge transfers should be rate limited to $(X, T)$ where $X To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. - ##### 3. Relayer key protection The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. @@ -103,16 +103,15 @@ Multisignature approaches are common praxis, for example see [MIP-21](https://gi Needs discussion. --- +## Reference Implementation + +The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. ## Errata ## Appendix - -### A1 -Nothing important here. - --- ## Copyright From 77bc60c7e10c63ab9d97d73b24a58cdc7fc2f99c Mon Sep 17 00:00:00 2001 From: Richard Melkonian Date: Wed, 6 Nov 2024 10:09:10 +0100 Subject: [PATCH 3/8] remove: ref --- MIP/mip-0/README.md | 168 +++++++++++++++++++++++++------------------- 1 file changed, 94 insertions(+), 74 deletions(-) diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md index bae2d62f..c62a92bb 100644 --- a/MIP/mip-0/README.md +++ b/MIP/mip-0/README.md @@ -26,86 +26,106 @@ This MIP proposes an implementation of the governance mechanism proposed in [MIP The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. -##### 1. Fix the Potential Supply - -As described in the [Abstract](#abstract), the sum of the token supply of `$L1MOVE` and `$L2MOVE` is equal to `MOVE_MAX`. Since the bridge is the sole point of creation (or release) of `$L2MOVE` token, the L2 contract MUST monitor the `$L2MOVE` supply. The L2 bridge contract MUST not release more `$L2MOVE` than the maximum supply `MOVE_MAX`. - -##### 2. Native Bridge rate limitation - -The total amount of bridge transfers should be rate limited to $(X, T)$ where $X$ is the maximum transferable amount per time period $T$. I.e. the bridge should not allow more than $X$ total transaction value in any $T$ period. - -To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. - - -##### 3. Relayer key protection - -The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. - -[This article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7) describes some of the considerations that have to be taken into account: - - **Multisigs**: - > It’s likely that the bridge is controlled by one or more multisigs —wallets that require multiple individuals to sign before a transaction is executed. Multisigs add an element of security by ensuring that a single signer can’t control the bridge. Multisigs might be used to enable the bridge contracts to be upgraded or paused. While multisigs are an essential security control for bridges, they are not foolproof and require proper management. In fact multisigs have been targeted in some major bridge exploits. - -**Contract Exploits**: -> Multisigs are implemented as smart contracts and are thus potentially vulnerable to exploits. Many of the popular multisig contracts have been used to store billions in assets over time and are somewhat battle tested. Nonetheless, these contracts do represent additional attack surface. - -**Signers are People**: -> Multisigs are controlled by a group of signers; you must trust that the private keys of those signers are kept secure. Any individual that is a singer on a multisig must be trusted to not be an adversary of course, but also must be trusted to adhere to basic security practices. Multisig signers are ripe targets for phishing and malware attacks. - ## Reference Implementation - +```rust +//pseudocode +module GovernedGasPool::goverened_gas_pool { + use aptos_framework::aptos_coin::AptosCoin; + use aptos_framework::coin; + use aptos_framework::signer; + use aptos_framework::aptos_governance; + use aptos_framework::aptos_governance::{self, GovernanceProposal}; + use aptos_std::vector; + use aptos_std::option::{self, Option}; + + // Address of the governance framework module + const GOVERNANCE_ADDRESS: address = @0x1; + + struct GovernedPool has key { + funds: coin::Coin, // holds the pool of funds in AptosCoin + passed_proposals: vector::Vector, // list of proposals that passed governance + admin: address // address with permission to execute proposals + } + + struct DispersalAction has copy, drop, store { + recipient: address, + amount: u64 + } + + struct Proposal has key { + id: u64, + dispersal_action: Option, // Only one type of action at a time + executed: bool, + } + + /// Initialize the Governed Pool + public fun initialize_governed_pool(admin: &signer, authorized_admin: address): address { + let governed_pool = GovernedPool { + funds: coin::zero(), + passed_proposals: vector::empty(), + admin: authorized_admin + }; + let addr = signer::address_of(admin); + move_to(admin, governed_pool); + addr + } + + /// Add a proposal that has passed governance + /// Only callable by the governance module at address 0x1 + public fun add_passed_proposal( + pool: &mut GovernedPool, + governance_signer: &signer, + id: u64, + dispersal_action: DispersalAction + ) { + // Ensure only the governance framework can call this function + assert!(signer::address_of(governance_signer) == GOVERNANCE_ADDRESS, 1); + + // Verify that the proposal is approved in aptos_governance + assert!(aptos_governance::is_proposal_approved(id), 2); + + let proposal = Proposal { + id, + dispersal_action: option::some(dispersal_action), + executed: false, + }; + vector::push_back(&mut pool.passed_proposals, proposal); + } + + /// Execute a proposal that has been approved by governance + /// Only callable by the designated admin + public fun execute_passed_proposal(pool: &mut GovernedPool, executor: &signer, proposal_id: u64) { + // Ensure only the authorized admin can call this function + assert!(signer::address_of(executor) == pool.admin, 2); + + let proposal_index = find_proposal(&pool.passed_proposals, proposal_id); + let proposal = &mut vector::borrow_mut(&mut pool.passed_proposals, proposal_index); + + // Ensure the proposal hasn't already been executed + assert!(!proposal.executed, 3); + + // Execute the dispersal action if present + if (option::is_some(&proposal.dispersal_action)) { + let action = option::borrow(&proposal.dispersal_action).unwrap(); + let amount = action.amount; + assert!(amount <= coin::value(&pool.funds), 4); // Ensure pool has sufficient funds + coin::withdraw(&mut pool.funds, amount); + coin::deposit(&signer::create(action.recipient), amount); + }; + + proposal.executed = true; + } +} +``` + +Notice the call : +`assert!(aptos_governance::is_proposal_approved(id), 2);` ## Verification -##### 1. Fix the Potential Supply - -Since the maximal released supply of `$L1MOVE` is `MOVE_MAX` the maximum *Potential Supply* (of the sum of the supply of `$L1MOVE` and `$L2MOVE`) is 2 $\times$ `MOVE_MAX`, even in the case of a compromised relayer and a maximum exploit. - -##### 2. Native Bridge rate limitation - - -Eigenlayer AVS does suggest a similar model and provides the following Definition on Strong Economic Security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf): - -> *Formal Definition of Strong Cryptoeconomic Security* -If [a bridge] acquires more [cryptoeconomic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong cryptoeconomic security, i.e.
->         *[Economic]-security ≥ Harm-from-corruption [..] in $T_{redeem}$ slots* - -> [..] consider a [..] bridge [..] for a rollup, which has a $(X, T)$-rate-limit [..]. Now if [$T - -Needs discussion. - ---- -## Reference Implementation - -The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. ## Errata From f9b8555be9c6c8e68bebb41eface616f85ab21ed Mon Sep 17 00:00:00 2001 From: apenzk Date: Tue, 12 Nov 2024 10:26:46 +0100 Subject: [PATCH 4/8] Revert "remove: ref" This reverts commit 77bc60c7e10c63ab9d97d73b24a58cdc7fc2f99c. --- MIP/mip-0/README.md | 168 +++++++++++++++++++------------------------- 1 file changed, 74 insertions(+), 94 deletions(-) diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md index c62a92bb..bae2d62f 100644 --- a/MIP/mip-0/README.md +++ b/MIP/mip-0/README.md @@ -26,106 +26,86 @@ This MIP proposes an implementation of the governance mechanism proposed in [MIP The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. +##### 1. Fix the Potential Supply + +As described in the [Abstract](#abstract), the sum of the token supply of `$L1MOVE` and `$L2MOVE` is equal to `MOVE_MAX`. Since the bridge is the sole point of creation (or release) of `$L2MOVE` token, the L2 contract MUST monitor the `$L2MOVE` supply. The L2 bridge contract MUST not release more `$L2MOVE` than the maximum supply `MOVE_MAX`. + +##### 2. Native Bridge rate limitation + +The total amount of bridge transfers should be rate limited to $(X, T)$ where $X$ is the maximum transferable amount per time period $T$. I.e. the bridge should not allow more than $X$ total transaction value in any $T$ period. + +To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. + + +##### 3. Relayer key protection + +The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. + +[This article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7) describes some of the considerations that have to be taken into account: + + **Multisigs**: + > It’s likely that the bridge is controlled by one or more multisigs —wallets that require multiple individuals to sign before a transaction is executed. Multisigs add an element of security by ensuring that a single signer can’t control the bridge. Multisigs might be used to enable the bridge contracts to be upgraded or paused. While multisigs are an essential security control for bridges, they are not foolproof and require proper management. In fact multisigs have been targeted in some major bridge exploits. + +**Contract Exploits**: +> Multisigs are implemented as smart contracts and are thus potentially vulnerable to exploits. Many of the popular multisig contracts have been used to store billions in assets over time and are somewhat battle tested. Nonetheless, these contracts do represent additional attack surface. + +**Signers are People**: +> Multisigs are controlled by a group of signers; you must trust that the private keys of those signers are kept secure. Any individual that is a singer on a multisig must be trusted to not be an adversary of course, but also must be trusted to adhere to basic security practices. Multisig signers are ripe targets for phishing and malware attacks. + ## Reference Implementation -The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. + ## Verification +##### 1. Fix the Potential Supply + +Since the maximal released supply of `$L1MOVE` is `MOVE_MAX` the maximum *Potential Supply* (of the sum of the supply of `$L1MOVE` and `$L2MOVE`) is 2 $\times$ `MOVE_MAX`, even in the case of a compromised relayer and a maximum exploit. + +##### 2. Native Bridge rate limitation + + +Eigenlayer AVS does suggest a similar model and provides the following Definition on Strong Economic Security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf): + +> *Formal Definition of Strong Cryptoeconomic Security* +If [a bridge] acquires more [cryptoeconomic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong cryptoeconomic security, i.e.
+>         *[Economic]-security ≥ Harm-from-corruption [..] in $T_{redeem}$ slots* + +> [..] consider a [..] bridge [..] for a rollup, which has a $(X, T)$-rate-limit [..]. Now if [$T + +Needs discussion. + +--- +## Reference Implementation + +The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. ## Errata From f5bc59b89f0a9d8ba02f12ce210c1bb1aacba352 Mon Sep 17 00:00:00 2001 From: apenzk Date: Tue, 12 Nov 2024 10:29:00 +0100 Subject: [PATCH 5/8] add back README file --- .github/CODEOWNERS | 2 + MIP/mip-48/README.md | 138 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+) create mode 100644 MIP/mip-48/README.md diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 3d5e5fd6..7a02783c 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -14,3 +14,5 @@ /MIP/mip15/ @l-monninger @apenzk /MD/md-15/ @l-monninger @apenzk + +/MIP/mip48/ @0xmovses \ No newline at end of file diff --git a/MIP/mip-48/README.md b/MIP/mip-48/README.md new file mode 100644 index 00000000..110a56a0 --- /dev/null +++ b/MIP/mip-48/README.md @@ -0,0 +1,138 @@ +# MIP-48: `aptos_governance` for Goverened Gas Pool +- **Description**: Use the `aptos_governance` framework for the Governed Gas Pool +- **Authors**: [Richard Melkonian](mailto:richard@movementlabs.xyz) + +## Abstract + +The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to be subject to onchain governance by a governing body that holds the +`$L2-MOVE` token. In [MIP-44] governance mechanisms and roles are proposed, such as `Proposers` and `Executors` so that the collected gas can be used +for the good of the network. + +The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid +directly to attestors as `$L1-MOVE` for rewards. For all these activities a dispersal of funds is required, this MIP proposes concrete ways to manage dispersal events +in a safe immutable and secure manner. + +To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. + +## Motivation + +This MIP proposes an implementation of the governance mechanism proposed in [MIP-44] by using the `aptos_governance.move` module. We think this has several benefits. +1. `aptos_governance.move` is fully audited and battle tested. +2. `aptos_governance.move` is currently in use on the Aptos Blockchain. +3. Using aptos governance prepares us for extendeding it and using it for future proposals to upgrade or migrate the network, this will be a fairly common necessity post-mainnet. +4. It strenghtens the utility of `$L2-MOVE` as this becomes the governance token. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +## Reference Implementation + +The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. + +```rust +//pseudocode +module GovernedGasPool::goverened_gas_pool { + use aptos_framework::aptos_coin::AptosCoin; + use aptos_framework::coin; + use aptos_framework::signer; + use aptos_framework::aptos_governance; + use aptos_framework::aptos_governance::{self, GovernanceProposal}; + use aptos_std::vector; + use aptos_std::option::{self, Option}; + + // Address of the governance framework module + const GOVERNANCE_ADDRESS: address = @0x1; + + struct GovernedPool has key { + funds: coin::Coin, // holds the pool of funds in AptosCoin + passed_proposals: vector::Vector, // list of proposals that passed governance + admin: address // address with permission to execute proposals + } + + struct DispersalAction has copy, drop, store { + recipient: address, + amount: u64 + } + + struct Proposal has key { + id: u64, + dispersal_action: Option, // Only one type of action at a time + executed: bool, + } + + /// Initialize the Governed Pool + public fun initialize_governed_pool(admin: &signer, authorized_admin: address): address { + let governed_pool = GovernedPool { + funds: coin::zero(), + passed_proposals: vector::empty(), + admin: authorized_admin + }; + let addr = signer::address_of(admin); + move_to(admin, governed_pool); + addr + } + + /// Add a proposal that has passed governance + /// Only callable by the governance module at address 0x1 + public fun add_passed_proposal( + pool: &mut GovernedPool, + governance_signer: &signer, + id: u64, + dispersal_action: DispersalAction + ) { + // Ensure only the governance framework can call this function + assert!(signer::address_of(governance_signer) == GOVERNANCE_ADDRESS, 1); + + // Verify that the proposal is approved in aptos_governance + assert!(aptos_governance::is_proposal_approved(id), 2); + + let proposal = Proposal { + id, + dispersal_action: option::some(dispersal_action), + executed: false, + }; + vector::push_back(&mut pool.passed_proposals, proposal); + } + + /// Execute a proposal that has been approved by governance + /// Only callable by the designated admin + public fun execute_passed_proposal(pool: &mut GovernedPool, executor: &signer, proposal_id: u64) { + // Ensure only the authorized admin can call this function + assert!(signer::address_of(executor) == pool.admin, 2); + + let proposal_index = find_proposal(&pool.passed_proposals, proposal_id); + let proposal = &mut vector::borrow_mut(&mut pool.passed_proposals, proposal_index); + + // Ensure the proposal hasn't already been executed + assert!(!proposal.executed, 3); + + // Execute the dispersal action if present + if (option::is_some(&proposal.dispersal_action)) { + let action = option::borrow(&proposal.dispersal_action).unwrap(); + let amount = action.amount; + assert!(amount <= coin::value(&pool.funds), 4); // Ensure pool has sufficient funds + coin::withdraw(&mut pool.funds, amount); + coin::deposit(&signer::create(action.recipient), amount); + }; + + proposal.executed = true; + } +} +``` + +Notice the call : +`assert!(aptos_governance::is_proposal_approved(id), 2);` + +## Verification + + +## Errata + + +## Appendix + +--- +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From de6405a0adc3b9e78677e2f2f34f115e4cfcad34 Mon Sep 17 00:00:00 2001 From: apenzk Date: Tue, 28 Jan 2025 15:29:02 +0100 Subject: [PATCH 6/8] file was in wrong place --- README.md => MIP/mip-48/README2.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename README.md => MIP/mip-48/README2.md (100%) diff --git a/README.md b/MIP/mip-48/README2.md similarity index 100% rename from README.md rename to MIP/mip-48/README2.md From 077c200323baeb091e8e031b14038eec3a6fc7ff Mon Sep 17 00:00:00 2001 From: apenzk Date: Tue, 28 Jan 2025 15:30:18 +0100 Subject: [PATCH 7/8] moved wrong file --- MIP/mip-0/README.md | 118 ------------------------------------- MIP/mip-48/README2.md | 131 ++++++++++++++++++++++-------------------- README.md | 109 +++++++++++++++++++++++++++++++++++ 3 files changed, 179 insertions(+), 179 deletions(-) delete mode 100644 MIP/mip-0/README.md create mode 100644 README.md diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md deleted file mode 100644 index bae2d62f..00000000 --- a/MIP/mip-0/README.md +++ /dev/null @@ -1,118 +0,0 @@ -# MIP-\: use `aptos_governance` for Goverened Gas Pool -- **Description**: ???? -- **Authors**: [Richard Melkonian](mailto:richard@movementlabs.xyz) - -## Abstract - -The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to be subject to onchain governance by a governing body that holds the -`$L2-MOVE` token. In [MIP-44] governance mechanisms and roles are proposed, such as `Proposers` and `Executors` so that the collected gas can be used -for the good of the network. - -The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid -directly to attestors as `$L1-MOVE` for rewards. For all these activities a dispersal of funds is required, this MIP proposes concrete ways to manage dispersal events -in a safe immutable and secure manner. - -To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. - -## Motivation - -This MIP proposes an implementation of the governance mechanism proposed in [MIP-44] by using the `aptos_governance.move` module. We think this has several benefits. -1. `aptos_governance.move` is fully audited and battle tested. -2. `aptos_governance.move` is currently in use on the Aptos Blockchain. -3. Using aptos governance prepares us for extendeding it and using it for future proposals to upgrade or migrate the network, this will be a fairly common necessity post-mainnet. -4. It strenghtens the utility of `$L2-MOVE` as this becomes the governance token. - -## Specification - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. - -##### 1. Fix the Potential Supply - -As described in the [Abstract](#abstract), the sum of the token supply of `$L1MOVE` and `$L2MOVE` is equal to `MOVE_MAX`. Since the bridge is the sole point of creation (or release) of `$L2MOVE` token, the L2 contract MUST monitor the `$L2MOVE` supply. The L2 bridge contract MUST not release more `$L2MOVE` than the maximum supply `MOVE_MAX`. - -##### 2. Native Bridge rate limitation - -The total amount of bridge transfers should be rate limited to $(X, T)$ where $X$ is the maximum transferable amount per time period $T$. I.e. the bridge should not allow more than $X$ total transaction value in any $T$ period. - -To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. - - -##### 3. Relayer key protection - -The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. - -[This article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7) describes some of the considerations that have to be taken into account: - - **Multisigs**: - > It’s likely that the bridge is controlled by one or more multisigs —wallets that require multiple individuals to sign before a transaction is executed. Multisigs add an element of security by ensuring that a single signer can’t control the bridge. Multisigs might be used to enable the bridge contracts to be upgraded or paused. While multisigs are an essential security control for bridges, they are not foolproof and require proper management. In fact multisigs have been targeted in some major bridge exploits. - -**Contract Exploits**: -> Multisigs are implemented as smart contracts and are thus potentially vulnerable to exploits. Many of the popular multisig contracts have been used to store billions in assets over time and are somewhat battle tested. Nonetheless, these contracts do represent additional attack surface. - -**Signers are People**: -> Multisigs are controlled by a group of signers; you must trust that the private keys of those signers are kept secure. Any individual that is a singer on a multisig must be trusted to not be an adversary of course, but also must be trusted to adhere to basic security practices. Multisig signers are ripe targets for phishing and malware attacks. - -## Reference Implementation - - - -## Verification - -##### 1. Fix the Potential Supply - -Since the maximal released supply of `$L1MOVE` is `MOVE_MAX` the maximum *Potential Supply* (of the sum of the supply of `$L1MOVE` and `$L2MOVE`) is 2 $\times$ `MOVE_MAX`, even in the case of a compromised relayer and a maximum exploit. - -##### 2. Native Bridge rate limitation - - -Eigenlayer AVS does suggest a similar model and provides the following Definition on Strong Economic Security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf): - -> *Formal Definition of Strong Cryptoeconomic Security* -If [a bridge] acquires more [cryptoeconomic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong cryptoeconomic security, i.e.
->         *[Economic]-security ≥ Harm-from-corruption [..] in $T_{redeem}$ slots* - -> [..] consider a [..] bridge [..] for a rollup, which has a $(X, T)$-rate-limit [..]. Now if [$T - -Needs discussion. - ---- -## Reference Implementation - -The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. - -## Errata - - -## Appendix - ---- -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/MIP/mip-48/README2.md b/MIP/mip-48/README2.md index 82bcd753..bae2d62f 100644 --- a/MIP/mip-48/README2.md +++ b/MIP/mip-48/README2.md @@ -1,109 +1,118 @@ +# MIP-\: use `aptos_governance` for Goverened Gas Pool +- **Description**: ???? +- **Authors**: [Richard Melkonian](mailto:richard@movementlabs.xyz) -# MIP, MD and MG +## Abstract -We differentiate between MD and MIPs. +The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to be subject to onchain governance by a governing body that holds the +`$L2-MOVE` token. In [MIP-44] governance mechanisms and roles are proposed, such as `Proposers` and `Executors` so that the collected gas can be used +for the good of the network. -An overview of the MIPs and MDs can be found in the [OVERVIEW](https://github.com/movementlabsxyz/MIP/wiki/Overview). +The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid +directly to attestors as `$L1-MOVE` for rewards. For all these activities a dispersal of funds is required, this MIP proposes concrete ways to manage dispersal events +in a safe immutable and secure manner. -In addition MG serves as a glossary for terms defined in the MIPs and MDs. +To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. -## Movement Desiderata (MD) +## Motivation -See [MD-0](./MD/md-0) to get started. A template is provided at [md-template](md-template.md). +This MIP proposes an implementation of the governance mechanism proposed in [MIP-44] by using the `aptos_governance.move` module. We think this has several benefits. +1. `aptos_governance.move` is fully audited and battle tested. +2. `aptos_governance.move` is currently in use on the Aptos Blockchain. +3. Using aptos governance prepares us for extendeding it and using it for future proposals to upgrade or migrate the network, this will be a fairly common necessity post-mainnet. +4. It strenghtens the utility of `$L2-MOVE` as this becomes the governance token. -MDs serve to capture the **objectives** behind the **introduction** of a particular MIP. Any +## Specification -- _wish_, -- _requirement_, or -- _need_ +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. -related to MIPs should be documented as an MD and stored in the MD directory. +##### 1. Fix the Potential Supply -## Movement Improvement Proposal (MIP) +As described in the [Abstract](#abstract), the sum of the token supply of `$L1MOVE` and `$L2MOVE` is equal to `MOVE_MAX`. Since the bridge is the sole point of creation (or release) of `$L2MOVE` token, the L2 contract MUST monitor the `$L2MOVE` supply. The L2 bridge contract MUST not release more `$L2MOVE` than the maximum supply `MOVE_MAX`. -See [MIP-0](./MIP/mip-0) to get started. A template is provided at [mip-template](mip-template.md). +##### 2. Native Bridge rate limitation -### Deciding whether to propose +The total amount of bridge transfers should be rate limited to $(X, T)$ where $X$ is the maximum transferable amount per time period $T$. I.e. the bridge should not allow more than $X$ total transaction value in any $T$ period. -You **SHOULD** draft and submit an MIP, if any of the following are true: +To not impact honest traffic heavily, a governance body MAY be overseeing, whether the `bridge_rate` SHOULD be increased temporarily and for what interval. However, such a mechanism impacts the security assumptions as this governance body also would have to adhere to stringent security requirements and a compromise of the governance body could effectively disable the rate limitation. Also the above mentioned Crypto-economic security guarantees do not hold any longer. -- Governance for the relevant software unit or process requires an MIP. -- The proposal is complex or fundamentally alters existing software units or processes. -AND, you plan to do the work of fully specifying the proposal and shepherding it through the MIP review process. +##### 3. Relayer key protection -You **SHOULD NOT** draft an MIP, if any of the following are true: +The relayer shall maximize security measurements to protect its keys. For example, it SHOULD implement a multi-signature scheme to sign its messages, as is proposed in [MIP-21](https://github.com/movementlabsxyz/MIP/pull/21). The owners of the constituent keys should be distinct entities with distinct access to their keys. -- You only intend to request a change to software units or processes without overseeing specification and review. -- The change is trivial. In the event that an MIP is required by governance, such trivial changes usually be handled as either errata or appendices of an existing MIP. +[This article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7) describes some of the considerations that have to be taken into account: -## Movement Glossary (MG) + **Multisigs**: + > It’s likely that the bridge is controlled by one or more multisigs —wallets that require multiple individuals to sign before a transaction is executed. Multisigs add an element of security by ensuring that a single signer can’t control the bridge. Multisigs might be used to enable the bridge contracts to be upgraded or paused. While multisigs are an essential security control for bridges, they are not foolproof and require proper management. In fact multisigs have been targeted in some major bridge exploits. -See [MG-0](./MIP/mg-0) to get started. A template is provided at [mg-template](mg-template.md). +**Contract Exploits**: +> Multisigs are implemented as smart contracts and are thus potentially vulnerable to exploits. Many of the popular multisig contracts have been used to store billions in assets over time and are somewhat battle tested. Nonetheless, these contracts do represent additional attack surface. -An alphabetically ordered list of terms is provided in the [glossary](GLOSSARY.md). +**Signers are People**: +> Multisigs are controlled by a group of signers; you must trust that the private keys of those signers are kept secure. Any individual that is a singer on a multisig must be trusted to not be an adversary of course, but also must be trusted to adhere to basic security practices. Multisig signers are ripe targets for phishing and malware attacks. -MGs serve to capture the **definitions** of terms introduced in the MIPs and MDs. The creation of a new MG requires an MIP or MG (since new terms are introduced through the MIP or MG). +## Reference Implementation -## Files and numbering + -An MIP/MD starts as **Draft**s. They DO NOT acquire a number at this point. +## Verification -An MIP/MD is assigned their PR number as soon as they are in the **Review** process. MDs that do not introduce a new MIP/MD are also accepted. Thus, there will be gaps in the MIP/MD number sequence. These gaps will also emerge when MIPs/MDs are deprecated or rejected. +##### 1. Fix the Potential Supply -> [!NOTE] -> Update the [OVERVIEW](https://github.com/movementlabsxyz/MIP/wiki/Overview) file with the MIP/MD number, title and other requirements. +Since the maximal released supply of `$L1MOVE` is `MOVE_MAX` the maximum *Potential Supply* (of the sum of the supply of `$L1MOVE` and `$L2MOVE`) is 2 $\times$ `MOVE_MAX`, even in the case of a compromised relayer and a maximum exploit. -PRs that don't introduce a new MIP/MD are also accepted, for example MIPs/MDs can be updated. PRs that **Update** a MIP/MD should state so in the PR title, e.g. `[Update] MIP-....`. +##### 2. Native Bridge rate limitation -## Status Terms -An MIP/MD is proposed through a PR. Each MIP/MDG-introducing PR should have a status in the name in the form `[Status] ...`. +Eigenlayer AVS does suggest a similar model and provides the following Definition on Strong Economic Security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf): -An MIP/MG should at all times have one of the following statuses: +> *Formal Definition of Strong Cryptoeconomic Security* +If [a bridge] acquires more [cryptoeconomic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong cryptoeconomic security, i.e.
+>         *[Economic]-security ≥ Harm-from-corruption [..] in $T_{redeem}$ slots* -- **Draft** - (set by author) An MIP/MD that is open for consideration. (It does not yet hold an MIP/MD number) -- **Review** - (set by author) The MIP/MD is under peer review. The MIP/MD should receive an **MIP/MD number**, according to the rules described in the [Files and numbering](#files-and-numbering) section. At this point the editor should be involved to ensure the MIP/MD adheres to the guidelines. +> [..] consider a [..] bridge [..] for a rollup, which has a $(X, T)$-rate-limit [..]. Now if [$T[!Note] -> In case the editors are not available for an unacceptable long period of time, a reviewer should assume the role of the editor interim. +##### 3. Relayer key protection -After acceptance the MIP/MD is merged into `main` and the branch should be deleted. +Multisignature approaches are common praxis, for example see [MIP-21](https://github.com/movementlabsxyz/MIP/tree/primata/bridge-attestors/MIP/mip-21) or see [this article](https://medium.com/@j2abro/a-visual-guide-to-blockchain-bridge-security-e982fec671a7). -Additionally, the following statuses are used for MIPs/MDs that are not actively being worked on: -- **Stagnant** - an MIP/MD that has not been updated for 6 months. -- **Withdrawn** - an MIP/MD that has not been withdrawn. + -**Conflict resolution**: In the unlikely case, where an editor requests a change from an author that the author does not agree with and communication does not resolve the situation +Needs discussion. -- the editor can mandate that the author implements the changes by getting 2 upvotes from reviewers on their discussion comment mentioning the changes. -- Otherwise the author can merge without the editor requested change. +--- +## Reference Implementation -## Code owners +The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds. -An author commits to becoming the owner of the MIP/MD they propose. This means that for any future changes to the MIP/MD the author will be notified. +## Errata -This is being implemented by adding the author as a code owner in the `.github/CODEOWNERS` file for a given MIP/MD. + +## Appendix + +--- +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/README.md b/README.md new file mode 100644 index 00000000..82bcd753 --- /dev/null +++ b/README.md @@ -0,0 +1,109 @@ + +# MIP, MD and MG + +We differentiate between MD and MIPs. + +An overview of the MIPs and MDs can be found in the [OVERVIEW](https://github.com/movementlabsxyz/MIP/wiki/Overview). + +In addition MG serves as a glossary for terms defined in the MIPs and MDs. + +## Movement Desiderata (MD) + +See [MD-0](./MD/md-0) to get started. A template is provided at [md-template](md-template.md). + +MDs serve to capture the **objectives** behind the **introduction** of a particular MIP. Any + +- _wish_, +- _requirement_, or +- _need_ + +related to MIPs should be documented as an MD and stored in the MD directory. + +## Movement Improvement Proposal (MIP) + +See [MIP-0](./MIP/mip-0) to get started. A template is provided at [mip-template](mip-template.md). + +### Deciding whether to propose + +You **SHOULD** draft and submit an MIP, if any of the following are true: + +- Governance for the relevant software unit or process requires an MIP. +- The proposal is complex or fundamentally alters existing software units or processes. + +AND, you plan to do the work of fully specifying the proposal and shepherding it through the MIP review process. + +You **SHOULD NOT** draft an MIP, if any of the following are true: + +- You only intend to request a change to software units or processes without overseeing specification and review. +- The change is trivial. In the event that an MIP is required by governance, such trivial changes usually be handled as either errata or appendices of an existing MIP. + +## Movement Glossary (MG) + +See [MG-0](./MIP/mg-0) to get started. A template is provided at [mg-template](mg-template.md). + +An alphabetically ordered list of terms is provided in the [glossary](GLOSSARY.md). + +MGs serve to capture the **definitions** of terms introduced in the MIPs and MDs. The creation of a new MG requires an MIP or MG (since new terms are introduced through the MIP or MG). + +## Files and numbering + +Each MIP, MD or MG is stored in a separate subdirectory with the a name `mip-`, `md-` or `mg-`. The subdirectory contains a `README.md` that describes the MIP, MD, or MG. All assets related to the MIP, MD or MG are stored in the same subdirectory. + +An MIP/MD starts as **Draft**s. They DO NOT acquire a number at this point. + +An MIP/MD is assigned their PR number as soon as they are in the **Review** process. MDs that do not introduce a new MIP/MD are also accepted. Thus, there will be gaps in the MIP/MD number sequence. These gaps will also emerge when MIPs/MDs are deprecated or rejected. + +> [!NOTE] +> Update the [OVERVIEW](https://github.com/movementlabsxyz/MIP/wiki/Overview) file with the MIP/MD number, title and other requirements. + +PRs that don't introduce a new MIP/MD are also accepted, for example MIPs/MDs can be updated. PRs that **Update** a MIP/MD should state so in the PR title, e.g. `[Update] MIP-....`. + +## Status Terms + +An MIP/MD is proposed through a PR. Each MIP/MDG-introducing PR should have a status in the name in the form `[Status] ...`. + +An MIP/MG should at all times have one of the following statuses: + +- **Draft** - (set by author) An MIP/MD that is open for consideration. (It does not yet hold an MIP/MD number) +- **Review** - (set by author) The MIP/MD is under peer review. The MIP/MD should receive an **MIP/MD number**, according to the rules described in the [Files and numbering](#files-and-numbering) section. At this point the editor should be involved to ensure the MIP/MD adheres to the guidelines. + +>[!Note] +> In case the editors are not available for an unacceptable long period of time, a reviewer should assume the role of the editor interim. + +After acceptance the MIP/MD is merged into `main` and the branch should be deleted. + +Additionally, the following statuses are used for MIPs/MDs that are not actively being worked on: + +- **Stagnant** - an MIP/MD that has not been updated for 6 months. +- **Withdrawn** - an MIP/MD that has not been withdrawn. + +Finally, an MIP/MD can also be updated: + +- **Update** - (set by author) An MIP/MD is being updated. The title should list the MIP/MD number, e.g. `[Update] MIP-0 ...`. + +## Editor + +The motivation for the role of the editor is to ensure the readability and easy access of content, until further means, such as automatic rendering becomes available. + +Currently the editors are [@apenzk](https://github.com/apenzk). + +The editor is responsible for the final review of the MIPs. The editor is responsible for the following: + +- Ensures a high quality of the MIPs/MDs, e.g. checking language while reviewing. +- Removes content from the MIPs/MDs that is commented out. (e.g. content within brackets) +- Ensures the MIP/MD numbering is correct. +- Ensures the MIP/MD is in the correct status. +- Ensures the authors have added themselves to [CODEOWNERS](./.github/CODEOWNERS), see [Code owners](#code-owners). + +The editor is not responsible for the content. + +**Conflict resolution**: In the unlikely case, where an editor requests a change from an author that the author does not agree with and communication does not resolve the situation + +- the editor can mandate that the author implements the changes by getting 2 upvotes from reviewers on their discussion comment mentioning the changes. +- Otherwise the author can merge without the editor requested change. + +## Code owners + +An author commits to becoming the owner of the MIP/MD they propose. This means that for any future changes to the MIP/MD the author will be notified. + +This is being implemented by adding the author as a code owner in the `.github/CODEOWNERS` file for a given MIP/MD. From 0da4ee20d29eb8d5b3606078b1cc138afbafcfaf Mon Sep 17 00:00:00 2001 From: apenzk Date: Tue, 28 Jan 2025 15:33:11 +0100 Subject: [PATCH 8/8] get back the accidently replaced mip-0 file --- MIP/mip-0/README.md | 60 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 MIP/mip-0/README.md diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md new file mode 100644 index 00000000..75121248 --- /dev/null +++ b/MIP/mip-0/README.md @@ -0,0 +1,60 @@ +# MIP-0: MIPs +- **Description**: Movement Improvement Proposals standardize and formalize specifications for Movement technologies. +- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) +- **Desiderata**: [MD-0](../MD/md-0) + +## Abstract + +Movement Improvement Proposals (MIPs) serve as a mechanism to propose, discuss, and adopt changes or enhancements to Movement technologies. By providing a standardized and formalized structure for these proposals, MIPs ensure that proposed improvements are well-defined, transparent, and accessible to the wider community. + +## Motivation + +Movement technologies continually evolve, and there's a need to ensure that the process of proposing and adopting changes is both organized and standardized. By establishing MIPs, we aim to facilitate the introduction of new features or improvements, making sure they are well-vetted, discussed, and documented. This ensures the integrity of Movement technologies, making it easier for third parties to adopt and adapt to these changes. + +## Specification + +A Movement Improvement Proposal (MIP) is a design document that provides information to the Movement community, describing a new feature or improvement for Movement technologies. + +- **Structure**: Each MIP must adhere to the given template, which requires details like title, description, author, status, and more. A MIP also includes sections like Abstract, Motivation, Specification, Reference Implementation, Verification, Errata, and Appendix. + + - An md-template is provided in the [MIP Repository](https://github.com/movemntdev/MIP) which further specifies this structure. This MIP is an example of said structure. + +- **Lifecycle**: An MIP starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MIP can also be deprecated if it becomes obsolete. + +- **Storage**: MIPs should be stored in the MIPs directory at [MIP Repository](https://github.com/movemntdev/MIP). + +- **Definitions** : Provide definitions that you think will empower the reader to quickly dive into the topic. + +## Reference Implementation + +A reference implementation or a sample MIP following the MIP template can be provided to guide potential proposers. This MIP (MIP-0) serves as a practical example, aiding in understanding the format and expectations. + +## Verification + +1. **Correctness**: Each MIP must convincingly demonstrate its correctness. + +This MIP is correct insofar as it uses a structure established by Ethereum for Improvement Proposals which has hitherto been successful. + +2. **Security Implications**: Each MIP should be evaluated for any potential security risks it might introduce to Movement technologies. + +The primary security concern associated with this MIP is the exposure of proprietary techologies or information via the ill-advised formation of an MIP which the MIP process might encourage. + +3. **Performance Impacts**: The implications of the proposal on system performance should be analyzed. + +The primarry performance concern associated with this MIP is its potential for overuse. Only specifications that are non-trivial and very high-quality should be composed as MIPs. + +4. **Validation Procedures**: To the extent possible, formal, analytical, or machined-aided validation of the above should be pursued. + +I'm using spellcheck while writing this MIP. You can verify that I am using valid grammar by pasting this sentence into Google Docs. + +5. **Peer Review and Community Feedback**: A section should be included that captures significant feedback from the community, which may influence the final specifications of the MIP. + +The Movement Labs team is currently reviewing and assessig this process. + +## Errata + +Post-publication corrections, if any, to the MIPs should be documented in this section. This ensures transparency and provides readers with accurate and up-to-date information. + +## Appendix + +The Appendix should contain references and notes related to the MIP. Materials referenced in the MIP should be marked with specific labels (e.g., ⟨R1⟩) for easy tracking and understanding. \ No newline at end of file