How do we define a Bridge and what are the main design schools?

(A small blueprint on how to think about bridges and the various projects that exist. Somewhat opinionated)

A bridge is an application that enables the transfer of tokens across trust boundaries from one domain to another. It’s an application that uses cross-chain channels to send tokens from one domain to another.

It’s responsible for locking locally originating tokens and minting their representations to the remote domain.

It’s a more specialized version of the following general problem:

How can an application on one blockchain react to an event on another blockchain?

Definition

Formally, it’s described as the “Cross-Chain Communication”¹ (CCC) problem and has been the topic of research for many years already. It’s analogous to similar problems that concern distributed databases. We can model it as a Non-Blocking Atomic Commit. Instead of protocol rules, the system must be able to handle Byzantine failures.

An example can shed some light:

Alice will execute T1 on Blockchain B1, only if Bob executes T2 on Blockchain B2. Thus, we want either both T1 and T2 or none. It’s analogous to the Fair Exchange Problem.

It should:

• Be effective → Either both observe the Transactions they want, or they both abort
• Be atomic -> Either we have both transactions or neither
• Be timely -> Eventually, the protocol will conclude

More broadly, CCC can be reduced to the following 4 phases:

• Setup
• Pre-Commit on B1
• Verify
• Commit on B2 (or abort revert B1 state)

It has been proven¹ that CCC is impossible without a trusted third party or synchronicity.

Even with the use of light clients, there is still a trusted third party, which is the consensus set of the blockchain.

Design Space

Roughly, there are four design families, each with its design tradeoffs.

The tradeoffs are around the following categories:

• Latency, How quickly do we get the message out of the channel
• Security, aka under what circumstances can we have funds frozen/stolen
• Complexity, aka how easy it is to be implemented
• Overhead, aka cost to users to validate messages
• Reusability

Validator Set

• Low Latency
• No Security
• Low Complexity
• Low Overhead
• High Reusability

Essentially a multi-sig. Users trust that M of N validators are honest, and if not, all funds locked by the bridge are at risk.

Axelar², Wormhole³, and Layer0⁴ belong to this category.

Axelar: A staking blockchain enforces rules of who belongs to the M of N set. Slashing exists, but the blockchain can’t verify fraud on the chains it connects, so the slashing concerns only that the validators follow the consensus rules of the “Axelar chain”. Validators can perform fraud by stealing all the funds and not getting slashed as long as they follow the consensus rules.

Wormhole: A validator set, but there are lots of them, and US institutions run them—validators you can sue.

Layer0: A 2x2 multi-sig between Layer0 and Chainlink.

Light Client / ZK

• Low Latency
• High Security
• High Complexity
• Mid-high Overhead
• High Reusability (with Tendermint)

Light client bridges verify the consensus rules of one domain into another. For example, Bitcoin SPV on Ethereum would verify Bitcoin headers in a smart contract. By passing a transaction, a proof, and a title, the receiver chain can confirm that that transaction was included (thus valid according to the sending chain) and accept it.

Examples of light clients are the IBC⁵ on cosmos and Bitcoin SPV⁶ on Ethereum.

Zero-knowledge is the same, but instead of running the light client on-chain, we compute a ZK proof of the state transition off-chain and verify the proof.

Succinct⁷ is a good example of a ZK-based bridge. IBC is an excellent example of a light-client cross-chain protocol. Although they seem to offer the best of both worlds (speed, safety, etc.), the tradeoff is extreme complexity in the form of ZK circuits for the verification of the consensus rules. Every new consensus protocol requires a new circuit, so connecting a new chain can be trivial (using the same consensus protocol) to years of engineering work.

One of the reasons why IBC works that well is because all Cosmos chains share the same consensus protocol, thus no new work is required to bridge a new cosmos chain to the rest. Applying the same thinking to a heterogeneous environment is more challenging. Another reason is that Cosmos was built with IBC and cross-chain interop as an explicit design goal, not an afterthought. Thus, Cosmos chose a consensus protocol (Tendermint) that is friendly to light-client verification. Most consensus protocols are not built with light-clients in mind. For example, Ethereum introduced later a botched light-client upgrade⁸.

Optimistic

• Medium Latency
• Low Security
• Low Complexity
• Low Overhead
• Very High Reusability

Pioneered by Optics⁹ in Celo (which later became Nomad), it has a 1 of M trust system. On top of the validator, you have another agent called Watcher, which can be configured by the app and is responsible for disconnecting the app when fraud is detected. Due to the optimistic window, that disconnection is enough to protect it.

We exchange liveness to lower the trust assumptions and it’s extremely simple, meaning that connecting new chains is nearly trivial.

A few examples of this are: Nomad¹⁰, Synapse¹¹, and Hyperlane¹² (fka Abacus).

Rollup Bridge

A rollup bridge is an enshrined bridge with a synchrony assumption between the base layer and the rollup. In a way, the validators of the base layer act as “validators” for the bridge itself. The two validator sets are the same.

An example is Connext¹³, which unifies the various Rollup Bridges into a single interface for the developers to build.

Conclusion

When thinking about Bridges, it’s important to think in terms of tradeoffs. There aren’t silver bullets and anyone who’s saying otherwise is probably selling snake oil. Depending on the dapp, it makes sense to use different Bridging protocols.

Always remember that behind a Bridge there is a team and that team is the ultimate weak link (most probably) of the whole protocol. In my view, if the team has been intellectually dishonest in the past, that’s a signal that should not be overlooked, even if the technology seems better than the competitors.

References