MD-7: Suzuka MEV

MD/md-1/README.md

@@ -0,0 +1,68 @@
+# MD-1: Minimize Risk of Compromised Bridge Key without Governance
+- **Description**: Provide a mechanism to minimize the risk of a compromised bridge key without relying on governance.
+- **Authors**: [Liam Monninger](mailto:[email protected])
+
+
+## Overview
+The Atomic Bridge service relies on trusted keys for relaying events between chains. Without governance or multisig contracts, the risk entailed by a compromised bridge key is significant. Even with logic safeguarding against direct mint operations, fraudulent events on either chain can still be synthesized. 
+
+The desiderata herein recognize standard governance as generally the best means of managing these kinds of risks in general. Specialized contracts can be used to accumulate votes and make it difficult for a single actor to compromise bridge security. 
+
+However, in the case of bridging, inactive or unreliable governance can be a significant risk as well. In effect, the changes represented by the in-flight message represent those already agreed upon by the destination chain's governance. These are then subject to a smaller, potentially less-secure governance process before being relayed to the destination chain. The risk of DOS attacks on this governance process is thus high.
+
+Until a robust design for relaying bridge messages based on votes is attained, bridge trust assumptions are offset by a presumed trustworthy bridge signing service which uses known keys that would be controlled by Movement Labs.
+
+This desiderata requests a means to minimize the risk of a compromised bridge key without relying on on-chain governance.
+
+## 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: Minimize Direct Access to Bridge Keys while Maintaining Use
+**User Journey**: Movement Labs Atomic Bridge Service Operators (MLABSO) can run the service with appropriate signing keys without direct access to said keys.
+
+**Justification**: Without direct access to the keys, MLABSO are forced to use a more secure mechanism for signing messages which can be more easily secured audited such as an HSM or enclave.
+
+### D2: Only Allow Attested Usage of Bridge Keys
+**User Journey**: Only attested software can use bridge keys.
+
+**Justification**: Even without direct access to the keys, MLABSO could still abuse bridge keys by abusing their access to the secure signing mechanism. Enforcing attestation of software using the keys can help mitigate this risk.
+
+### D3: Time-Lock Key Usage
+**User Journey**: MLABSO can only reliably replace software using a key in a time-locked manner.
+
+**Justification**: The software using a given key may require updates or replacement. Time-locking can allow this to occur without diminishing the benefits of attestations.
+
+## 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.
+-->

MD/md-4/READM.md

@@ -0,0 +1,62 @@
+# MD-4: MCR Offsetting Gas Costs
+- **Description**: Provide models for the game theory of offsetting gas costs in MCR.
+- **Authors**: [Liam Monninger](mailto:[email protected])
+
+
+## Overview
+In the current MCR implementation, the last attester which trips the `rollOverEpoch` function may pay large gas fees, as they perform roll-over work for previous participants. This would create a disincentive for the last attester to participate in the game, potentially not doing so at all. It has been presumed that the implementation would be updated s.t. the last attester would be specially rewarded for their work. This also creates a game-theoretic problem, as the last attester could be incentivized to wait until the last moment to participate.
+
+To combat this, round-robin rewarding and commitment schemes such as Pedersen Commitments have been suggested. However, these have not been formalized. 
+
+## 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: Model for Gas Costs in MCR without Offset
+**User Journey**: A researcher or protocol implementer can understand the game theory of gas costs in MCR without offsetting.
+
+**Justification**: The current implementation of MCR does not offset gas costs for the last attester. This could lead to a disincentive to participate in the game, provide a model which clearly shows this.
+
+### D2: Model for Gas Costs in MCR with Offset
+**User Journey**: A researcher or protocol implementer can understand the game theory of gas costs in MCR with offsetting.
+
+**Justification**: Naive proposals suggest simply offsetting the gas cost by rewarding the last attester transparently. Provide a model which demonstrates the game theory of this.
+
+### D3: Models for Information Incomplete Gas Cost Offset
+**User Journey**: A researcher or protocol implementer can understand the game theory of gas costs in MCR with incomplete information.
+
+**Justification**: Information incompleteness may improve the game theory of offsetting gas costs. Provide models which demonstrate this for incompleteness derived from (1) general network latency, (2) a round-robin rewarding scheme, and (3) a Pedersen Commitment scheme.
+
+## 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.
+-->

