diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 86530438..33eddf40 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -6,9 +6,10 @@ /MIP/mip-0/ @l-monninger @apenzk /MD/md-0/ @l-monninger @apenzk /MG/mg-0/ @l-monninger @apenzk -/MIP/mip1/ @l-monninger +/MIP/mip-1/ @l-monninger /MD/md-3/ @l-monninger /MIP/mip-15/ @l-monninger @apenzk /MD/md-15/ @l-monninger @apenzk /MIP/mip-39/ @franck44 /MIP/mip-53/ @l-monninger +/MIP/mip-58/ @primata @apenzk diff --git a/.vscode/settings.json b/.vscode/settings.json index 5e737fce..f43d1930 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,4 +1,5 @@ { "stm32-for-vscode.openOCDPath": false, - "stm32-for-vscode.armToolchainPath": false + "stm32-for-vscode.armToolchainPath": false, + "spellright.userDictionary": "${workspaceFolder}/.vscode/spellright.dict" } \ No newline at end of file diff --git a/.vscode/spellright.dict b/.vscode/spellright.dict new file mode 100644 index 00000000..9e44b122 --- /dev/null +++ b/.vscode/spellright.dict @@ -0,0 +1,5 @@ +Fastconfirmation +multisig +timelock +timelocks +trustlessness diff --git a/MIP/mip-0/README.md b/MIP/mip-0/README.md index fd0c5bae..cca17daf 100644 --- a/MIP/mip-0/README.md +++ b/MIP/mip-0/README.md @@ -1,7 +1,8 @@ # MIP-0: Formalize Movement Proposals -- **Description**: A process through with Movement Improvement Proposals standardize and formalize specifications for Movement technologies. -- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz), [Andreas Penzkofer](mailto:andreas.penzkofer@movementlabs.xyz) -- **Desiderata**: [MD-0](../MD/md-0) + +- **Description**: A process through which Movement Improvement Proposals standardize and formalize specifications for Movement technologies. +- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz), Andreas Penzkofer +- **Desiderata**: [MD-0](../../MD/md-0) ## Abstract diff --git a/MIP/mip-1/README.md b/MIP/mip-1/README.md index 7f4691ec..82535703 100644 --- a/MIP/mip-1/README.md +++ b/MIP/mip-1/README.md @@ -14,7 +14,7 @@ This protocol was originally suggested as a solution to minimizing trust assumpt ## Specification -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. +_The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174._ ### Protocol Description @@ -33,6 +33,7 @@ The following messages types are exchanged between the Enclave and the Client: These messages are exchanged as follows: **Synchronization Phase** + 1. Prior to sending its first application message, the Client generates and safely stores CSPRNG nonce and sends it to the Enclave in a SYN message. 2. The Enclave processes the SYN message: - If enclave does not have a stored nonce, this indicates that no other client has attempted to synchronize with the Enclave. The Enclave MUST accept the nonce, store the nonce, and respond with a SYN-OK message. @@ -41,6 +42,7 @@ These messages are exchanged as follows: - If the nonce is not at the top of the queue or has not passed its time-lock, the Enclave MUST respond with a SYN-TL message. **Application Phase** + 1. The Client sends an APP message to the Enclave with the application message and the nonce for the current message and the nonce for the next message. 2. The Enclave processes the APP message: - If the nonce for the current message is the expected nonce, the Enclave MUST process the application message and update the nonce for the next message. It MUST responds with an APP-OK message. @@ -66,9 +68,11 @@ A MLABSO is informed that the bridge service needs to be upgraded. Because the p Now, a malicious MLABSO decides to attempt to abuse the key. She knows she cannot directly access the key. She also knows that she will not be able to use the key until the program has synchronized to a nonce she controls. She deems discovering or replacing the nonce used in the existing program intractable. So, she must stop the service and start a new synchronization phase. This will time-lock the service for 20 minutes. However, in the end, she will have the ability to sign with the key. The MLABSO begins the synchronization phase. However, during this time, a legitimate MLABSO notices that the bridge service is being upgraded (perhaps even that it is down). The legitimate MLABSO then reviews access logs to discover the malicious MLABSO's actions. The malicious MLABSO and her program are then removed from the system before the new bridge service can be synchronized. ### Practical Considerations -In practice, there are several phenomena regarded as external to the ENTL protocol which need to be considered in order to make it safely usable. + +In practice, there are several phenomena regarded as external to the ENTL protocol which need to be considered in order to make it safely usable. #### Securing the Nonce + In order to avoid the possibility of malicious usage, both the current nonce and the next nonce need to be stored in a manner that is difficult to access except by the current program. We do not intend to impose cryptographically secure requirements on this storage, as that begins to invoke concepts related to the literature on succinct arguments for programs. However, there are several simpler ways that can make accessing the and using the outside nonce difficult. To describe these, it first helps to consider what enables a nonce attack and to consider the time these operations take. diff --git a/MIP/mip-15/README.md b/MIP/mip-15/README.md index 318f37a9..6c56cd88 100644 --- a/MIP/mip-15/README.md +++ b/MIP/mip-15/README.md @@ -1,4 +1,5 @@ # MIP-15: MG (Movement Gloss) + - **Description**: Introduces the Movement Gloss (MG) document type and establishes a process for introducing new glossary terms. Introduces the [Glossary](../GLOSSARY.md), which contains an overview of all terms defined through MGs. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) - **Reviewer**: Andreas Penzkofer @@ -18,23 +19,27 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Glossary -The [Glossary](../GLOSSARY.md) is an alphabetically ordered list of terms defined through MGs. Any term introduced through an MG MUST be declared in the Glossary. +The [Glossary](../GLOSSARY.md) is an alphabetically ordered list of terms defined through MGs. Any term introduced through an MG MUST be declared in the Glossary. The Glossary table contains the following columns: + - The Term - A short definition - The number of the MG that introduces the term ### MG Document Type + A template for the MG is provided at [mg-template](../../md-template.md). An example MG is provided at [mg-0](../../MG/mg-0/README.md). These templates cover the requested elements listed in [MD-15.D1](../MD/md-15/README.md). ### MG Process + 1. A new glossary term MUST be defined in an MG document matching the provided templates. 2. An MG document MUST not be accepted unless justified in an MIP. -For example, herein, we justify the introduction of [MG-0](../../MG/mg-0/README.md). MG-0 defines the term "gloss" which is used in the context of Movement Labs to denote the definition of a term as would feature as an entry in a glossary. It is important to include in the glossary both clarify as the acronym "MG" and to provide an example gloss. +For example, herein, we justify the introduction of [MG-0](../../MG/mg-0/README.md). MG-0 defines the term "gloss" which is used in the context of Movement Labs to denote the definition of a term as would feature as an entry in a glossary. It is important to include in the glossary both clarify as the acronym "MG" and to provide an example gloss. ## Reference Implementation + See the MG document type template at [mg-template](../../md-template.md) and the example MG at [mg-0](../../MG/mg-0/README.md). ## Verification diff --git a/MIP/mip-39/README.md b/MIP/mip-39/README.md index cf5610a7..4f316397 100644 --- a/MIP/mip-39/README.md +++ b/MIP/mip-39/README.md @@ -17,7 +17,7 @@ This MIP describes the high-level architecture of the [HTLC-based](https://bitco The Movement chain (L2) uses the \$L2MOVE token to pay for gas fees. As a result users need to hold \$L2MOVE tokens to pay for their transactions. -> [!IMPORTANT] +> [!IMPORTANT] > The _native_ \$L1MOVE token is an ERC-20 contract on Ethereum (L1). By native, we mean that this is the location where the token is minted and burned and where the total supply is set and possibly modified (inflation/deflation). The **\$L1MOVE token reserve** is in the L1 contract. To use the Movement chain and pay for gas fees, a user will acquire \$L1MOVE (native) tokens on L1, and _bridge_ them to L2. On the L2 they can use the token to pay for gas fees or with any other dApps that transact the \$L2MOVE token. @@ -282,7 +282,7 @@ To reproduce the results and check the properties on the model, you need a worki The results of the model-checking verification are as follows: let $maxRelayerDelay $ be the **maximum delay** for the relayer to relay an event, and $timeLock1$ and $timeLock2$ be the timelocks on L1 and L2 respectively. -> [!IMPORTANT] +> [!IMPORTANT] > **Verification results** > We have **proved** (model-checked with UPPAAL) the following properties (valid using the versions of the contracts below): > diff --git a/MIP/mip-53/README.md b/MIP/mip-53/README.md index 40b231ac..d7082402 100644 --- a/MIP/mip-53/README.md +++ b/MIP/mip-53/README.md @@ -1,8 +1,8 @@ # MIP-53: Conventions for Proposing Progressive L2 Models + - **Description**: Introduces conventions for proposing progressive L2 models. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) -- **Reviewer**: [Andreas Penzkofer](mailto:andreas.penzkofer@movementlabs.xyz) -- **Desiderata**: $\emptyset$ +- **Reviewer**: Andreas Penzkofer ## Abstract @@ -15,6 +15,7 @@ We propose a set of conventions including naming, formatting, and related standa In order to facilitate the development of L2 systems, it is important to have a clear and consistent way to propose and review models for these systems. This MIP aims to provide a set of conventions for proposing progressive L2 models that will help to ensure that proposals are clear, consistent, and easy to review. ## Specification + Progressive L2 models should adhere to conventions of the following forms: - **naming**: apply a standard naming format. @@ -24,11 +25,13 @@ Progressive L2 models should adhere to conventions of the following forms: - **pros and cons**: a list of pros and cons. ### Naming -All proposed progressive L2 models MUST adopt a name of the form "The [Location] Model" where [Location] is a location where the proposal was drafted or a similarly symbolic location. This name should be the title of the associated MIP. -In text, the model SHOULD be referred to as "[Location] Model," that is, the name of the model in title case. +All proposed progressive L2 models MUST adopt a name of the form "The [Location] Model" where [Location] is a location where the proposal was drafted or a similarly symbolic location. This name should be the title of the associated MIP. + +In text, the model SHOULD be referred to as "[Location] Model," that is, the name of the model in title case. ### Acknowledgement of Standards + At the start of the "Specification" section of the MIP, the author MUST include the following markdown snippet: ``` @@ -36,6 +39,7 @@ We acknowledge and apply the conventions of [MIP-53: Conventions for Proposing P ``` ### Summary Table + All proposed progressive L2 models MUST complete the following table: | Category | Criterion | Evaluation | @@ -51,9 +55,11 @@ All proposed progressive L2 models MUST complete the following table: |X| [Component Name 2](link/to/component/design) | A description of usage of said component. | ### Statement Towards Progression + All proposed progressive L2 models MUST include a statement of how the model suits a progressive approach to L2 design and release. This statement SHOULD be a paragraph in length and immediately follow the summary table--as if it were a caption for the table. ### Pros and Cons + All proposed progressive L2 models MUST include a list of pros and cons. This list SHOULD be formatted as two separate bulleted lists in subsections titled "Pros" and "Cons." ## Verification diff --git a/MIP/mip-58/L1ToL2.png b/MIP/mip-58/L1ToL2.png new file mode 100644 index 00000000..7a5e273e Binary files /dev/null and b/MIP/mip-58/L1ToL2.png differ diff --git a/MIP/mip-58/L2ToL1.png b/MIP/mip-58/L2ToL1.png new file mode 100644 index 00000000..44d0c061 Binary files /dev/null and b/MIP/mip-58/L2ToL1.png differ diff --git a/MIP/mip-58/README.md b/MIP/mip-58/README.md new file mode 100644 index 00000000..a6a7a941 --- /dev/null +++ b/MIP/mip-58/README.md @@ -0,0 +1,304 @@ +# MIP-58: Lock/Mint-type Native Bridge with trusted Relayer + +- **Description**: Proposes a lock/mint-type Native Bridge that capitalizes on the trust-assumption on the Relayer. +- **Authors**: [Primata](mailto:primata@movementlabs.xyz), Andreas Penzkofer + +## Abstract + +We propose a lock/mint-type Native Bridge. The lock/mint bridge design streamlines operations, enhances security, and improves user experience (compared to the previously employed HTLC-based Native Bridge) making it easier to bridge assets between chains. + +## Motivation + +Different types of bridges have been considered for the Native Bridge, see [MIP-60](https://github.com/movementlabsxyz/MIP/pull/60). The initial design employed a HTLC-based bridge, which has been found to lead to bad UX, requires four transactions, and a complex design. + +This proposal advocates for replacing the current HTLC-based bridge design, with a lock/mint-type bridge with a simpler and more efficient two-transaction mechanism. The proposed design reduces costs, enhances security, minimizes user friction, and avoids potential exploits caused by refund logic. It addresses long-standing issues such as reliance on sponsored transactions, outdated audits, and unimplemented fee mechanisms speeding the process to achieve a fully functional bridge that movement yet has been unable to complete, and lots of under issues raised and still pending. + +**Reminder: HTLC-based bridge** + +The HTLC-type Native Bridge design poses numerous challenges, including inefficiency, cost, and user frustration: + +1. **Transaction complexity** +Requires four interactions: + - Two by the user (initiate the transfer and finalize the transfer). + - One by the Relayer to complete the transfer. + - One by a third party (tasked to the Relayer) to finalize refunds in case of failure. + - If any of these fails, users and the operator face losses. +2. **High cost** + - The multi-transaction setup is expensive for both users and the operator. + - Estimations in fee calculation that are too far off can result in significant losses. + - If fees are miscalculated by 25\%, this leads to a 25\% loss. When L1 fees increase, the loss can escalate dramatically in absolute terms. +3. **Unfriendly user experience** + - The current design requires users to have funds on the target chain for finalization. This increases friction and discourages adoption. + - Sponsored transactions are essential to the current implementation but remain unimplemented, leaving users stranded without funds. +4. **Security risks** + - Relayer keys are a critical point of failure. This assumption cannot be avoided. + - Refund logic introduces vulnerabilities where attackers could exploit the rate limit and Relayer downtime. + - For instance, if the Relayer fails to finalize on the initiator, a malicious actor could: + - Take over the refund keys. + - Exploit both directions of the bridge (e.g., \$L1MOVE→\$L2MOVE and \$L2MOVE→\$L1MOVE) repeatedly, draining funds. +5. **Maintenance burden** + - The current design requires a complete UI/UX overhaul, adding complexity and delay. +6. **Unnecessary complexity** + - HTLC-based bridges are largely abandoned in favor of simpler, more effective designs. + - Examples like the [Consensys HTLC](https://github.com/Consensys/htlc-bridge) bridge demonstrate the [pitfalls of such approaches](https://entethalliance.org/crosschain-bridges-overview-where-we-are-now/). +7. **Infrastructure simplification** + - Infrastructure is still incomplete for the current HTLC bridge design and we are struggling to find sound solutions that balance UI/UX and security. For example, [this issue](https://github.com/movementlabsxyz/movement/issues/838) regarding UX vs number of confirmations to require on the Ethereum side, is still under debate. + - Because of the over-engineered design, infrastructure is prone to error and we might end up being damaged by the amount of infrastructure we have not built yet and has to be built for the Relayer to fully function. + - We could strip down the Relayer code and achieve a final design much more quickly. + +**Protocol simplification (compared to HTLC-based Native Bridge)** + +The proposed lock/mint bridge design mitigates these issues, creating a safer, faster, and user-friendly bridge while maintaining operational reliability. + +- Combine lock and completion functionality on the counterparty contract. +- Remove refund logic to streamline operations and improve security. +- Cheaper transactions because of reduction of logic. +- Consolidate Initiator and Counterparty into a single contract (this might be the most dangerous thing proposed but it has already been proposed for HTLC Native Bridge implementation). + +## Specification + +The lock/mint bridge design focuses on minimizing complexity and maximizing security. It also leverages the trust assumption on the Relayer to streamline operations and enhance user experience. + +### Components + +The following components are involved + +**L1 Native Bridge contract** +The contract to which a user can request a bridge transfer L1→L2 and through which the Relayer completes transfers L2→L1. + +**L2 Native Bridge contract** +The contract to which a user can request a bridge transfer L2→L1 and through which the Relayer completes transfers L1→L2. + +**L1 token pool** +An address which collects \$L1MOVE that are transferred L1→L2 and from which tokens are released when transferred L2→L1. + +**L2 Mint contract** +A contract capable of minting \$L2MOVE. + +**Governance operator** +An entity that can set the bridge fee and adjust the rate limit. + +**Rate limiter** +A mechanism that limits the number of tokens that can be transferred. The rate limitation is discussed in [MIP-74](https://github.com/movementlabsxyz/MIP/pull/74). + +**(Partially Trusted) Relayer** +An off-chain partially trusted component (except for bugs or theft of keys) that can read relevant events from either chain and processes transfer requests by completing them on the target chain. It MAY operate nodes on both chains to learn about the finalization of `complete_transfer` transactions. The operation of the Relayer, including the bootstrapping process, is detailed in [MIP-61](https://github.com/movementlabsxyz/MIP/pull/61). + +### Storage fields + +The storage fields are directional, hence we need to mirror the mapping for L1→L2, as well as L2→L1. Hence, we will talk about source and target chain. + +#### Source bridge contract + +```rust +struct SourceBridgeTransfers { + /// A list of unique bridge transfer IDs. + bridge_transfer_ids: Vec, + /// A mapping of `bridge_transfer_id` to the bridge details. + bridge_transfer: HashMap, +} + +/// Details of a bridge transfer on the source chain. +struct SourceBridgeDetails { + /// The address of the user initiating the bridge transfer. + originator: Address, + /// The address of the user receiving the bridge transfer. + recipient: Address, + /// The amount of tokens being transferred. + amount: u128, + /// A unique identifier for each bridge transfer, incremented by the contract. + nonce: u64, +} +``` + +#### Target bridge contract + +```rust +struct TargetBridgeTransfers { + /// A list of unique bridge transfer IDs. + bridge_transfer_ids: Vec, + /// A mapping of `bridge_transfer_id` to the bridge details. + bridge_transfer: HashMap, +} + +/// Details of a bridge transfer on the target chain. +struct TargetBridgeDetails { + /// The address of the user initiating the bridge transfer. + originator: String, // or `Address` if using an Ethereum-compatible type + /// The address of the user receiving the bridge transfer. + recipient: String, + /// The amount of tokens being transferred. + amount: u128, + /// A unique identifier for each bridge transfer, incremented by the contract. + nonce: u64, +} +``` + +### Transaction flow + +> [!NOTE] +> This bridge design is a simpler version compared to the previous HTLC-based implementation, thus less steps are required to complete a bridge transfer. + +The bridge is initiated by the user and completed by the Relayer. The Relayer is a trusted party that finalizes the bridge transfer on the target chain. The user is not required to have funds on the target chain to complete the transfer. The Relayer is responsible for completing the transfer on the target chain. + +- There are two possible states, `transfer_initiated` or `transfer_completed`. +- User initiates the transfer. +- Relayer completes the transfer with parameter validation. +- Current HasuraDB built internally can provide enough infrastructure for users to know if their transaction has been completed. It does not differ from the current (HTLC-based) design in any way since user is not able to see if their transaction is in-flight. We could introduce this by notifying the user if the Relayer has been ordered to complete the transaction. + +```mermaid +sequenceDiagram + participant User + participant Source_Contract as Source Chain Contract + participant Relayer + participant Target_Contract as Target Chain Contract + + User ->> Source_Contract: Initiate Transfer + Source_Contract -->> Relayer: Emit Transfer Event + Relayer ->> Target_Contract: Complete Transfer + Target_Contract -->> User: Tokens Delivered +``` +*Figure: Interaction flow diagram.* + +![Transaction History](tx-history.png) +*Figure: Users would be able to see if the bridge has been completed. It's either pending or completed.* + +### Protocol description + +#### L1 → L2 + +1. User initiates a bridge transfer on L1 via a `initiate_transfer` transaction. Contract stores a mapping of the user `bridgeTransferId` for easy access. It transfers from the user \$L1MOVE to the contract. The transaction emits `originator`, `recipient`, `amount` and a `nonce`. +2. Relayer awaits for finalization of the `initiate_transfer` transaction on L1. +3. Relayer sends a `complete_transfer` transaction on L2 to complete the transfer. +4. The contract verifies that the transaction is correct by comparing the provided `bridgeTransferId` hash and the emitted values of `originator`, `recipient`, `amount` and `nonce`. Finally, it mints \$L2MOVE and sends it to the recipient address. +5. User is notified on the frontend that their transaction has been completed. +6. The time to finality for the complete transaction on the L2 should be considered after the postconfirmation, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), to provide strong finality guarantees. + +> [!NOTE] +> Postconfirmation is an anchoring mechanism for the L2 to the L1. It provides additional reorg protection. We MAY consider Fastconfirmation instead of Postconfirmation, see [MIP-65](https://github.com/movementlabsxyz/MIP/pull/65). This assumes the L2 is extremely unlikely to reorg AND the committee is considered to be safe. + +![L1-L2](L1ToL2.png) + +#### L2 → L1 + +1. User initiates a bridge transfer on L2. Contract stores a mapping of the user `nonce` to bridge details for easy access. User transfers \$L2MOVE amount to the contract which burns it. The transaction emits originator, recipient, amount and `nonce`. +2. Relayer awaits for finalization of the transaction on L2. Finality COULD be considered the postconfirmation, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), to provide strong finality guarantees. However, we suggest the Relayer SHOULD consider fastconfirmation, see [MIP-65](https://github.com/movementlabsxyz/MIP/pull/65) instead, due to high fluctuation of gas prices on L1 within time that is required for postconfirmation. Nevertheless, this introduces dependency on that the L2 is extremely unlikely to reorg AND the committee is considered to be safe. +3. Relayer completes the transfer on L1 by sending a `complete_transfer` transaction. +4. L1 contract verifies that `complete_transfer` is correct by comparing the provided `bridgeTransferId` hash and the emitted values of initiator, recipient, amount and `nonce`. Also `nonce` must not be used yet. Finally, it transfers \$L1MOVE to the recipient address from the locked token pool. +5. User is notified on the frontend that their transaction has been completed. + +![L2-L1](L2ToL1.png) + +### Key features + +We discuss the key features also in relation to the HTLC-based bridge to provide a comparison with the previous design. + +1. **Lock/Mint mechanism** + - **Initiation**: User sends a transaction to initiate the bridge containing recipient and amount. + - **Completion**: A Relayer or multi-signature group completes the transfer on the counterparty contract with the originator, recipient, amount and `nonce` for hash verification. + - **No funds requirement**: User is not required to have funds on target chain and we do not have to build sponsored transactions. + - **Delivery by Relayer**: Because the Relayer delivers the funds, there is no requirement for the user to complete the transaction on target chain, therefore simplifying the user experience and allowing a smooth onboarding on the network for transfers from L1 to L2. User only has to await for the finalization on the source chain and for the Relayer to perform the completion on target chain. This is standard practice for every major bridge in the ecosystem. + - **Less parameters**: Because there is no exchange of secrets between the user and Relayer, we have a substantial reduction of logic. + - **Must complete transfers**: Previously we reserve a refunder role to revert transactions. In this approach this is different as we guarantee delivery of funds through the same party that would guarantee funds being refunded, because transfers MUST be completed. + +2. **Consolidation of logic** + - Merge lock and completion functionality on the counterparty contract. Once lock is called, funds are already in the control of the user. In the HTLC implementation, once the timelock is over and complete on initiator has not been called, both the initiator and counterparty funds are available to the user, opening up for an exploit. + - Removes the refund functionality entirely to eliminate associated exploits. + +3. **Parameter validation** + - Ensure parameter validation on the counterparty to prevent invalid transactions. + +4. **Relayer redundancy** + - Use two types of Relayers: + - **Automated relayer**: Operated with minimal human involvement; its private key is highly secured. + - **Multi-signature Relayer**: Managed by the team to guarantee transaction completion in case of failures. + +5. **Cost efficiency** + - Minimize gas costs by reducing the number of interactions and simplifying fee calculations. + +6. **Enhanced security** + - Avoid refund logic to close exploit windows. + - Protect against key compromise through key isolation or known by no parties and multi-signature Relayer setups. + - There is no scenario where a bridge could lead to double-spending. It's either completed by Relayer or not. + - In the HTLC bridge the user can loose its bridge `preImage` which could lead to them being unable to complete the bridge. By not relying on a `preImage` from the user, it minimizes issues. It is not a loss in security because the purpose of the `preImage` is solely for refunding. + +7. **Batch processing for downtime** + - Multi-signature Relayers can process multiple pending transactions in a single batch to compensate for downtime. + +8. **BridgeTransferId** + - Continue using unique identifier to prevent double-spending and track transactions securely. + +9. **Initial bridge fee proposals** + - On the L1 to L2 bridge, do not charge fees. + - On the L2 to L1 bridge, charge a fee estimated by admin. It's set to the gas spent in ethereum in move. This requires an oracle and can only be implemented after oracles are live and we are able to have a maintainer that is able to set the fees on L2. + + ``` + entry fun set_fee(caller: &signer, fee: u64) { + assert_is_maintainer(caller); + borrow_global(@aptos_framework).fee = fee; + } + ``` + +10. **Best practices** + +- Adopt currently used bridge designs from established designs like Arbitrum, LayerZero and Blast bridges, which use a Relayer to finalize the bridge. +- User is not required to have funds on counterparty contract to finalize the bridge. + +## Exploits and potential losses + +1. **Key compromise** + - The compromise of the Relayer keys would lead to unauthorized transactions, putting the protocol at risk of unlimited value exploit. The protocol must absorb the losses and rotate Relayers. To minimize this risk [MIP-74](https://github.com/movementlabsxyz/MIP/pull/74) proposes a rate limitation even for the Relayer. +2. **Fee wrong estimation** + - Incorrect fee calculations (e.g., underestimating gas) can cause significant financial losses for the operator. + +## Reference implementation + +[Solidity Implementation](https://github.com/movementlabsxyz/movement/tree/primata/simple-native-bridge) + +[Move Implementation](https://github.com/movementlabsxyz/aptos-core/tree/andygolay/simplified-bridge) + +### (Optional) Recommendations + +#### Batch completion for multisig Relayer** + +Multisig Relayers could process pending transactions in batches during downtime of the standard Relayer, ensuring timely resolution. + +## Verification + +1. **Correctness** + - Simulate multiple transaction scenarios to ensure robustness. + - Test edge cases, including Relayer downtime and batch processing. + +2. **Security implications** + - Conduct audits focused on the simplified design. + - Implement rate-limiting safeguards and validate parameters in contracts. + +3. **Performance impacts** + - Benchmark gas costs and transaction throughput. + +4. **Validation procedures** + - Perform an audit and thorough testing, alongside an open invite to the community to verify the bridge. + - Seek community feedback and incorporate suggestions. + +## Appendix + +### A1: Related issues + +- [Movement Issue #838](https://github.com/movementlabsxyz/movement/issues/838) +- [Movement Issue #842](https://github.com/movementlabsxyz/movement/issues/842) + +### A2: Gas cost comparison + +- **Current Design**: ~400k gas per bridge round trip. +- **Simplified Design**: ~200k gas per bridge round trip. + +### A3: Referenced designs + +- [Arbitrum Bridge](https://bridge.arbitrum.io/?destinationChain=arbitrum-one&sourceChain=ethereum) +- [Blast Bridge](https://docs.blast.io/building/bridges/mainnet) + +--- + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/MIP/mip-58/tx-history.png b/MIP/mip-58/tx-history.png new file mode 100644 index 00000000..d1e52975 Binary files /dev/null and b/MIP/mip-58/tx-history.png differ