Decentralized DOT<>ETH Bridges: A Comparison Thread

Tech Talk
1

With the ongoing debate around the Snowbridge common good chain proposal (Polkassembly), I call all Ethereum bridge projects that claim the title of #decentralized to join this thread for a technical debate.

From the Polkassembly post, it appears there are 3 contenders:

  • Snowbridge
  • Darwinia
  • Composable

Each ETH bridge project that claims the #decentralized title should:

(a) provide docs on how it works (very clear, plus links to code),
(b) explain the security model (incl governance, upgrades, etc.)
(c) share audit reports,
(d) explain of the business model (e.g. token vs no token)
(e) link a live testnet incl. performance measures
(f) advantages over the other bridges up for discussion

This will allow for a tech-based discussion and comparison of pros and cons.

Please do not start any debates around the common good slot proposal. This thread should be 100% technical. It can serve as basis for the political side of the debate - but not more.

13 Likes
2

Completely agree. The debate should be focused around technical merit and value add to the ecosystem.

1 Like
3

Really looking forward to a technical discussion. How can we create a cross-chain bridge which is secure, but also has good UX and scalable (scalable to much to ask?)

4

Definition of trustless security

Before contrasting Snowbridge to other solutions, I think it’s important for us to align on what we believe trustless security means in a Polkadot context. We define a trustless, secure polkadot bridge as one in which users and applications need to trust only:

  1. Polkadot itself, ie, it’s consensus algorithm and state transition machine, and that it’s code is bug-free
  2. Ethereum, ie, it’s consensus algorithm and state transition machine, and that it’s code is bug-free
  3. The governance and upgrade process of Polkadot itself (ie, council/gov2 root origin/DOT token holder votes)
  4. The governance and upgrade process of Ethereum itself (ie, ETH staking and their rough community consensus)
  5. All on-chain code involved in the bridge is bug-free (ie: any code on any chain or parachain involved in the bridge and any smart contract code)

In addition to the above, most designs in some component of their stack require a single honest party (eg: All parachains today do require at least one single honest node running the parachain). We consider this requirement acceptabe too, provided that this role is fairly permissionless and openly accessible for anyone to participate as.

There should be no other trust required in any part of the bridge or parachains involved.

On evaluating trustlessness

Another important thing to understand is that, in most cases, the security of a system is only as strong as it’s weakest link. This means that any trustless bridge needs to be full stack trustless, across all of its code, contracts, chains, parachains, governance and upgrade processes. If any of these pieces do not meet the above definition of trustless, then the bridge’s trustlessness and decentralization will likely degrade to that of the lowest common denominator.

We’ll also talk about what we believe common good means, but that’s for another post. This one is focused on trustlessness.

Why is trustless security critically important for a Polkadot Ethereum bridge?

Of course, there are tons of reasons why a trustless bridge is important, but in the Polkadot context we believe it is even more critical than typical, specifically because:

  • Bridges are infectious. Their assets, messages and applications will spread through the ecosystem into other parachains and applications. This means that their flaws are infectious too, and issues with a bridge, especially the Ethereum bridge which is likely to have the most assets/usage of any other bridge will become issues for Polkadot as a whole.
  • If the Ethereum bridge is not trustless, there is significant risk that its assets infects most Polkadot dapps and all of Polkadot and all parachains have their security degraded to that of the bridge.
  • Even if the Ethereum bridge is decentralized, if it does not meet the exact 1 - 5 criteria above, this means that it is getting some of it’s decentralization/trustless from somewhere else, that isn’t Polkadot. This means that Polkadots security and the security that staking the DOT token provides is at risk of being undermined not just for the bridge, but for all apps on all parachains.

Common Polkadot Bridge components

Most polkadot ethereum bridges today involve some combination of all the below components:

  • A: Ethereum smart contracts for the bridge
  • B: Ethereum smart contracts for any asset-related applications
  • C: Bridge-related parachain logic
  • D: Parachain consensus/verification
  • E: Governance and upgrade process for the smart contracts
  • F: Governance and upgrade process for the parachain and bridge-related code on it
  • G: Other components that do not run on Polkadot nor Ethereum (eg: relayers, oracles, other blockchains with different security)

Snowbridge

For Snowbridge, we have the following:

  • A: Ethereum smart contracts for the bridge
    • Run on ethereum and use light client verification for all headers based on BEEFY proofs, merkle proofs for all messages and permissionless access channels
  • B: Ethereum smart contracts for any asset or monetary related applications (eg: Bridged tokens)
    • Run on ethereum and use the above bridge verifications to mint wrapped assets, with access only via the above bridge verification channels
  • C: Bridge-related parachain logic
    • Runs in a Rust pallet and uses light client verification for all headers based on Ethereum’s Proof of Stake, merkle proofs for all messages and permissionless access channels
  • D: Parachain consensus/verification
    • Expected to run as a parachain on polkadot, using the bridge hub built on Cumulus with single-honest-party based consensus and fairly permissionless validators.
  • E: Governance and upgrade process for the smart contracts
    • Gov2 root origin only, propogated to Ethereum via cross-chain governance
  • F: Governance and upgrade process for the parachain and bridge-related code on it
    • Gov2 root origin only
  • G: Other components that do not run on Polkadot nor Ethereum (eg: relayers, oracles, other blockchains with different security)
    • Offchain relayers, with single-honest-party requirements and fully permissionless access to anyone

