Cross-Chain Bridge Assessment Process

28

Kydo from Stanford Blockchain Club here.

Thank you to all the community delegates and bridge providers supporting the MMA design. If you are interested (as a bridge or delegate) to be part of the MMA design process, we welcome you to join our conversation. Just drop @Kydo a message here or on Twitter @0xkydo.

Multi-Message Aggregation (MMA) Design Question List:

Please note: the design is still under development and some minor changes could happen. However, these changes do not influence the overall security, liveness, and trust models of the design.

  1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
  • Better security and better availability: Using MMA, a Uniswap governance message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges. The likelihood of a large number of high-quality bridges concurrently getting exploited is strictly smaller than using a single bridge. Moreover, assuming all participating bridges have high availability, MMA provides better availability compared to a single bridge.
  • Vendor-lock-in free: Choosing MMA means that Uniswap will not be locked into one single vendor and therefore do not suffer from interest alignment risks or service quality risks down the road.
  • Simple and flexible: MMA is a straightforward smart contract framework consisting of around 350 lines of code. There is no need to operate any off-chain components. Its simple logic makes it easy to be thoroughly audited and formally verified. Moreover, it offers an adapter framework that is simple to integrate. This is evident from the successful integration of Celer, deBridge, Router Protocol, and Wormhole.

2. How long has the system been running on mainnet?

  • It is not running on mainnet.

3. How much value has the system secured? (Current TVL, total transaction volume)

  • Depends on the underlying bridge protocols.

4. Provide a background on your team.

  • MMA is a community effort. We are made up of 7 Uniswap delegates and 4 bridge providers/aggregators.

5. Please link your developer documentation.

6. Does the bridge support arbitrary message passing?

  • Yes, arbitrary message passing is supported through bridges integrated into MMA solution. The current MMA design can be illustrated in the diagram below.
┌────────────────────────────────────────────────────────────────────────────────────────────┐
│ Source chain                                                                               │
│                                                                                            │
│                                                ┌─────────────────┐   ┌───────────────────┐ │
│                                             ┌─►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│                                             │  └─────────────────┘   └───────────────────┘ │
│        remoteCall           dispatchMessage │                                              │
│ ┌────────┐    ┌────────────────────┐        │  ┌─────────────────┐   ┌───────────────────┐ │
│ │ Caller ├───►│ MultiMessageSender ├────────┼─►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘    └────────────────────┘        │  └─────────────────┘   └───────────────────┘ │
│                                             │                                              │
│                                             │  ┌─────────────────┐   ┌───────────────────┐ │
│                                             └─►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│                                                └─────────────────┘   └───────────────────┘ │
│                                                                                            │
└────────────────────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│ Destination chain                                                                           │
│                                                                                             │
│ ┌───────────────────┐   ┌─────────────────┐                                                 │
│ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├─┐                                               │
│ └───────────────────┘   └─────────────────┘ │                                               │
│                                             │receiveMessage              call               │
│ ┌───────────────────┐   ┌─────────────────┐ │     ┌──────────────────────┐     ┌──────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├─┼────►│ MultiMessageReceiver ├────►│ Receiver │ │
│ └───────────────────┘   └─────────────────┘ │     └──────────────────────┘     └──────────┘ │
│                                             │                                               │
│ ┌───────────────────┐   ┌─────────────────┐ │                                               │
│ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├─┘                                               │
│ └───────────────────┘   └─────────────────┘                                                 │
│                                                                                             │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

7. Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

  • The first audit is done by Peckshield and Halborn is engaged to do another audit. Peckshield audit report can be found here. Halborn is WIP. ETA - Wednesday, Feb 22nd
  • In the future, the MMA core contracts (MultiMessageSender & MultiMessageReceiver) will be formally verified.

8. Is there a bug bounty program?

  • No

9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.

  • All contract code in MMA are not upgradable. Uniswap Ethereum governance can change the configuration of the MMA including adding and remove bridge adapters and changing the quroum threshold of bridges.
  • The upgrade process is straightforward. If Uniswap wants to remove/add a bridge from the MMA design, it simply adds/removes it through a contract call from Uniswap governance.
  • Here is the documentation for configuration changes. And here is the example deployment and configuration changes on testnet using MMA.

10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?

  • There is no persist owner-like entity in the MMA solution contracts. An owner exists for MultiBridgeReceiver contract only for initialization and will be burnt once it is setup. No owner exist in any integrated bridge adapter.

11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?

  • The security of MMA relies on the quroum among integrated bridges. Assuming k is the quroum and N is the total number of integrated bridge. As long as k out of N bridges are passing the same governance calldata in the message, the governance action will be executed.

12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.

  • There are two ways for an adversary to pass a fraudulent message from Ethereum to the destination chain: 1) the adversary compromises k out of the N bridges. Or 2) the adversary exploits the MultiBridgeSender or the MultiBridgeReceiver contracts to fake message passed by Uniswap governance. The latter concern can be addressed by thourough auditing and formal verification of the simple logic present.

13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.

  • The adversary can only censor a governance message from passing through MMA when (N-k+1) out of N bridge providers are offline or compromised.

14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.

  • The slashing mechanism in MMA is simple, removing the bridge from the set of approved bridge set. Additional, native slashing mechanisms for individual bridges still exist.

15. Provide any additional information you would like here:

  • MMA is a community-driven effort. The effort is led by a group of experienced Uniswap delegates and multiple bridge/aggregator providers. In the spirit of open source, we also would love to credit the amazing contributors to the project. Celer has contributed most of the implementation, conducted audits and deBridge and Router also integrated their solution with the adapter interface. Peckshield has provided the first audit pro bono. Hyperlane also constructed its parallel design based on ISM.
  • It is important to note that there is no bridge-specific dependency in the MMA solution and it is bridge-neutral. We welcome community feedbacks. Moreover, we believe the MMA design is not just beneficial to Uniswap. It is a generalized solution for any DAO that relies on cross-chain governance.
  • We believe the MMA design works in conjunction with the bridge assessment team’s final deliverable. If the MMA design is chosen at the end, we can use the bridge assessment team’s evaluations of the bridges as the selection criteria for the initial bridge participants.
  • MMA is a public good. It not only is open source and free for anyone to use but also leverages emerging ERC-5164 standards and aims to bring more standardization to the bridging space.
6 Likes