diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index c67e0c43..436ef443 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -25,6 +25,7 @@ /MIP/mip-88/ @apenzk @Primata /MIP/mip-91/ @apenzk /MIP/mip-94/ @andygolay +/MIP/mip-103/ @l-monninger ## MGs /MG/mg-0/ @l-monninger diff --git a/.vscode/spellright.dict b/.vscode/spellright.dict index 36f86153..aece05f6 100644 --- a/.vscode/spellright.dict +++ b/.vscode/spellright.dict @@ -2,7 +2,9 @@ Aptos Changelog Fastconfirmation Fastconfirmations +Merkle multisig +onchain postconfirm postconfirmed timelock diff --git a/MIP/mip-103/README.md b/MIP/mip-103/README.md new file mode 100644 index 00000000..c05b06fc --- /dev/null +++ b/MIP/mip-103/README.md @@ -0,0 +1,261 @@ +# MIP-103: Baker Confirmations (ZK-FFS) + +- **Description**: Proposes a Zero Knowledge means of confirming commitments between layers aligned with the FFS protocol. +- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) +- **Desiderata**: [MD-34](https://github.com/movementlabsxyz/MIP/pull/34), [MD-3](https://github.com/movementlabsxyz/MIP/pull/3), [MD-4](https://github.com/movementlabsxyz/MIP/pull/4), [MD-5](https://github.com/movementlabsxyz/MIP/pull/5), [MD-37](https://github.com/movementlabsxyz/MIP/pull/37), [MD-65](https://github.com/movementlabsxyz/MIP/pull/65) +- **Etymology**: The first draft of this proposal was written in a cafe on Baker Street in San Francisco. + +## Abstract + +We propose a Baker Confirmations as a means of generalizing the FFS protocol via a Zero Knowledge proof of consensus mechanism. The benefits of using such a system are threefold: (a) modularity, (b) composability, and (c) scalable or reduced costs. We also briefly propose how Baker Confirmations can be used to solve the problems outlined in [MD-3](https://github.com/movementlabsxyz/MIP/pull/3), [MD-4](https://github.com/movementlabsxyz/MIP/pull/4), and [MD-5](https://github.com/movementlabsxyz/MIP/pull/5) which are difficult to solve when vote tabulation is represented on-chain. + +## Motivation + +Ultimately, the role of the contracts in the current FFS protocol are simply to verify and mark consensus on a particular commitment at a particular `superBlock` height, or round, on a given ledger. While implementing the actual tabulation of votes on-chain serves to reduce development time and avoid the implementation of an off-chain service, it does not in fact minimize the role of the on-chain contracts. Baker Confirmations instead propose such minimization by ensuring that the contracts simply verify ZK proofs of consensus and dispatch the appropriate onchain events. + +## Specification + +![Baker Confirmations](./rsc/baker-confirmations.png) + +There are two crucial roles in a Baker Confirmer which we will address individually and in detail: + +- **Attesters** generate commitments at a given block-height and sign them before broadcasting them to the Baker Network. +- **Validators** verify the commitments generated by the Attesters, tabulate them in a Zero Knowledge program, and submit the proof of this Zero Knowledge program and its outputs on-chain. + +In a simplified model of a Baker Network, all Participants are both Attesters and Validators. However, as we will demonstrate, this is not a strict requirement of the protocol. + +For simplicity we specify Baker Confirmations in terms of a simple unidirectional commitment scheme we call [Baker Coin](#baker-coin). We introduce but do not specify generalizations of this scheme which are especially intriguing for their composability, modularity, and multi-directionality. + +Finally, we describe how the specification addresses problems [MD-3](https://github.com/movementlabsxyz/MIP/pull/3), [MD-4](https://github.com/movementlabsxyz/MIP/pull/4), and [MD-5](https://github.com/movementlabsxyz/MIP/pull/5), as well as contending with problems inherent to the Baker Confirmations scheme itself. + +### Baker Coin + +Baker Coin is a class of unidirectional commitment protocols satisfying the [postconfirmations]() scheme proposed in [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37). It has the following additional constraints: + +1. **Unidirectional**: A Baker Coin protocol MUST intend ONLY to post a commitment the state of a given Ledger B onto Ledger A, not vice versa. +2. **Staked**: A Baker Coin protocol MUST rely on weighted votes, known as stake, to determine whether consensus has been reached amongst a set of participants. These stake weights must be represented over the field of integers from 0 to 2^256 - 1, $\mathbb{F}_{2^{256}}$. +3. **Epoch-bound**: A Baker Coin protocol MUST fix stake weights throughout an epoch $e \in E$ which begins at a Unix timestamp $t_e$ and ends at a Unix timestamp $t_{e+1}$. This has the same effect as fixing the **Attesters** for a given epoch. +4. **Rewarding**: A Baker Coin protocol MAY dispatch events to issue new units of a given token or "coin," Coin A, on Ledger A in the event of a commitment. The value of this coin may range from 0 to 2^256 - 1, $\mathbb{F}_{2^{256}}$. +5. **Slashing**: A Baker Coin protocol MAY also remove or "slash" staked Coin A held in the verification contract on Ledger A in the event of a commitment. The value of this slashed token may range from 0 to 2^256 - 1, $\mathbb{F}_{2^{256}}$. +6. **Observant**: A Baker Coin protocol MUST use a set of trusted **A-Observers** to relay valid stake events from Ledger A to validators in the Baker Network. These **A-Observers** are not necessarily the same as the **Attesters** for a given epoch. + +> :bulb: +> The **Observant** constraint is intentionally suboptimal from the perspective of trust. We will be using it to underscore possibilities of **Internal Staking**, **Staked A-Observers**, Ledger B certificate summaries, and other composable solutions in this and future MIPs. + +There are thus four node types in a Baker Coin protocol: + +- **Baker Coin Attesters** perform the basic operations of an **Attester** but also send stake messages to Ledger A. They thus *broadcast* the following messages. + - $COMMIT(commitment, height, signature) \rightarrow \text{Baker Coin Validators}$ which makes a signed `COMMITMENT` to a given Ledger B state at a given height. + - $STAKE(amount, epoch, signature) \rightarrow \text{A-Participants}$ which attempts to stake an amount of Coin A on Ledger A for a given epoch. +- **Baker Coin Validators** perform the basic operations of a **Validator** but also receive $TRUSTED\\_STAKE$ messages from **A-Observers**. They thus *broadcast* the following messages. + - $COMMITMENT\\_PROOF(commitment, height, Attesters, proof, signature) \rightarrow \text{A-Participants}$ which attempts to post a commitment to a given Ledger B state at a given Ledger B height on Ledger A. +- **A-Observers** perform the role of observing stake events on Ledger A and relaying them to the Baker Network. They thus *broadcast* the following messages. + - $TRUSTED\\_STAKE(amount, participant, epoch, signature) \rightarrow \text{Baker Coin Validators}$ which indicates a valid stake event on Ledger A as initiated by a Baker Coin Attester via a $STAKE$ message. +- **A-Participants (Ledger A Participants)** perform the basic operations of a participant on Ledger A, as defined by Protocol A which MUST include the emission $STAKE\\_RECEIVED$ events. They thus *broadcast* the following messages: + - $STAKE\\_RECEIVED(amount, participant, epoch, signature) \rightarrow \text{A-Observers}$ which indicates a valid stake event on Ledger A as initiated by a Baker Coin Attester via a $STAKE$ message. + +We render the following assumptions about knowledge after receiving a given message in the Baker Coin protocol: + +1. Once an **A-Observer** has received sufficient and accordingly verified $STAKE\\_RECEIVED$ messages from A-Participants, the effects of the corresponding $STAKE$ messages on Ledger A SHALL remain fixed for the remainder of the epoch. +2. Once a **Baker Coin Validator** has received sufficient and accordingly verified $TRUSTED\\_STAKE$ messages from **A-Observers**, it SHALL correctly update its internal representation of stake weights for the remainder of the epoch. + +We may now address the specific and practical behavior of the **Attester** and the **Validator** in a Baker Coin protocol, so as to explain the core mechanism of Baker Confirmations. + +### Attesters + +An honest Attester in the Baker Coin protocol is assumed to compute a new state root by running a state transition function $T: S \times M \rightarrow S$ on the current state $s \in S$ and a set of messages $m \in M$ to produce a new state $s' \in S$. The Attester then signs the new state root and broadcasts it to the Baker Network. + +In order to ensure the proof computed by the Validator can attest to the identity of the commitment, the commitment MUST be signed by the Attester. + +Thereby, an honest Attester in the Baker Coin protocol SHOULD simply broadcast messages of the form $COMMIT(commitment, height, signature)$ to the Baker Network that represent honest and attributable computations of the state of Ledger B at a given height. + +The form of state transition function MUST be such that for a given height all replicas of Ledger B SHALL produce the same state and thus the same commitment. + +### Validators + +The role of the Validator is more complex. The Validator MUST: + +1. Run a procedure $RECEIVE\\_COMMITMENT$ which accepts a commitment and height from an Attester and updates its internal representation of the commitments. +2. Run a procedure $RECEIVE\\_TRUSTED\\_STAKE$ which accepts a stake amount, participant, and epoch from an A-Observer and updates its internal representation of the stake weights. +3. Use a heuristic to decide when to run a procedure $COMPUTE\\_PROOF$ which computes a Zero Knowledge proof of consensus on a given commitment at a given height. +4. Use a heuristic to decide when to run a procedure $POST\\_PROOF$ which posts the Zero Knowledge proof of consensus on a given commitment by broadcasting a $COMMITMENT\\_PROOF$ message to A-Participants. + +#### $RECEIVE\\_COMMITMENT$ + +- ##### Human Language Description of Procedure + + $RECEIVE\\_COMMITMENT$ takes a commitment and height from an Attester. It verifies the commitment and stores it in a table indexed by height. It then notifies the heuristic checker to decide whether to run $COMPUTE\\_PROOF$. + + ##### Pseudocode Description of Procedure + + ```python + def RECEIVE_COMMITMENT(commitment, height, signature): + # Verify the commitment and signature + if not verify_commitment(commitment, height, signature): + return + + # Store the commitment in a table indexed by height + self.commitments[height] = commitment + + # Notify the heuristic checker to decide whether to run COMPUTE_PROOF + self.heuristic_checker.notify() + ``` + +#### $RECEIVE\\_TRUSTED\\_STAKE$ + +- ##### Human Language Description of Procedure + + $RECEIVE\\_TRUSTED\\_STAKE$ takes a stake amount, participant, and epoch from an A-Observer. It verifies the stake amount and epoch and stores it in a table indexed by participant and epoch, but MUST only modify stake weights for the next epoch. If this constraint is not applied, then the epoch staking constraint is violated. + + > :warning: + > The constraint on the epoch staking above is naive as it does not account for the time it takes for a Validator to receive a $TRUSTED\\_STAKE$ message from an A-Observer. This will be discussed in more detail below. + + ##### Pseudocode Description of Procedure + + ```python + def RECEIVE_TRUSTED_STAKE(amount, participant, epoch, signature): + # Verify the epoch + if epoch < self.current_epoch + 1: + return + + # Verify the stake amount and signature + if not verify_stake(amount, participant, epoch, signature): + return + + # Store the stake amount in a table indexed by participant and epoch + self.stake_weights[participant][epoch] = amount + ``` + +#### $COMPUTE\\_CONSENSUS$ and Heuristic + +- ##### Human Language Description of Procedure + + $COMPUTE\\_CONSENSUS$ tabulates all of the commitments and stake weights for a given height and epoch and computes a Zero Knowledge proof of consensus on a given commitment at a given height. It additionally outputs slashing and rewarding amounts for the participants who submitted the commitments according to slashing function $S$ and rewarding function $R$. It is run in a ZK execution environment and so outputs a proof of the computation. + + ##### Pseudocode Description of Procedure + + ```python + def COMPUTE_CONSENSUS(commitment, height, epoch): + # Tabulate all of the commitments and stake weights for a given height and epoch + commitments = self.commitments[height] + stake_weights = self.stake_weights[epoch] + + # Check if the sum of the stake weights voting on a given commitment is greater than the threshold + if sum(stake_weights[participant] for participant in commitments if commitments[participant] == commitment) > threshold: + # Compute the slashing and rewarding amounts + slashing_amounts = S(commitments, stake_weights, commitment, height, epoch) + rewarding_amounts = R(commitments, stake_weights, commitment, height, epoch) + + # Return the proof of consensus and the slashing and rewarding amounts + return proof, slashing_amounts, rewarding_amounts + else: + return None, None, None + + ``` + + ##### Human Language Description of Heuristic + + This MIP does prescribe a specific heuristic for deciding when to run $COMPUTE\\_CONSENSUS$. In general, however, the **Validator** would save compute by only running $COMPUTE\\_CONSENSUS$ when it has received a sufficient number of commitments and stake weights, i.e., by precomputing the $COMPUTE\\_CONSENSUS$ procedure outside of the ZK execution environment. + +#### $POST\\_PROOF$ + +- Proof posting is intended to be a simple procedure which broadcasts a $COMMITMENT\\_PROOF$ message to A-Participants. The message SHALL include the commitment, height, Attesters, proof, slashing amounts, rewarding amounts, and signature. It does not require any additional computation. + + ##### Human Language Description of Heuristic + + This MIP does prescribe a specific heuristic for deciding when to run $POST\\_PROOF$. In general, however, the **Validator** has to balance on-chain costs with the expected value of the reward. + + To avoid disincentivizing honest posting behavior due to reward uncertainty, the on-chain reward mechanism should accept more than simply the initial commit. This phenomenon is addresses more completely in [Phenomena](#phenomena). + +### Phenomena + +- #### Forking and Asynchrony + + In general, forks are easier to represent off-chain than on-chain. We, however, note several distinct simplifications which arise from the Baker Confirmations protocol. + + ##### Fork Representation + + Baker Confirmations for a Baker Coin Protocol remove the need to represent forks on-chain. The on-chain contract must simply verify the Zero Knowledge proof of consensus and dispatch the appropriate onchain events. + + ##### Fork Stake + + The primary problem with stake in an FFS confirmation device, outlined in [MD-3](https://github.com/movementlabsxyz/MIP/blob/md/mcr-asynchrony-part-2/MD/md-3/asychronous-upgrades-problem.md) is that--because said device is not inherently designed within the reorganization logic of the confirming ledger itself--rewards, once issued on a given fork, cannot be revoked. In contrast, in more conventional DLT, the rewards exist on the fork of the ledger itself and once that fork is orphaned, the rewards are revoked. + + This problem persists under Baker Confirmations for a Baker Coin Protocol. However, it is possible to remove gas attacks associated with these solutions: + + 1. **Reward Delay**: One partial solution to the Fork Stake problem is to delay the emission of rewards by some number of epochs. The result is that contributing to a fork which does not survive for the duration of the delay period is not profitable. When tabulating on-chain, this delay is, however, problematic because it may lead to the cost of issuing a reward to an honest Partition A being correlated with the cost of issuing a reward to a malicious Partition B. When the delay is applied off-chain, however, these costs are negligible. + 2. **Gas Splitting**: Another partial solution to the Fork Stake problem is in fact to split the + + ##### Confirmation rewards and liveness + + An issue with on-chain confirmation is that the cost of confirming or rolling over an epoch is proportional to the size of the Validator set. As a result this specific task requires incentivization in order to cover the cost. + + As discussed in [MD-4](https://github.com/movementlabsxyz/MIP/pull/102), dependent on the implementation, this may lead to disincentives for Validators to post proofs, if not properly rewarded, or a race to post at the correct time to receive the reward. If less then the threshold stake of validators behave honest (and instead, e.g. rational), this could lead to hard to predict behavior for the liveness of the protocol. + + [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37) separates this issue from the validators, by introducing the notion of an **acceptor**, which is dedicated for the service of confirming and rolling over an epoch. This removes race conditions and makes the rewards for this task more predictable. Moreover, it moves the liveness concerns into a more classical realm with timeouts. + + The Baker Coin Protocol still may suffer from the problem described in [MD-4](https://github.com/movementlabsxyz/MIP/pull/102), as it is provided that the Validator post a proof containing clear-text rewards and slashes. This means that the Validator posting the proof still runs a transaction proportional to the size of the Validator set. + + Note that the Validator could share the Merkle root of rewards, against which Validators would submit Merkle Proofs to claim their rewards. This then fixes the cost of the commitment transaction. We discuss this possibility further in the [Generalizations](#generalizations) section. + + ###### Standoffs + + [MD-4](https://github.com/movementlabsxyz/MIP/pull/4/files) also presents the problem of standoffs wherein a Validator, upon realizing it is the last Validator needed to reach a super-majority, may choose to withhold its commitment in order to maximize its reward. + + The Baker Coin Protocol is not immune to this problem. Commitments are still provided in clear-text and so the Validator can still choose to withhold its commitment with knowledge of the other commitments made. Commitment hiding schemes also do not work because the Validator must still provide a proof of consensus and thus will still be able to compute whether its vote would satisfy the super-majority threshold. + +- #### Reward Uncertainty + + In general, the contracts receiving a Commitment in Baker Confirmations must be able to handle multiple and differing super-majority commitments to the same value. This presents several phenomena which are worthy of note. + + ##### Proofs of Differing Consensus + + In theory, each Validator can receive a different--but intersecting--set of commitments from the Attesters to reach a super-majority. Concerning attester rewards, this simply means that the on-chain contract MUST reward by the union of all accepted proofs of commitment to avoid over-rewarding Attesters. + + ##### Proofs of Differing Commitments + + In theory, Attesters can submit differing commitments to different Validators and arrive at a consensus on a given commitment at each. In simple cases, this behavior would not satisfy our Byzantine assumptions under FFS, and so does not need to be addressed. + + However, this problem becomes more acute when considering that the Validators may allow for the production of forks. In this case, an Attester could submit different commitments to different Validators to potentially earn rewards on different forks. To Validator $V_1$, Attester $Att$ may make Commitment $C_1$ on Fork $F_1$. Attester $Att$ cannot recommit to Validator $V_1$, but could still commit to Validator $V_1$ on Fork $F_2$. + + Because the on-chain contract must accept multiple commitments, it must also accept multiple proofs of consensus. Thus, Attester $Att$'s commitment to both Validator $V_1$ and Validator $V_2$ could be accepted on-chain. + +### Generalizations + +- #### Multidirectional Baker Confirmations and Composition + + We can conceive of a class of Baker Confirmations which are not unidirectional. These include cases where votes from attester compose the state of multiple ledgers. + + We detail this possibility in [MIP-n](mip-n/README.md). + +- #### Staked A-Observers + + We can conceive of a class of Baker Confirmations which are not observant. These include cases where the A-Observers are themselves staked and thus can be slashed for dishonest behavior. + + We detail this possibility in [MIP-n](mip-n/README.md). + +- #### Stake Checks + + We can conceive of a class of Baker Confirmations wherein the proofs contain the stake amounts against which they were computed s.t. these amounts can be checked on-chain before the proof is accepted. + + We detail this possibility in [MIP-n](mip-n/README.md). + +- #### Hooks + + We can conceive of a class of Baker Confirmations wherein the proofs contain hooks to trigger arbitrary logic on-chain. + + We detail this possibility in [MIP-n](mip-n/README.md). + +- #### Merkleization and State Certificates + + We can conceive of a class of Baker Confirmations wherein--instead of submitting clear-text commitments to readily dispatch on-chain logic--the commitments are submitted as Merkle roots against which Merkle-inclusion gated methods can be triggered by another service to dispatch on-chain logic. + + We detail this possibility in [MIP-n](mip-n/README.md). + +## Reference Implementation + +## Verification + +## Appendix + +## Changelog diff --git a/MIP/mip-103/roadmap/README.md b/MIP/mip-103/roadmap/README.md new file mode 100644 index 00000000..e8bcf32a --- /dev/null +++ b/MIP/mip-103/roadmap/README.md @@ -0,0 +1,82 @@ +# Roadmap +![Roadmap](./roadmap-summer.png) + +> [!NOTE] +> The above roadmap diagrams features key milestones. For a more complete treatment, see [Key Milestones](#key-milestones). + +This document contains a roadmap for Movement Lab's Fast Finality Settlement (FFS), a proof of stake L2 confirmations system. The roadmap advocates for continual community engagement via Staking Games and sees ultimately delivery of `ffs` to the `movement` mainnet by July 9, 2025. + +The roadmap is grouped into three non-consecutive stages: + +1. **Primitive**: development and testing of proof of concept implementations of FFS. +2. **General**: development and testing relying on the reference implementation of FFS and which is decoupled from Movement Lab's full node logic or any particular VM. +3. **Movement**: development and testing of FFS integrated with Movement Lab's full node logic and VM. + +The grouping is primarily motivated by the opportunities for community participation and usage of the FFS system in a manner that is decoupled from Movement Lab's full node logic. + +## Key Concepts +- **Staking Game**: An incentivized period of `ffs` staking participation which does not affect the security of a mainnet. Staking Games are used to collect data and research the outcomes of different `ffs` implementations. +- **Staking Games Ceremony**: A public, community engaged ceremony announcing the end of a period of staking games and reporting some initial results. +- **contract-based `ffs`**: `ffs` implementations which tabulate consensus in the contracts. +- **`baker-confirmations`**: `ffs` implementations which use zero-knowledge proofs to tabulate consensus. +- **acceptor features**: The set of features which are used to program various of the liveness-inducing acceptor role in the `ffs` system. +- **Fork Stake Problem**: the problem or problems relating to forking and distribution of stake under the `ffs` system, particularly concerning the decision by consuming dApps of the correct fork. +- **Great Feature Selection**: The process of choosing the desired features which will begin rolling out on Movement mainnet. + +## Primitive +The **Primitive** stage of the roadmap is focused on the development and testing of proof of concept implementations of FFS. These include various iterations of MCR, early integrations with Symbiotic, and other proof of concept implementations. + +The **Primitive** stage breaks the FFS implementation out from under the `movement` monorepo for the first time as the `ffs` repo. + +The **Primitive** stage features live contracts on the Ethereum mainnet, testnet, and Movement managed networks. + +The **Primitive** stage uses small allocations of MOVE token to incentivize real user participation. Tooling is skewed towards immediately facilitating user participation. + +The complete **Primitive** roadmap is available [here](primitive/README.md). + +## General +The **General** stage of the roadmap is focused on the development and testing of implementations of FFS which are decoupled from Movement Lab's full node logic or any particular VM. This primarily means cleaning up existing proof of concept implementations, proving their correctness, and designing a more modular API. The initial implementation [Baker Confirmations (ZK-FFS)](../README.md) also begins under this stage. + +The **General** stage seeks to establish the `ffs` repo as not only a reference implementation, but a stable third-party dependency for downstream projects. A separate `baker-confirmations` repo is created to house the implementation of Baker Confirmations (ZK-FFS). + +The **General** stage features live contracts on the Ethereum mainnet, testnet, and Movement managed networks as well as the deployment of a Baker Confirmations development network. + +The **General** stage uses larger allocations of MOVE token to incentivize real user participation. Tooling is developed for generalized adoption of the `ffs` and `baker-confirmations` repos. + +The complete **General** roadmap is available [here](general/README.md). + +## Movement +The **Movement** stage of the roadmap is focused on the development and testing of FFS integrated with Movement Lab's full node logic and VM. This primarily means integrating the `ffs` and `baker-confirmations` repos into the `movement` monorepo. + +The **Movement** stage features live contracts on the Ethereum mainnet, testnet, and Movement managed networks as well as the deployment of a Baker Confirmations development network. + +The **Movement** stage culminates in a the production rollout of Movement mainnet staking. + +The complete **Movement** roadmap is available [here](movement/README.md). + +## Key Milestones +- **February 24, 2025:** Movement Labs Research Team takes over FFS implementation under the `ffs` repo. Work begins to prepare existing MCR contracts for Staking Games I. +- **March 14, 2025:** Movement Labs MIP committee approves acceptor features MIPs for `ffs` post-confirmations. +- **March 17 - April 5, 2025:** Movement Labs Research Team launches [Staking Games I](./staking-games/staking-games-i/), planning to actively collect data through the March 18, 2025 deadline. +- **March 20, 2025:** Movement Labs Research team introduces `ffs` General Node type, which is an `ffs` node process decoupled from Movement Lab's full node logic. +- **March 24, 2025:** Movement Labs Research Team introduces the acceptor features upgrade for MCR, adding staking games for each feature combination. +- **March 25, 2025:** Movement Labs Research Team completes MIPs for contract-based `ffs`, providing an agreed upon set of solutions to the Fork Stake problem. +- **March 30, 2025:** Movement Labs Research Team w/ Symbiotic Releases Symbiotic Stake Staking Game. +- **April 1, 2025:** Movement Labs Research Team publishes Baker Confirmations reference implementation under the `baker-confirmations` repo. +- **April 5, 2025:** Movement Labs Research Team holds the Staking Games I Closing Ceremony, marking an end to active community support while results are reviewed. +- **April 10, 2025:** Movement Labs Research Team w/ Movement Labs SRE Team introduces FFS testing environment and node spin-up tooling for contract-based `ffs`. This includes a Kurtosis-based ETH testnet. +- **April 10 - April 29, 2025:** Movement Labs Research Team launches [Staking Games II](./staking-games/staking-games-ii/), planning to actively collect data through the April 9, 2025 deadline. +- **April 12, 2025:** Movement Labs Research Team introduces the `ffs` Fork Stake upgrade for contract-based `ffs`. This may immediately apply to Staking Games II. This provides the first stable implementation of post-confirmations in the `ffs` repo. +- **April 14, 2025:** Movement Labs Research Teams introduces first stable release of `ffs` repo. +- **April 18, 2025:** Movement Labs Research Team completes first community-ready version of `baker-confirmations` repo. +- **April 18, 2025:** Movement Labs Research Team holds the Staking Games II Closing Ceremony, marking an end to active community support while results are reviewed. +- **April 23, 2025:** Movement Labs Research Team stabilizes L2 Confirmations implementation in the `ffs` repo. +- **April 27, 2025:** Movement Labs Research Team and Movement Labs Engineering team release first integration of stable `ffs` with the `movement-full-node`. +- **April 29, 2025:** Movement Labs Research Team and Movement Labs SRE Team introduce FFS Research Kit, a suite of tools for researchers to run and test FFS implementations as will be leveraged in Staking Games III. +- **May 16 - June 10, 2025:** Movement Labs Research Team launches [Staking Games III](./staking-games/staking-games-iii/), planning to actively collect data through the June 10, 2025 deadline. +- **May 24, 2025:** Movement Labs Research Team releases stable implementation of the San Francisco Model in the `ffs` repo. +- **June 10, 2025:** Movement Labs Research Team releases stable implementation of the San Francisco Model in the `baker-confirmations` repo. +- **June 13, 2025:** Movement Labs Research Team holds the Staking Games III Closing Ceremony, marking an end to active community support while results are reviewed. +- **June 16, 2025:** Movement Labs Research Team and Movement Labs Engineering make the Great Feature Selection, choosing the desired features which will begin rolling out on Movement mainnet. +- **June 23, 2025:** Movement Labs Research Team and Movement Labs Engineering team release `ffs` version selected from the Great Feature Selection to `movement` testnet. +- **July 9, 2025:** Movement Labs Research Team and Movement Labs Engineering team release `ffs` version selected from the Great Feature Selection to `movement` mainnet. diff --git a/MIP/mip-103/roadmap/general/README.md b/MIP/mip-103/roadmap/general/README.md new file mode 100644 index 00000000..2bdb231c --- /dev/null +++ b/MIP/mip-103/roadmap/general/README.md @@ -0,0 +1,21 @@ +# General +The General stage of the roadmap is focused on the development and testing of implementations of FFS which are decoupled from Movement Lab's full node logic or any particular VM. This primarily means cleaning up existing proof of concept implementations, proving their correctness, and designing a more modular API. The initial implementation [Baker Confirmations (ZK-FFS)](../README.md) also begins under this stage. + +## Key Deliverables + +### contract-based `ffs` +1. Fork Stake Upgrade + - **Forks:** Adds abilities to represent forks on the `ffs` post-confirmations contract. + - **Fork Client:** Adds dedicated logic for fork selection to the client. +1. Stable Delegation Upgrade +1. `ffs` Node process and client library +1. Signature Aggregation Ceremony + +### `baker-confirmations` +1. Baker Coin Baker Confirmations +1. Baker Hooks Generalization +1. Baker Confirmations Network + +### Infrastructure +1. Kurtosis Networks +1. FFS Research Kit \ No newline at end of file diff --git a/MIP/mip-103/roadmap/key-concepts/README.md b/MIP/mip-103/roadmap/key-concepts/README.md new file mode 100644 index 00000000..e69de29b diff --git a/MIP/mip-103/roadmap/movement/README.md b/MIP/mip-103/roadmap/movement/README.md new file mode 100644 index 00000000..c0692003 --- /dev/null +++ b/MIP/mip-103/roadmap/movement/README.md @@ -0,0 +1 @@ +# Movement \ No newline at end of file diff --git a/MIP/mip-103/roadmap/primitive/README.md b/MIP/mip-103/roadmap/primitive/README.md new file mode 100644 index 00000000..1ee3aa4d --- /dev/null +++ b/MIP/mip-103/roadmap/primitive/README.md @@ -0,0 +1,13 @@ +# Primitive +The Primitive stage of the roadmap is focused on the development and testing of implementations of FFS which are decoupled from Movement Lab's full node logic or any particular VM. This primarily means cleaning up existing proof of concept implementations, proving their correctness, and designing a more modular API. The initial implementation [Baker Confirmations (ZK-FFS)](../README.md) also begins under this stage. + +## Key Deliverables + +### contract-based `ffs` +1. MCR +1. Acceptor Features Upgrade: + - **Acceptor Stake Feature:** Adds a stake requirement to the acceptor role. + - **Volunteer Acceptor Feature:** Determines whether volunteers can perform the acceptor role. + - **Acceptor Election Feature:** Performs on-chain election of the acceptor per epoch. + - **Acceptor Client:** Adds dedicated logic for the acceptor role to the client. +1. MCR Client Distribution \ No newline at end of file diff --git a/MIP/mip-103/roadmap/roadmap-summer.png b/MIP/mip-103/roadmap/roadmap-summer.png new file mode 100644 index 00000000..be890706 Binary files /dev/null and b/MIP/mip-103/roadmap/roadmap-summer.png differ diff --git a/MIP/mip-103/roadmap/staking-games/README.md b/MIP/mip-103/roadmap/staking-games/README.md new file mode 100644 index 00000000..e69de29b diff --git a/MIP/mip-103/roadmap/staking-games/staking-games-i/README.md b/MIP/mip-103/roadmap/staking-games/staking-games-i/README.md new file mode 100644 index 00000000..d007c3ce --- /dev/null +++ b/MIP/mip-103/roadmap/staking-games/staking-games-i/README.md @@ -0,0 +1,11 @@ +# Staking Games I +Staking Games I focus on the usage of early contract-based `ffs` implementations to collect data on the outcomes of different `ffs` implementations. The primary goal is to collect data on the Fork Stake Problem and to inform the Great Feature Selection. + +There are six Staking Games in Staking Games I: + +1. **Chaos Staking (1000 MOVE):** Participants encouraged to use any means to post to an MCR contract. Rewards are distributed by standard rewarding rules. +2. **Slack Channel Staking (2000 MOVE):** Participants use a Slack Bot to post different commitments to an MCR contract. Rewards are distributed by standard rewarding rules. +3. **Volunteer Brigade (3000 MOVE):** After the introduction of the acceptor features, an MCR contract is deployed for which rewards on performing the volunteer acceptor role may be heightened. +4. **Super Majority Attack (3000 MOVE):** Participants are split into two groups. One group is incentivized (outside the contract) to maintain an honest super-majority of stake and tally up as many commitments as possible. The other group is incentivized to attack the honest super-majority. +5. **Governor Exploits (5000 MOVE):** Administrative roles are passed around to different participants at different points in time. Commitments are made to an MCR contract with normal rewarding rules. The incentive is merely to take advantage of the administrative roles to augment the rewards. +6. **Symbiotic Stake (1000 MOVE):** Participants are incentivized to post arbitrary commitments via a live instance of the Symbiotic network which has mock MOVE token staked in it (real rewards issued after completion by Movement Labs Research Team). \ No newline at end of file diff --git a/MIP/mip-103/roadmap/staking-games/staking-games-ii/README.md b/MIP/mip-103/roadmap/staking-games/staking-games-ii/README.md new file mode 100644 index 00000000..934879bc --- /dev/null +++ b/MIP/mip-103/roadmap/staking-games/staking-games-ii/README.md @@ -0,0 +1,8 @@ +# Staking Games II +Staking Games II focuses on the usage the generalized implementation of `ffs` in the `ffs` repo to collect data on the outcomes of different `ffs` implementations. The primary goal is to collect data on the Fork Stake Problem and to inform the Great Feature Selection. + +There are three Staking Games in Staking Games II: + +1. **Chaos Staking (10000 MOVE):** Participants encouraged to use any means to post to an `ffs` post-confirmations contract. Rewards are distributed by standard rewarding rules. +2. **Longest Fork (20000 MOVE):** Participants are antagonistically incentivized to attempt to build the longest possible fork in an `ffs` post-confirmations contract which implements the Fork Stake upgrade. +3. **Tug of War (10000 MOVE):** Participants are split into teams. Each team has a set of commitments that they are incentivized to get accepted to the `ffs` post-confirmations contract. \ No newline at end of file diff --git a/MIP/mip-103/roadmap/staking-games/staking-games-iii/README.md b/MIP/mip-103/roadmap/staking-games/staking-games-iii/README.md new file mode 100644 index 00000000..8975477d --- /dev/null +++ b/MIP/mip-103/roadmap/staking-games/staking-games-iii/README.md @@ -0,0 +1,7 @@ +# Staking Games III +Staking Games III is a comprehensive suite of staking games designed to test and validate the effectiveness of various `ffs` implementations, `baker-confirmations`, and the `movement-full-node` integration. The primary goal is to gather empirical data on the Fork Stake Problem and to inform the Great Feature Selection. + +There are two Staking Games in Staking Games III: + +1. **Chaos Staking (50000 MOVE):** Participants are encouraged to use any means to post to an `ffs` post-confirmations contracts, `baker-confirmations` contracts, or the `movement-full-node`. Rewards are distributed by standard rewarding rules. +2. **Cracked Window (50000 MOVE):** Participants are additional rewards for demonstrating an induced inconsistency between L1 and L2 confirmations. \ No newline at end of file diff --git a/MIP/mip-103/rsc/baker-confirmations.png b/MIP/mip-103/rsc/baker-confirmations.png new file mode 100644 index 00000000..7dc428c3 Binary files /dev/null and b/MIP/mip-103/rsc/baker-confirmations.png differ