MD/md-6/README.md

@@ -0,0 +1,80 @@
+# MD-6: Suzuka Block Validation
+- **Description**: Provide means to validate blocks to prevent public DA DOS attacks.
+- **Authors**: [Liam Monninger](mailto:[email protected])
+
+
+## Overview
+The current implementation of the Suzuka Network relies on a public and permissionless DA. Anyone can submit batches to the DA. Blocks, that are created from these batches, are not further validated besides their correctness w.r.t. the Aptos executor. 
+
+This could lead to an unsophisticated DOS attack wherein the attacker simply spams the network with low gas fee--both on the DA and in the execution layer--blocks. A slightly more sophisticated attack would see the attack DOS the DA namespace itself in a [Woods Attack](https://forum.celestia.org/t/woods-attack-on-celestia/59).
+
+While we cannot prevent latter, providing solutions to the former may prove vital to fairness amongst genuine network participants.
+
+## 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: Model Transaction Fairness in Suzuka Network
+**User Journey**: A researcher or protocol implementer can understand what transaction fairness means in the Suzuka Network.
+
+**Justification**: Transaction fairness is a key component of any blockchain network. It is important to understand what it means in the context of the Suzuka Network.
+
+**Recommendations**:
+- The strongest form of formally defined fairness is currently [batch-order-fairness](https://link.springer.com/chapter/10.1007/978-3-030-56877-1_16). What would it mean for the Suzuka Network to achieve this. 
+- Transaction fairness should consider:
+    - Time in flight
+    - Congestion
+    - Ingress node
+    - Causality
+
+### D2: Accept Only Blocks Signed by Staked Validators
+**User Journey**: A proposer submits batches to the DA which will later be processed by the Aptos executor. A proposer must be a Suzuka validator.
+
+**Justification**: This will prevent DOS attacks on the network by requiring a stake to submit blocks.
+
+**Recommendations**:
+- Be sure to consider what is lost in this approach. For example, currently, a developer could bypass a Suzuka Full Node an submit directly to the DA--allowing them to avoid any potential censorship. This would be lost in a naive implementation of this approach, as they would be required to either (a) submit via a full-node or (b) stake themselves.
+
+### D3: Invalidation or Validator-slashing for Producing Unfair Blocks
+**User Journey**: Validators can be slashed for producing unfair blocks.
+
+**Justification**: This will disincentivize validators from producing unfair blocks.
+
+**Recommendations**:
+- This would be a highly experimental feature and should be researched and implemented with caution. 
+- Deterministic transaction and block ordering should cover most of the cases of unfairness. These are discussed in [MD-7](../md-7/README.md). However, in theory you could also slash on conditions like including too many transactions from one user, sending too many blocks at a given time, sending too few blocks at a given time, sending blocks of unequal size when transactions are available, etc.
+
+
+## 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.
+-->

MD/md-7/README.md

@@ -0,0 +1,131 @@
+# MD-7: Prevent Suzuka MEV Exploits and Censorship
+- **Description**: Provide an account of possible Suzuka MEV attacks and censorship vulnerabilities, and propose solutions to mitigate these risks.
+- **Authors**: [Liam Monninger](mailto:[email protected])
+
+## Definitions
+
+ * Node: An independent program that processes or utilizes trusted blockchain state. Examples of nodes include Light nodes, bootstrap nodes, Full nodes, and RPC nodes.
+ * Proposer / Sequencer: Receive Tx from users and proposes transactions to the DA (Data Availability layer).
+ * Validator: Validates the blockchain state to ensure it is trusted.
+ * Batch / Blob: A set of transactions aggregated by a proposer and sent to the DA.
+ * Block: A set of transactions that defines the minimum atomic state change and secures the blockchain.
+ * Sequence Numbers: Equivalent to Ethereum's Nonce for Aptos. A number that orders transactions sent by an account.
+ * Height: The DA orders its generated blocks by Height. The DA's internal process increases the height, and one to several blocks can belong to a given height.
+
+## Current process diagram
+```mermaid
+flowchart TD
+    subgraph User
+    end
+    subgraph Full node
+        subgraph Sequencer
+            sequencer("Sequencer/Proposer:
+            Receive Tx from users
+            Aggregate Tx in batch
+            Propose Tx Batch to the DA
+            ")
+        end
+        validator("Validator:
+            Validate block
+            Call executor
+            Settle block on chain
+            Manage states:
+            blocks / accounts
+        ")
+        executor("Executor:
+            Execute block
+            using Aptos Executor
+            Generate execution state
+        ")
+
+    end
+    subgraph DA
+        da("Celestia DA:
+            Receive batch of Tx
+            Aggregate Batch in Block
+            Entry point to get a block
+        ")
+    end
+    sequencer-- "Propose batch" --> da
+    validator-- "get blocks at height" --> da
+    validator<-- "Execute block" --> executor
+    User-- "Submit Tx" --> sequencer
+
+```
+
+## Overview
+The Suzuka Network is known to be subject to MEV exploits in the form of manipulating block size and order. That is, while transactions within a block are ordered deterministically, full nodes are currently given freedom to chose which transactions to include in a block and when to send those blocks to the network. Execution-level validation will only assert that the sequence numbers are appropriate and other dApp-specific logic. There are no penalties for being to have withheld a transaction. 
+
+The desiderata presented herein request a complete model of MEV in the Suzuka Network. They also make some provisional requests based on surmised ways to prevent certain MEV attacks.
+
+Most of the account of MEV attacks should be based on the model of transaction fairness given in [MD-6](../md-6/README.md).
+
+Many of MEV attacks addressed can also be classed as censorship attacks. That is, a miner can choose to not include a transaction in a block. This is a form of censorship. As such, the desiderata herein also address censorship attacks.
+
+## 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: Model Suzuka MEV Attacks
+**User Journey**: A researcher or protocol implementer can understand the game theory of MEV attacks in the Suzuka Network.
+
+**Justification**: Suzuka MEV attacks are a significant risk to the network. Understanding them is the first step to preventing them.
+
+**Recommendations**:
+- Begin be enumerating all of placers where a single entity has control over transaction inclusion or ordering. 
+- Evaluate how the history and origin of transactions can be tracked and recorded.
+
+### D2: Merge Blocks and Assign Deterministic Cut-points
+**User Journey**: An honest Suzuka Full Node can only form the final blocks needed for execution by (a) merging blocks in a given DA height range, (b) ordering transactions deterministically, and (c) assigning deterministic cut-points for block formation.
+
+**Justification**: If the blocks from a given DA height range are merged and then split with deterministic cut-points, a Suzuka Proposer would only be able to manipulate the inclusion or exclusion of a transaction in a given DA height range--no longer the order of blocks therein. This limitation of the action space could render most MEV attacks implausible--particularly if it increases the latency of an attack held across two block height ranges beyond the window in which the client would notice the failure and submit a transaction to an honest Suzuka Full Node.
+
+### D3: Induced Proposer Races for Fair Provenance
+**User Journey**: Suzuka Proposers are subject to a potentially race on each transaction whereby if each 
+
+**Justification**: This will disincentivize validators from producing unfair blocks.
+
+**Recommendations**:
+- This involves two primary innovations (1) making the transaction dataflow amenable to duplicate transactions and (2) providing reward or penalization controls applicable to the Proposer function similar to those referenced in [MD-6](../md-6/README.md).
+- A simple protocol could provide a provocative start:
+    1. The Client submits a signed transaction to a Suzuka Full Node.
+    2. The Suzuka Full Node signs this transaction and sends it back as confirmation to the Client.
+    3. The Client MAY optionally have submitted the same transaction to another Suzuka Full Node.
+    4. The DA records where the transaction was included and by which Proposer. The first propose to have submitted wins the race. Subsequent duplicates are ignored.
+    5. The state computed by the transactions in a block is eventually settled along with a set of signers who won their respective races.
+    6. The settlement contract rewards the winning Proposer. 
+
+
+## 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.
+-->