[draft] MIP-103: Baker Confirmations (ZK-FFS) #103
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,82 @@ | ||
| # Roadmap | ||
|  | ||
|
|
||
| > [!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. | ||
|
Contributor
There was a problem hiding this comment. would you class this as the prototype stage? would be more clear than General. it looks like prototype as its decoupled from full node logic
Contributor
Author
There was a problem hiding this comment. Prototype isn't quite the ambition. It's more a push to extract FFS as a generalizable software. All of what's leading up to that in development is essentially a prototype. |
||
| 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. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 |
Empty file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| # Movement |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
|
Contributor
There was a problem hiding this comment. should start to think of a suitable name, rather than Multi-Commit-Rollup.
Contributor
Author
There was a problem hiding this comment. Yeah, I mean MCR is just what we'll keep for that first contract we share for the games as it is what that implementation was originally called and we're not planning to keep it. |
||
| 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 | ||
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Empty file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should distinguish clearly between a confirmation layer and a finality layer. E.g. Fastconfirmations are a confirmation layer, whereas Postconfirmations are a settlement layer (think finality).
Why is this important ? Because the final say is by the settlement layer (the base truth). Would the settlement layer reorg, so would have to do the confirmation layer (ideally with no consequence on the transaction order, but possibly with impact on e.g. hashes - for example if the confirmation layer intakes finalization data from L1.)
Maybe the following is representive of this
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so are you referring here to the confirmation system or the finality system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, in the long run because of generalization, I was actually thinking we might benefit from a new term because of confusion this can cause. I've used "Confirmations" as the general term here because every layer involved uses this voting mechanism to confirm that a certain state has been reached, whichever one is the ultimate is finality.
In other words, not all confirmations are finalizations, but a finalization is a confirmation.