Based on the above definition, besides for the always-present and unavoidable risk of bugs in the code, Snowbridge meets all requirements 1 - 5

Also, in addition to further audits to mitigate the bug risk, we also plan to implement additional mechanisms within the bridge to limit the blast radius of attacks, for example a circuit breaker.

We can provide our assessment of other projects, but we’d rather not dish out harsh critiques before other teams have a chance to share their thoughts on their terms :).

6 Likes
5

I think we should wait until

  1. EVM starts to support BLS signatures
  2. Polkadot starts to use BLS signatures

before we decide on what to chose as a common good bridge.

Polkadot is not even using Schnorr in its Light Client Bridges for Ethereum because it doesn’t support it. Instead we are using ecdsa. Which is good for compatibility but a bad choice overall.

I don’t know how the relations with Ethereum are but if there is way to support it, there is a good chance for Ethereum to start supporting BLS with Shanghai Upgrade.

Why Polkadot should use BLS in general?

6

Can you share where do you get this impression?

My personal take is that BLS precompile would not be EF’s priority anytime soon unless they think Ethereum has a clear win over all the Alt L1s.

7

Sorry if I didn’t explain clearly. I mean, if enough support can be provided, it can be added to Ethereum because it is one of the Shanghai update candidates. Since the client codes are also ready, it is necessary to make some noise again.

8

Darwinia is happy to participate in technical discussions and contribute to common good chains as well.

Darwinia has invested a lot of time in the field of cross-chain messaging, and has implemented the interoperability with Eth2 based on the on-chain light client. Before ‘The Merge’, the messaging channel between Darwinia and Eth1 had been running for a long time. We have also achieved interoperability with other parachains through the Darwinia Parachain using HRMP, which is currently being tested on the testnets (Pangolin <> Rococo <> Moonbase alpha). These works have prepared the Polkadot ecosystem to connect to Ethereum. We are open-minded and hope to see more innovations in this field. We are preparing some materials, which will be listed here in the next few days.

2 Likes
9

Vincent from Snowfork here. We’ve consolidated and refreshed our technical documentation. Please have a look at https://docs.snowbridge.network/.

The documentation describes:

  1. How the bridge actually works at a technical level
  2. Its security model (governance and upgrades)
  3. How to use the Rococo<->Goerli testnet
  4. Some preliminary performance and cost measures.

Over the next week, more content will be added:

  1. Economic model of the bridge (i.e. how will the bridge sustain its operations).
  2. Comparisons with other bridges (including bridges in other ecosystems)
  3. More performance and cost figures

Please add your questions, concerns, and thoughts to this forum thread.

10

