MD-21: Native Bridge with Attesters

  • Description: Proposal for simplifying the native bridge mechanism using an attester-based approach and drawing inspiration from USDC’s CCTP. The goal is to reducing friction, cost, and complexity for Layer 2 onboarding.
  • Authors: Primata

Overview

This MD lays out steps to introduce and leverage an attester-based bridge model to create a frictionless, efficient, and secure cross-chain experience for Movement technologies.

A bridge mechanism is essential for any Layer 2 solution, serving as the user’s first interaction with the network. This process must be smooth and frictionless, ensuring that dealing with tokens on L1 and bridging to native gas tokens on L2 does not overcomplicate the user experience. The bridge must balance user onboarding, cost-efficiency, and simplicity, while minimizing transaction complexity.

We request to

  1. draw inspiration from the Cross-Chain Transfer Protocol (CCTP) protocol by USDC, which offers an elegant solution to these challenges.
  2. Apply an attester based model to the native bridge.
  3. Supply a clear flow for the bridge mechanism.

Motivation

Our current bridge solution has been increasing in complexity with each iteration. Originally requiring three on-chain transactions, it now requires four, initiate bridge, lock, complete source chain, complete target chain. Additionally, the bridge does not currently support gas charging mechanisms to prevent exploits, and ongoing discussions are leaning toward adding further components, making it even more complex and computationally expensive.

We believe the best approach is to draw from live implementations that have achieved a streamlined user experience with minimal cost to the user. One such example is USDC’s CCTP, which offers simplicity, security, and efficiency in cross-chain bridging. Instead of increasing the complexity of our current bridge design, we should aim to adopt more proven mechanisms.

Desiderata

D1: Take inspiration from CCTP

User Journey

The developer can understand the Cross-Chain Transfer Protocol (CCTP) model and draw from it to design a bridge mechanism that is simple, secure, and efficient.

Description

The CCTP operates using a set of attesters that validate all bridge transactions occurring between chains. These attesters listen for bridge events, confirm the validity of transactions, and, if necessary, revert them by providing appropriate proofs. A transfer allowance managed by a centralized authority further ensures that breaches are mitigated by limiting the amount of value transferred.

Justification

Already operational Relying on a protocol like CCTP that has been tested in live environments significantly reduces the risk of any unexpected utilization of off-chain and on-chain proofs. It is also operational and widely adopted.

Reduction of messages

  1. An on-chain component on source domain emits a message.
  2. Circle’s off-chain attestation service signs the message.
  3. The on-chain component at the destination domain receives the message, and forwards the message body to the specified recipient.

This results in 2 onchain transactions and 1 offchain transaction. Comparatively, HTLC requires 4 onchain transactions.

This approach minimizes the need for additional components and avoids the reliance on synthetic assets, leading to a simplified and cost-effective bridge solution.

Recommendations

Reference Implementation For more details on how this model operates, refer to USDC’s Cross-Chain Transfer Protocol (CCTP) documentation:
USDC CCTP Overview

D2: Apply the Attester Model and Multisig Scheme

User Journey

The developer can implement a bridge mechanism that uses a multisig scheme.

Justification

Security Implications: The use of a multisig setup adds a layer of security, with aggregated signatures preventing unauthorized access. The transfer allowance mechanism further mitigates potential breaches by limiting how much can be transferred.

Performance Impacts: Because we would use a multisig off-chain signature to complete bridges, the set of attesters and the multisig address to produce the signature that we have to check the message against it could be the same set of the L2 Settlement signers. This method reduces the computational overhead associated with multiple on-chain transactions and simplifies the bridge process. The reliance on a proven mechanism ensures minimal performance degradation. It also provides a bridging service with 1:1 bridging with minimal logic that could be potentially used for exploits. It could also facilitate aggregating bridges since a merkle root could be used to handle the validity of the logic.

Validation Procedures: Formal and machine-aided validation of the off-chain signature and on-chain message handling will be crucial for ensuring the correctness of this proposal.

Peer Review and Community Feedback: The approach should be subject to review and feedback from the Movement Labs team and the wider community to ensure that it meets the needs of the ecosystem.

Recommendations

  • Bridge Relayer as Attester: The Bridge Relayer in our system will function as an attester, operating via a multisig scheme (i.e. the attester collects signatures from a threshold number of comittee members that approve of the message). This relayer, through aggregated signatures, produces a proof on a signed message.

  • User Interaction: Users, or other parties interested in completing the bridge, retrieve their funds on the target chain by submitting the signature and message.

  • Validation Mechanism: The off-chain signature produced by the multisig scheme is verified against the message on-chain. As a reference, we could use the same automation scheme as the MIP-18 Stage 0 Upgradeability and Multisigs. The challenge is to make sure that the signature is only used once so no transaction is replayed, but the beauty is that the signature is provided by a multi-party system that do not need to provide onchain signatures. It’s also important to use a solid architecture that prevents hash mining attacks.

D3: Specify the Flow

User Journey

The developer can understand the flow of the bridge mechanism. Hence a flow diagram and description should be provided.

Justification

The bridge mechanism should be straightforward and easy to understand.

Recommendations

  1. User Deposits:

    • The user deposits tokens on the source chain, which triggers a deposit event.

  2. Bridge Relayer:

    • The Bridge Relayer, listening for the deposit event, picks up the message or messages associated with the deposit.

  3. Multisig Signing:

    • The multisig party signs the bridge transaction. The combination of signatures produces an aggregated signature that ties the signatures to the message.

  4. Target Chain Verification:

    • On the target chain, the aggregated signature and the message are used to verify the validity of the bridge transaction. The withdrawal can only occur if the multisig-provided signature is valid.

  5. User Withdrawal:

    • Once the signature is verified, the user can withdraw the corresponding funds on the target chain.

This process is bi-directional, allowing funds to be bridged between Layer 1 and Layer 2, and vice versa, with minimal complexity and friction.

Errata

Appendix

  • [R1] USDC Cross-Chain Transfer Protocol: https://www.circle.com/en/cross-chain-transfer-protocol
  • [R2] USDC CCTP Overview: https://developers.circle.com/stablecoins/docs/generic-message-passing