Decentralized DOT<>ETH Bridges: A Comparison Thread

[Aki]

We agree with Snowfork’s opinion about bridge security. And, we also adopt the on-chain light client verification mechanism. it only needs to trust the validator set (or miners of POW chain) of the two blockchains. there is no external trust needed. So, on-chain light client verification is the best solution from a security point of view.

Darwinia is not just a bridge but supports various cross-chain message support and services, including integrated XCMP, routing, Oracle-based messages, or future Rollup Messages. Darwinia Network Provides Programmable Cross-Chain Messaging Network For dApp Developers.

To support such services, we split the architect into three layers, the truth layer, message layer, and the application layer. For Darwinia, we focus on the message layer, bind to diverse self-developed or integrated truth layers, and provide cross-chain messaging services to dApps located in the application layer. LCMP is a light-client-based message protocol and is only one of the protocols we will support.

Supported Message Protocols and Truth layers.

• LCMP(Bridge Message), how it works?

  • https://docs.darwinia.network/lcmp-overview
  • We implemented LCMP as substrate pallets and solidity contracts.
  • substrate <> substrate(s2s)
    • GitHub - darwinia-network/darwinia-messages-substrate: Darwinia LCMP integration SDK for substrate chains ✉️ based on GitHub - paritytech/parity-bridges-common: Collection of Useful Bridge Building Tools 🏗️.
    • Darwinia <> Crab message channel is already running. And Darwinia <> Darwinia Parachain message channel will be running soon.
    • In order to facilitate the use of cross-chain functions in smart contracts, we provide solidity SDK for s2s. Introducing the Darwinia Universal Cross-Chain Messaging SDK
  • Darwinia <> Ethereum2(d2e)
    • Darwinia <> Ethereum2 is already running and has been employed by Helix to provide cross-chain applications for assets. Helix is a user of the Darwinia cross-chain messaging service.
      • https://helixbridge.app/en/apps
      • RING(Darwinia Smart Chain) <> RING(Ethereum)
    • In d2e we developed and used the solidity version of LCMP. We implemented beacon chain light client spec in solidity.
    • Because of technical limitations (Ethereum does not support ed25519) and the cost is too high, we use a transition scheme on Darwinia light client on Ethereum, which we call ECDSA authority. It is a governance-selected committee, responsible for ECDSA signing and verifying messages from Darwinia to Ethereum. We also considered BEEFY, but it is a transition scheme too, we more hope to use BLS in the future.
    • Darwinia MessageRoot Commitment.

• XCMP Integration

  Darwinia has parachains on both Polkadot and Kusama, build many channels with other parachains, and adopt XCM/XCMP to provide massage services to applications in Darwinia chains and other chains.

  • Darwinia chain keeps running as a solo chain.
    • GitHub - darwinia-network/darwinia: Universal cross-chain message network. | We are hiring, hello@darwinia.network
    • GitHub - darwinia-network/darwinia-common: Darwinia Runtime Pallet Library and Pangolin/Pangoro Testnet
  • Darwinia Parachain proxy Darwinia chain to interoperate with other parachains.
    • GitHub - darwinia-network/darwinia-parachain

• Message Router

  • parachain message router(lcmp-xcmp router)

    Darwinia Parachain is now used as the LCMP-XCMP router for other parachains. The smart contracts between Pangolin and Moonbase Alpha have been able to communicate with each other.

    • Message router for LCMP & XCMP by jiguantong · Pull Request #141 · darwinia-network/darwinia-parachain · GitHub
    • XCMP <> LCMP routing2 by wuminzhe · Pull Request #281 · darwinia-network/darwinia-messages-sol · GitHub
    • Crab Smart Chain <> Moonriver Routing Scheme (new)
    • https://medium.com/darwinianetwork/darwinia-introduces-lcmp-xcmp-router-implementing-cross-chain-messaging-between-parachains-and-b9f6da2d0d75

  • LCMP - EVM support

    In order to conveniently use S2S in EVM, we provide LCMP - EVM support. 1. The cross-chain messages of s2s can directly call the contract method of EVM. 2. The s2s cross-chain messages can also be sent from the EVM contract.

    • Understanding Crab Chain and Crab Smart Chain

  • Build EVM - XCMP - LCMP - EVM solution by integrating with Moonbeam’s LCMP - EVM support.

    Since moonbeam supports XCM-EVM, we go one step further and implement EVM-XCMP-LCMP-EVM support. You can call each other in the contracts at both ends.

