[review] MIP-49: NB-FFS Governed Rewards and Fees

MD/md-n/README.md

@@ -0,0 +1,78 @@
+# MD-15: Movement L2 Gas Fees
+- **Description**: Provide a means of computing, charging, and distributing gas fees for the Movement L2s which rely on a separate DA and Settlement Layer, e.g., the Movement Network.
+- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz)
+- **Reviewer**: Andreas Penzkofer
+
+
+## Overview
+In order to understand how to fairly and effectively incentivize participation in the Movement Network, we need to establish a means of computing, charging, and distributing gas fees for the Movement L2s which rely on a separate DA and Settlement Layer. This will allow us to ensure that the Movement Network is able to operate efficiently and that the incentives for participation are aligned with the goals of the Movement Network.
+
+The work done in a Movement Network L2 is mostly outlined in [MIP-19](https://github.com/movementlabsxyz/MIP/pull/19). These desiderata request means to actually compute said work, charge proportional gas fees, and distribute these fees to the appropriate parties.
+
+## Desiderata
+
+<!--
+  List out the specific desiderata. Each entry should consist of:
+
+  1. Title: A concise name for the desideratum.
+  2. User Journey: A one or two-sentence statement focusing on the "user" (could be a human, machine, software, etc.) and their interaction or experience.
+  3. Description (optional): A more detailed explanation if needed.
+  4. Justification: The reasoning behind the desideratum. Why is it necessary or desired?
+  5. Recommendations (optional): Suggestions or guidance related to the desideratum.
+
+  Format as:
+
+  ### Desideratum Title
+
+  **User Journey**: [user] can [action].
+
+  **Description**: <More detailed explanation if needed (optional)>
+
+  **Justification**: <Why this is a significant or required desideratum>
+
+  **Recommendations**: <Any specific guidance or suggestions (optional)>
+
+  TODO: Remove this comment before finalizing.
+-->
+### D1: Specify How to Compute Execution Fees for a Movement L2
+
+**User Journey**: A developer can implement execution fee computation for a Movement L2 from a specification thereof.
+
+**Justification**:  [MIP-19](https://github.com/movementlabsxyz/MIP/pull/19) categorizes execution fees as "the costs that correspond to resources usage, CPU and permanent storage." These need to be accounted for in any system to ensure the operators of nodes are appropriately incentivized for their participation and the fairness of resource usage is maintained.
+
+### D2: Specify How to Compute DA Gas Fees for a Movement L2
+
+**User Journey**: A developer can implement DA fee computation for a Movement L2 from a specification thereof.
+
+**Justification**:  [MIP-19](https://github.com/movementlabsxyz/MIP/pull/19) categorizes DA fees as "the costs of publishing transactions/blocks data to a data availability layer." These are considered separately from execution fees because the DA is expected to be a extrinsic system with its own fee model.
+
+### D3: Specify How to Compute Settle Gas Fees for a Movement L2
+
+**User Journey**: A developer can implement settlement fee computation for a Movement L2 from a specification thereof.
+
+**Justification**: [MIP-19](https://github.com/movementlabsxyz/MIP/pull/19) categorizes DA fees as "the costs of validating a transaction (e.g. zk-proof generation and verification, validators attestations)." These are considered separately from execution fees because settlement is expected to be a extrinsic system with its own fee model.
+
+### D4: Specify which Participants Should Be Charged which Gas Fees
+
+**User Journey**: A network participant can understand which fees they are responsible for.
+
+**Justification**: Costs can be passed through to various actors in the L2 system. It is important to specify which actors are responsible for which fees to ensure that the system is fair and that the incentives for participation are aligned with the goals of the Movement Network.
+
+### D5: Specify How to Distribute Gas Fees to the Appropriate Parties
+
+**User Journey**: A network participant can understand how gas fees are distributed.
+
+**Justification**: Gas fees must ultimately be used to pay extrinsic costs or else be considered as rewards. It is important to specify how gas fees are distributed to ensure that the system is fair and that the incentives for participation are aligned with the goals of the Movement Network.
+
+## 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.
+-->

MIP/mip-n/README.md

@@ -0,0 +1,110 @@
+# MIP-49: AB-FFS Governed Fees and Rewards
+- **Description**: Proposes a fee model which prioritizes using governance to adjust FFS rewards in an AB-FFS L2 system.
+- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz)
+- **Reviewer**: Andreas Penzkofer
+- **Desiderata**: [MD-49](../MD/md-n/README.md)
+
+## Abstract
+
+In response to [MD-49](../MD/md-n/README.md), we propose a fee model for an AB-FFS L2 system which interprets all fees as compensated for in gas fees, bridge fees, or FFS rewards which are adjusted by a governing body. We argue that this approach avoids many of the security and fairness issues that arise in more complex fee models, and is analogous to fee models used in traditional L1 systems. We provide an account of the complexity of other fee models and the limitations from which even theses models suffer. We exemplify these limitations by describing an AB-FFS system which uses Celestia as DA and Ethereum as the Settlement Layer.
+
+## Motivation
+
+[MD-49](../MD/md-n/README.md) requests a means of computing, charging, and distributing gas fees for the Movement L2s which rely on a separate DA and Settlement Layer. We provide such means for an AB-FFS system.
+
+## Specification
+
+![AB-FFS Governed Fees and Rewards](governed-fees-and-rewards.png)
+
+### Definitions
+- **FFS reward**: a reward paid to a node operator in either the separate `L1RewardToken` or the `L1StakingToken` for participating in the network.
+- **L2 client**: the end user of the L2 network who pays gas fees from their L2 wallet.
+- **validator**: a node operator who runs a node participating in Execution, DA, and Settlement.
+- **delegator**: a staking participant who delegates their stake to a validator.
+- **bridge client**: the user of the bridge service who issues transactions on a source chain to be transferred to a destination chain.
+- **bridge operator**: the operator of the bridge service who charges fees for transferring assets between chains.
+
+### Requirements 
+An AB-FFS Governed Reward system will meet the following requirements:
+
+1. An AB-FFS Governed Rewards system SHALL idenitfy four operators to whom fees may be charged or rewards may be paid: L2 clients, validators, delegators, and bridge operators.
+2. An AB-FFS Governed Rewards system MUST provide a means for the governing body, e.g., Movement Labs to adjust FFS reward parameters according to a vote. This is intended to ensure the value of the FFS rewards exceeds difficult to compute costs of operating as a participant in the L2 system.
+3. An AB-FFS Governed Rewards system MUST provide a means for the governing body to adjust the gas fees charged to L2 clients according to a vot. This is intended to ensure that the cost of using the L2 system is competitive with other systems.
+4. An AB-FFS Governed Rewards system MUST provide a means for the governing body to adjust the fees charged to bridge clients according to a vote. This is intended to ensure that the cost of using the bridge service is competitive with other systems.
+5. An AB-FFS Governed Rewards system SHALL compensate validators as a function of expected settlement and DA costs with FFS rewards, but does not need to recompute this expectations. 
+6. An AB-FFS Governed Rewards system SHALL compensate bridge operators with collected gas fees, but does not need to recompute these fees.
+7. An AB-FFS Governed Rewards system MUST transfer gas fees into a [Governed Gas Pool](https://github.com/movementlabsxyz/MIP/pulls) which SHALL be used to add additional rewards to the FFS rewards pool when needed. 
+
+### Costs and Computability
+
+#### Execution Costs
+Execution costs MAY be computed using a VM gas algebra similar to those used in L1 protocols. These costs are intrinsic to the L2 system and are naturally paid by clients.
+
+For example, under AB-FFS Governed Fees and Rewards, the [Aptos Gas Algebra](https://aptos.dev/en/network/blockchain/base-gas) should be used to compute execution costs.
+
+**Proportionality of Execution Costs to DA Costs**:
+In the event that the gas algebra renders a cost proportional to the byte size of the transaction, this cost can be seen as accounting for some of the DA costs. For example, the "payload" summands in the Aptos Gas Algebra can be seen as accounting for some of the DA costs. 
+
+Since gas fees are then paid into the Governed Gas Pool which is eventually used to fund the FFS Rewards Pool, we identify that proper adjustment of the FFS rewards for operators can partially be accounting for by execution gas fees. However, we suggest this as a reliable means of ensuring the availability of proportional funds for the FFS rewards pool, not as a means of directly compensating operators.
+
+**Proportionality of Execution Costs to Settlement Costs**:
+We do not expect the gas algebra to account for settlement costs. Under FFS, settlement costs proportional to the number of validators. The size of an individual attestation is fixed and rendered for a **block range**. Thus, larger transactions will not incur larger settlement costs than smaller transactions.
+
+#### DA Costs
+Under AB-FFS Governed Fees and Rewards, DA fee computation MUST not actively use an oracle or other live pricing model to introduce DA fees directly as **L2 client** gas fees. The security concerns of using an oracle to compute DA are commented on below. Instead, AB-FFS Governed Fees and Rewards recommends regarding the DA fee passed to **L2 clients** as 0, and the DA fee passed to **validators** as whatever the extrinsic system charges.
+
+As idenitfied in [MIP-19](https://github.com/movementlabsxyz/MIP/pulls), in general, DA costs will be proportional to the byte size of a transaction. However, many DAs implement a gas priority system that effectively introduces additional fees for network congestion. These fees are difficutl to anticiptate and are often unbounded. 
+
+For example, in Celestia, fees take the following [form](https://docs.celestia.org/how-to-guides/submit-data):
+
+```math
+\text{Total Fee} = \text{Gas Limit} * \text{Gas Price}
+```
+
+where: 
+    - `Gas Limit` is the maximum amount of gas that can be used for the transaction and is proportional to the byte size of the transaction.
+    - `Gas Price` is a price set by the user to incentivize validators to include the transaction in the next block.
+
+#### Settlement Costs
+Under AB-FFS Governed Fees and Rewards, settlement fee computation MUST not actively use an oracle or other live pricing model to introduce settlement fees directly as **L2 client** gas fees. The security concerns of using an oracle to compute settlement fees are commented on below. Instead, AB-FFS Governed Fees and Rewards recommends regarding the settlement fee passed to **L2 clients** as 0, and the settlement fee passed to **validators** as whatever the extrinsic system charges.
+
+In general, settlement costs can be modeled in the following form:
+
+```math
+\text{Settlement Cost} = \text{Number of Validators} * \text{L1 Gas Fee}
+```
+
+where:
+    - `Number of Validators` is the number of validators participating in the settlement.
+    - `L1 Gas Fee` is the gas fee charged by the Settlement Layer.
+
+While the size of an FFS attestion is constant for any transaction. `L1 Gas Fee` is not. Most L1s including, ETH, have implemented either gas priority systems or dynamic gas fees.
+
+
+### Comparisons to Other Fee Models
+
+#### Oracle-Based Fee Models
+In contrast to AB-FFS Governed Fees and Rewards, oracle-based fee models attempt to actively price **L2 client** gas fees according to the costs of operating the L2 system via both (1) the estimation or computation of DA and Settlement costs and (2) the computation of the value of the L2 gas token in terms of the DA and Settlement Layer gas tokens.
+
+Above, we discussed why it is difficult to anticipate DA and Settlement costs. While the former can be forgone in the event that the DA is always finalized before execution, the latter cannot as execution must occur before settlement.
+
+Additionally, however, using an oracle model introduces complexity and ultimately set of security risks.
+
+If the oracle model is trusted to appropriately account for the conversion rate between the L2 gas token and the DA and Settlement Layer gas tokens, then the oracle model is a single point of failure. If the oracle model is trusted, then the system is vulnerable to manipulation by the oracle.
+
+#### Wrapped Token Fee Models
+In contrast to AB-FFS Governed Fees and Rewards, wrapped token fee models attempt to wrap L2 transactions with corresponding DA and Settlement transactions, or else require native inclusion of requisite gas tokens in the L2 system.
+
+However, while DA fees can be known at execution, Settlement fees cannot. Thus, the wrapped token model would only account for tight bound on DA costs and would need to adopt a pessimistic model for Settlement costs. This would result in overcharging for Settlement costs.
+
+## Reference Implementation
+
+
+## Verification
+
+
+
+## Errata
+
+
+## Appendix