-
Notifications
You must be signed in to change notification settings - Fork 22
[Review] MD-38: Provide for Native Bridge and FFS Usage with Fixed Token Supply #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 6 commits
55393ec
37862ae
c86c75f
52ac7ab
1b7d247
1ddd68b
0d8ca21
83fdc18
16fb6d4
b29ace0
2a4f9df
b220b2f
0d2d300
0cfadad
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,76 @@ | ||||||||||||||||
| # MD-38: Provide for Fixed Token Supply when Using Atomic Bridge and Fast Finality Settlement (FFS) | ||||||||||||||||
| - **Description**: Requests for Movement Improvement Proposals (MIPs) to provide for fixed token supply when using the Atomic Bridge and Fast Finality Settlement (FFS). | ||||||||||||||||
| - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) | ||||||||||||||||
| - **Reviewer**: Andreas Penzkofer | ||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
| ## Overview | ||||||||||||||||
|  | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
| Using Fast Finality Settlement with the Atomic Bridge presents a challenge when the token supply is fixed. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The mention of FFS confused the context, i put it further down |
||||||||||||||||
|
|
||||||||||||||||
| Naively burning token on the L2 without a way to return it to either pools on the L2 or the L1 will result in a **deflationary token**, i.e., the supply decreases over time and eventually reaches 0 rendering any operations relying on gas impossible. Meanwhile, providing minting capabilities which involve the operation of fallible services can result in **either a deflationary or inflationary token** and the opportunity for **byzantine attacks**. | ||||||||||||||||
|
l-monninger marked this conversation as resolved.
Outdated
|
||||||||||||||||
|
|
||||||||||||||||
| Namely, in this context, trying to use the same token for both L2 gas and L1 rewards requires that the token be bridged back over or else rely on a trusted signer to relay the gas. This document outlines the challenges and potential solutions for this problem. | ||||||||||||||||
|
l-monninger marked this conversation as resolved.
Outdated
|
||||||||||||||||
|
|
||||||||||||||||
| Users of the Movement SDK should be **informed of different approaches and trade-offs when using the Atomic Bridge and Fast Finality Settlement with a fixed token supply.** This document provides an initial conceptual framing towards that end. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we frequently use the term approaches lateron.. its a bit hard to read so i suggest to explicitly remind the reader that the approaches mean aproaches for usage (of FFS and AB) |
||||||||||||||||
|
|
||||||||||||||||
| This document also seeks a response to the concerns raised in [MD-20](https://github.com/movementlabsxyz/MIP/pull/20). | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. abbreviations should be defined (unless they are in the glossary, which LP is not) |
||||||||||||||||
| ## Desiderata | ||||||||||||||||
|
|
||||||||||||||||
| ### D1: Provide MIPs for Approaches Presented in Appendix A1 and Similar | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **User Journey**: Developers can reference MIPs for **different approaches to using the Atomic Bridge and Fast Finality Settlement with a fixed token supply.** Developers can also **reference rejected MIPs** to understand why certain approaches are not recommended. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **Justification**: Developers need a clear understanding of the different approaches to using the Atomic Bridge and Fast Finality Settlement with a fixed token supply. MIPs provide a clear and standardized way to document these approaches. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| ### D2: Provide Staged Approaches for Networks Building on the Atomic Bridge and Fast Finality Settlement | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **User Journey**: Developers can reference approaches spawned from these desiderata to understand how to build networks using the Atomic Bridge and Fast Finality Settlement with a fixed token supply **in stages.** For example, developers can initially roll out a network using the **"Free Execution" approach and then transition to the "Noble Attester"** approach and so on. Some formats may be more suitable for certain stages of network development and release than others. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what is the "free execution"? |
||||||||||||||||
|
|
||||||||||||||||
| **Justification**: Developers need a clear understanding of how to build networks using the Atomic Bridge and Fast Finality Settlement with a fixed token supply in stages. This allows developers to roll out networks in a more controlled and manageable way. | ||||||||||||||||
|
|
||||||||||||||||
| **Recommendations**: | ||||||||||||||||
| - Ensure that achieving upgrades for each execution layer to support these transitions are also documented in MIPs. | ||||||||||||||||
|
|
||||||||||||||||
| ### D3: Provide Additional Software Necessary to Achieve Accepted Approaches in Movement SDK | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **User Journey**: Developers can use **modules from the Movement SDK** to achieve the approaches presented in Appendix A1 and similar. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **Justification**: Developers need a clear understanding of how to use the Movement SDK to achieve the approaches presented in Appendix A1 and similar. This allows developers to build networks using the Atomic Bridge and Fast Finality Settlement with a fixed token supply more easily. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| ### D3: Provide Guides and Software for Genesis Procedures and Initial Conditions of L1 and L2 Networks Using the Atomic Bridge and Fast Finality Settlement | ||||||||||||||||
|
|
||||||||||||||||
| **User Journey**: Developers can use guides and software from the Movement SDK to understand how to set up the **initial conditions of L1 and L2 networks** using the Atomic Bridge and Fast Finality Settlement. | ||||||||||||||||
|
|
||||||||||||||||
| **Justification**: Developers need a clear understanding of how to set up the initial conditions of L1 and L2 networks using the Atomic Bridge and Fast Finality Settlement. This allows developers to build networks using the Atomic Bridge and Fast Finality Settlement with a fixed token supply more easily. For example, one common approach will be to generate an initial supply on the L1 and run a privileged bridge and voucher swap exchange to the L2 such that overall circulation is grounded in the L1 mint. | ||||||||||||||||
|
l-monninger marked this conversation as resolved.
Outdated
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
| ## Errata | ||||||||||||||||
| <!-- | ||||||||||||||||
| Errata should be maintained after publication. | ||||||||||||||||
|
|
||||||||||||||||
| 1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information. | ||||||||||||||||
|
|
||||||||||||||||
| 2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights. | ||||||||||||||||
|
|
||||||||||||||||
| Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified. | ||||||||||||||||
|
|
||||||||||||||||
| TODO: Maintain this comment. | ||||||||||||||||
| --> | ||||||||||||||||
|
|
||||||||||||||||
| ## Appendix | ||||||||||||||||
|
|
||||||||||||||||
| ### A1: Suggested Solutions for Fixed Token Supply | ||||||||||||||||
|
|
||||||||||||||||
| | Name | Description | Gas Destination | Reward Form | Challenges | | ||||||||||||||||
| |-------------------|---------------------------------------|-----------------------|----------------------|-------------------------------------| | ||||||||||||||||
| | **Decoupled** | • Gas spent on the L2 deposited to pools on the L2. <br> • Rewards on the L1 are issued in a LP token which is demurrage. <br> • Ideally, intermediary tokens are used in the bridge to shield gas and staking token from bridge fallibility. | Pool on the L2 | FFS LP Token; voucher periods can be assigned. | • LP Token's demurrage assigns a lifetime to the viability of the settlement protocol which will require a new or asymptotic token voucher or token generation event at some point. | | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||||||||||||||||
| | **Trickle-back** | • Gas spent on the L2 recirculates to pools on the L2. <br> • Rewards are provided on the L2 for bridging back to the L1 at the address of the FFS LP Token. <br> • Ideally, intermediary tokens are used in the bridge to shield gas and staking token from bridge fallibility. | Pool on the L2 | Staking Token | • Rewards for pool providers to bridge back to the L1 at the address of the FFS LP Token need to be sufficient. <br> • Pool providers likely need to have only custodial access to token, otherwise intended rewarding game theory would likely be intractable. | | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Staking token is not defined - at least there should be a reference to the relevant document
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||
| | **Settle with Gas** | • The settlement messages include the amount of gas spent. The LP for the FFS claims token locked in the L1 bridge. <br> • Bridge may still benefit from intermediary tokens. | FFS LP Token | Staking Token | • Unclear how to handle forks. <br> • Centralization remains as FFS contract needs to have capability to claim token locked in L1 bridge. However, this can be governed on-chain in this case. <br> • Intermediary tokens can still help reduce attack surface via the bridge. Now attacks would likely focus on exploiting capabilities of the settlement contract to unlock token. | | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||||||||||||||||
| | **Noble Gasmaster** | • A trusted signer is responsible for successfully relaying gas spent. The use of intermediary tokens in the bridge is moot. | FFS LP Token | Staking Token | • Centralized signer. | | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. similar to the "acceptor" is there a way how any validator can be permitted to transfer L2 pool tokens to the L1 reward contract? (at the cost of L2fees and L1fees for that validator)? Similar to the Acceptor model, a L1-selected acceptor could be responsible for transferring rewards from L2 to L1, and get rewarded on L1 for this, however a volunteer could transfer also the L2RewardPool balance to the L1RewardPool balance (at their own cost) |
||||||||||||||||
| | **Free Execution** | • Execution does not charge gas fees, meaning gas token stays in circulation and supply does not change. | Nowhere | Staking Token or FFS LP Token | • No sybil resistance; not suitable for anything but promotional or initial stages of a network. <br> Gas fees do not contribute to rewards, so rewards rely solely on initial grant and perhaps LP. Execution does not have cost in token and so cannot drive work-based benefits in token. | | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. need a reference to a MD / MIP that exlpains Staking Token and FFS LP Token |
||||||||||||||||
| | **Gas Lock** | • Execution does not charge permanent gas fees, meaning gas token stays in circulation and supply does not change. <br> Gas for a transaction gets locked away until a time or block lock expires and then is returned to the account. | Nowhere/Temporary Lock | Staking Token or FFS LP Token | • Sybil resistance effectively only applies over the window of the time-lock or the amortized windows of the time-locks. Game theory is more complex for standard gas attacks. <br> • Gas fees do not contribute to rewards, so rewards rely solely on initial grant and perhaps LP. Execution does not have ultimate cost in token and so cannot drive work-based benefits in token. | | ||||||||||||||||
|
|
||||||||||||||||
Uh oh!
There was an error while loading. Please reload this page.