• Fee Market

  We designed and implemented a cross-chain fee market controlled by supply and demand

  • https://medium.com/darwinianetwork/darwinia-apps-guide-part-vⅰ-fee-market-analytics-9cd909e9e8
  • https://github.com/darwinia-network/bridger/blob/3e0708f5ec0c3a851ec4623f99585d742f220e05/docs/fee-market-strategy.m
  • https://feemarket.darwinia.network/

• Relayer Client

  bridger has a framework that supports message delivery between different chains. It provides very easy-to-use and simple bridge implementation logic. Anyone who wants to implement their own relayer only needs to refer to a bridge template.
  bridger now supports Substrate <> Substrate, Substrate <> Ethereum, EVM <> Ethereum with Fee Market.

  • GitHub - darwinia-network/bridger: Client for header and message relayers in Darwinia cross-chain messaging network.
  • rust-docs.darwinia.network/bridger
  • https://bridger-state.vercel.app/

Security Model

1. Governance & upgrade security
   1. Our philosophy is to minimize governance and upgrade and keep the protocol as simple as possible.
      1. For example, for the light client and truth layer component, we have no governance and owners. If there are upgrades from the anticipated chain, we just redeploy the truth layer components and let the message/application layer choose as they wish/need.
      2. For the message layer, we follow the minimized governance model for now.
      3. For the application layer, we only provide message SDK for dApp developers. We do not develop applications. dApps developers are responsible for their decision of governance model, we do not make decisions for them.
2. Truth Layer Security(Consensus Security)
   1. We use the approximate/best truth/consensus layer for different message protocols and applications.
      1. For example, for messages between parachains, we think it’s better to use XCMP as parachains share security from relay chains, actually working as sovereign shards of Polkadot.
      2. For messages between Ethereum and its rollup, we think it’s better to use the Rollup bridge instead of the light client since Layer2 has the same level of consensus security as Layer 1.
      3. For messages between heterogeneous layer 1 blockchains with their own consensus, the best way would be to employ light clients for them.
      4. For applications that do not require the most secure consensus security, but less cost of interoperation, they can adopt other bridge techs such as MPC, oracle-based, or optimistic verification-based protocol.
      5. Truth Layer cross-chain mechanisms comparison
3. Engineering and application/message layer split
   1. Application layer do custodian
   2. Darwinia Security Design Strategy and Philosophy Update

Business Model

• Token & Wallet

  • https://darwinia.network/economic_model#/tokens
  • https://apps.darwinia.network/

• Fee Market

  For message fees, Fee Market provides cross-chain message services and route services in general

  • https://medium.com/darwinianetwork/what-can-a-cross-chain-message-relayer-get-ffb683b689cb

Application Developer Support

Although we do not develop applications, we take developer support very seriously.

We believe that permissionless deployment is important for dApps developers. So we not only provide message services to substrate chains/runtimes, we also crafted our message protocol so that it can be used directly by a smart contract. With that, the dApps can get to use message endpoints without the need for permission from the source and target chains/runtimes.

SDK will be one of our next priorities.

https://github.com/darwinia-network/darwinia-messages-sol/tree/master/contracts/periphery/contracts/s2s

https://github.com/darwinia-network/darwinia-docs/tree/master/docs/sdk/guides

References:

https://www.notion.so/itering/Bridge-Instances-cc66b682cecb499ba845e99f78886e6d

https://medium.com/darwinianetwork/darwinia-security-design-strategy-and-philosophy-update-f66d3406f652

https://darwinia.network/itering_io_optimistic_bridge_technical_paper_en.pdf

https://www.notion.so/itering/POSA-Light-Client-429f2fe8f76c4d4e819b153a247e2c8e

https://www.notion.so/itering/Darwinia-Ethereum-Message-Protocol-V2-ccd0ad5a80894815bd93fbed8a41539a

https://www.notion.so/itering/Ethereum-Substrate-dd300afee3634f8c88f45792916e1918

https://www.notion.so/itering/Content-from-old-page-of-Message-Protocol-Not-used-d2c06c9d6bb34ee5a44c914c96fe4151

https://github.com/darwinia-network/darwinia-common/blob/e8fcdd78397d6b9264bea20a84093e6c0eb163f7/docs/Relayer Fee Market.md

https://github.com/darwinia-network/research/issues/21

https://github.com/paritytech/parity-bridges-common/issues/992

https://www.notion.so/itering/Upgrade-27e896a038af4d489595a4979c65aaa0

https://docs.helixbridge.app/how-it-works/token_protocol