Bridges Between Blockchains

They fulfill the attractive promise of connecting blockchain networks into an interoperable whole, allowing traded tokens and data to flow from one chain to another. Yet within that promise, the trust is concentrated: it comes from a limited number of contracts and operators, regardless of its locality. What exactly should a user trust as their assets cross?

Most prominently, a lock-and-mint bridge works by locking tokens on the source blockchain. It then mints a synthetic or wrapped version of that token on the destination blockchain. On the reverse path, the bridge burns the wrapped token on the destination chain and unlocks the original token on the source chain. These wrapped tokens are economic replicas of the original, backed by the original assets that have been locked into the bridge’s dedicated vault or collateral contract.

A liquidity-pool bridge, on the other hand, avoids the wrapping step entirely. Instead, the user simply receives tokens from pre-funded pools of liquidity on the destination chain. These liquidity pools are a resource that must be maintained; the cost and efficiency of cross-chain transfers will depend substantially on the pool’s health.

What makes a cross-chain bridge decide what is valid? There are three general methods.

In an optimistic bridge, messages are accepted by default and only disputed during a challenge window by watchers who post fraud proofs. Here, the validating trust assumption centers on the fraud-proving watcher group.

A light-client bridge verifies the remote chain’s state by checking headers, validator sets, and Merkle proofs, without relying on an attesting committee. The trust assumption here, instead, shifts to the headers, consensus rules, and Merkle machinery.

Finally, an external multisignature set of validators assents to the transfer. Because this is, in effect, a threshold membership, the trust is distributed across the signers but concentrated at the group level.

Given a contract or operator group holds a bridge’s assets, these pieces quickly become major targets. As a small number of contracts or wallets control a large amount of economic activity and tokens, there is a concentration of both value and risk.

These contracts are, practically, self-contained islands. They do not read each other’s state, and cannot be directly proved to exist on each other’s chains. So to cross between them, a bridge must operate as a relay: a pair of contracts on each chain, coupled by a tradition of updating each other. Then, a trusted sender of messages, running the relay server, must attest and propose the enabled path.

A user must think carefully before making the choice to bridge, even if the bridge code passes an audit. The same risks will still be there even if the audited code is correct – they come from the assumptions it makes.

• Its assumption about which party is attesting and moves the original funds.
• The checkpoint, if any, before those general multimember signatures or watcher nodes can actually move the original funds.
• The time it would take to revert an invalid cross-chain transfer once finality happens, on each side.
• The long settling back to its endpoint.

So it remains that, when they’re put into use, cross-chain bridges are among the largest points of failure in the crypto economy.

These trust assumptions create sharply varying tradeoffs between finality and speed.

• An optimistic bridge achieves relatively high throughput and speeds, but exposes more trust to the watcher prooflayer.
• Conversely, a light client focuses more on verification, with higher lags and costs, so it relies on the coin machine and the Merkle machinery.

In a competitively complex landscape, analysts should use a clear method of validation, not label everything trustless. Instead, they should weigh and weigh again, for many tend to assume.

Different gates at the different bridges are handholds in that ecosystem. They allow bridges of different designs to answer the same, basic, question of cross-chain transfers. But each shifts the risk to a different set of assumptions: to the locked operation, to the validation mechanism, to the availability of liquidity. Still, no matter how well designed, the tradeoffs remain.