At Sygma (https://docs.buildwithsygma.com/) we are working on an EVM-to-Substrate integration together with some parachain teams. Will announce more in the next 2 months but we are glad to be part of this discussion as well!

1 Like
11

when people think of a cross-chain bridge in a typical sense they are generally referring to asset bridges which allow us to lock/mint wrapped tokens between various chains and transfer liquidity, but that’s only one practical application for the kind of cross-chain message networks being discussed here, which allow arbitrary message passing to deliver any kind of asset or functionality imaginable across multiple chains, even asynchronously.

these new bridge networks as infrastructure will empower developers with the tools to create a more seamless user experience, especially when transacting assets across multiple hops. for example, imagine how many steps it takes to get assets on a chain you’ve never used before: in many cases you have to log into a CEX and buy the native token, and then send to your wallet on that chain and finally swap to your desired token. it’s a nightmare sometimes even for people familiar with the process, but this new cross-chain interoperability paradigm will eventually reduce all of these actions on the asset bridge front to just two or three clicks, all from the same wallet or interface, and this is only one example.

some other practical applications for cross-chain message networks are:

Cross-Chain DEX: Allow users to exchange assets across multiple chains in a single transaction.
Borrowing & Lending: Allow users to pledge collateral on one chain and borrow assets on other chains.
NFT Market: Bid on auctions taking place on another chain.
DAO Governance: Allow for a unified multi-chain governance mechanism without needing to move assets to a central voting chain.
Multi-Chain Gaming: Allow users to transfer NFTs across multiple chains.
Cross-Chain Arb and Liquidity Balancing: Trade assets and take advantage of opportunities across multiple chains

12

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.

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

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

1 Like
13

Thanks for the detailed overview Aki. Some comments below…

  • 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.

Please correct me if I’m wrong, but this does sound like a centralized multisig bridge. I’m also very curious why you felt that BEEFY was not appropriate or feasible for bridging to Ethereum?

I don’t consider BEEFY in its current state to be transitional. It’s working as designed for Ethereum bridging. At least for using BEEFY to bridge to Ethereum, BLS signatures will likely only be supported in 2024. Ethereum’s Shanghai upgrade scheduled in late 2023 doesn’t include EIP-2537 (BLS precompiles). So BLS is still a long time away.

Admittedly there is a cost to relay BEEFY commitments to the light client and to verify the validator signatures. But the minimum number of required signatures is low. Like 10 signatures for a validator set of 300 active validators. We explain this here. With Ethereum 2 and its new RANDAO randomness source, some of these parameters will be tweaked. But they should remain cost-effective. And of course, state updates to the light client can be rate-limited to reduce costs ultimately borne by users.

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

Yeah, that’s pretty cool! Snowbridge doesn’t have fee markets yet. Designing and implementing a relaying system based on trustless, decentralized fee-markets is really a complicated and intensive project on its own. So we felt it important to focus our attention on items we felt were most important for our initial launch. In any case, our bridge provides two separate and complementary relaying systems:

  1. Basic Channel: By ensuring guaranteed deliverability, anyone can relay messages at their own cost with the software we provide. Can be used by individuals and third-party teams to relay messages with the most cost efficiency.
  2. Incentivized Channel: Ensures guaranteed delivery by incentivizing permissionless relayers to relay messages. While perhaps not as cost-efficient as a fee-market approach, we feel its good enough for launch.

In the Polkadot->Ethereum direction our channels also batches messages together for delivery. This helps reduces gas costs of message verification by our BEEFY light client. The cost of verifying a message batch is nearly the same as verifying a single message, so we may as well support batching.

1 Like
14

@Vincent

  1. We think beefy is a good choice at this stage, but according to some feedback from helixbridge, we feel that the cost is still too high, users want a lower cost service, so we adopt the ecdsa authorities way. Snowfork seems to be able to reduce the cost to a very low level based on beefy, and we will do more to understand.
  2. How much is the fixed upfront fee?
15

Some rough cost figures at current gas prices -

The operational cost for BEEFY should be under $1,000,000 per year. I added more details here. Of course this won’t matter much by 2024 when BLS signatures come into play.

The fixed upfront fee charged by our incentivized channel should be around $20 according to calculations here. However, depending on demand levels, users are refunded a portion of that fee due to message batching.

For launch though, I think we’ll probably implement this trustless gas price estimator, which should reduce the fee closer to actual gas cost.

16

Less of a tech question but Imho the bridge should make inbound tx free/cheap and only charge for outbound initially

17

I think this is related with the Bridge solutions.

How useful is this new technique as a signature solution for Bridge?

18

Well Polkadot should get BLS support soon, assuming we can find anyone to review the PR (
this one was closed due to inactivity :frowning: ). But even if EIP-2537 is accepted, its still not easy to bridge to Ethereum using BLS.

Yes, it’s cheaper to aggregate public keys in BLS than verify individual Schnorr/ECDSA signatures, but a significant part of the cost was always storing and looking up the public keys. And BLS Signatures in BLS12-381 have a 50% larger key size than secp256k1 at 48 bytes. I’ll leave the gas cost of looking up 48 kilobytes or storing it every session as an exercise.

Now you could our our light client protocol based on rolling up BLS aggregation ( code and paper ), but that would require Ethereum to support more curves, BLS12-377 and BW6-761. There are EIPs for precompiles for this, EIP-3026 and EIP-2539 , but they are still taking years to support the BLS curves theu are now using in consensus, so I wouldn’t hold your breath on this being possible soon.

19

Ouch, thanks for the reality check Alistair.

Very glad about Core BLS Crypto by drskalman · Pull Request #11574 · paritytech/substrate · GitHub though. We need it for our Ethereum light client, to more efficiently verify BLS signatures in Substrate. We’ll chat to drskalman and see if there is some way we can help with the PR.

1 Like
20

Unfortunately whether this will directly help is also not clear. There are of course many choices for BLS signatures - curves, hash-to-curve etc. For BEEFY with the light client aggregation rollup, we will want validators to sign using the BLS12-377 curve, but on Ethereum, they will use BLS12-381. And I don’t know what we will fix on using for any host call and what will be an option.

In the long run, we want to standardise on the Arkworks library for elliptic curve crypto. It offers many options for curves. We went to some length to make sure it had the IETF hash to curve standard that Ethereum is using. We are considering adding more general purpose host calls for that so you’d be able to do fast pairings and other slow crypto operations in native rather than Wasm code for many curves.

Before then, you can of course use any Rust library for Ethereum-like BLS signatures, whether that is one an Ethereum client uses or Arkworks, compiled to Wasm in a runtime. Anyway, of course talk to us.