Cross-Chains Bridges

Bridges are protocols to transfer assets from one chain to another and achieve some degree of composability and interoperability between two chains. This post provides a framework to evaluate each bridge design.

The fast development of DeFi doesn’t come without growing pains. As utilization in most popular blockchains surges, the transaction value cannot justify the cost and time involved for many use cases. Further, transaction costs and speed can make the user experience for certain types of blockchain applications dreadful. A remedy for this issue comes from scaling solutions such as sidechains and rollups that allow blockchains to reach different market needs. The current scaling solutions are taking the blockchain space into a multi-chain, design-tailored environment.

There’s been a lot of development following this trend, including different layer 1 (L1) blockchains, such as Ethereum, Cosmos and Polkadot, sidechains such as xDAI, Polygon and Skale, and different layer 2 (L2) scaling solutions on top, such as optimistic and zk roll-ups. A substantial uncertainty facing this new multi-chain paradigm is how to scale blockchains to a large throughput without completely breaking interoperability. Users are already used to high composability and simply transferring value between protocols in L1. Nevertheless, most scalability solutions for the L1 systems, such as L2, break composability.

Bridges are protocols to transfer assets from one chain to another and achieve some degree of composability and interoperability between two chains. We believe bridges will play an essential role in the development of the ecosystem.

Bridges inherit the oracle problem

Blockchains cannot access data from outside of their network. Communication between chains depends on an entity or a third-party service to provide information on the other chain’s actions, commonly known as an oracle. As some blockchains are very interrelated, an oracle can be embedded in the blockchain protocol itself. When the communication between two chains is made at the protocol level and by their own chain nodes, we call it a cross-domain message passing. If the chain nodes do not feed the oracles, a new entity or protocol needs to assume the role, introducing new trust assumptions.

We can divide the relationship between chains into three groups: rollups, sidechains and distinct L1 chains. Rollups inherit the security model of their base layer. To accomplish that, the chain’s communication is made at the chain protocol level until reaching the base-layer finality. Sidechains have their own security model, but their nodes track some of the main-chain actions, feeding themselves with information of the base layer. Finally, distinct L1 chains have no relationship whatsoever, trusting on third-party to provide information across them.

This post will stretch out the definition of an L2 chain as any chain with cross-domain communication. We will use L2 for both roll-ups and sidechains, although other literature distinguishes between them based on their security guarantees.

Ethereum scaling solutions can use cross-domain communication to transfer assets in the direction L1 -> L2. A token is locked in a smart contract on Ethereum and the L2 nodes feed this information on-chain after finality, allowing the user to mint the same amount of tokens in the new chain. The process takes as much time as achieving finality guarantees of L1, usually a few minutes.

The inverse is more complex and depends on the chain nature. Because of the challenge period of optimistic rollups, transfer from L2 -> L1 takes days (generally one week) to reach finality. Only after, the user is allowed to receive its token back on L1. A withdrawal from a zk-rollup to layer-1 cannot be completed until a validity proof has been executed, increasing exit times. Returning the tokens is very slow, so fast withdrawal methods, provided by generic bridges, are needed for a better user experience.

Native and Generic bridges

When cross-domain message passing is used to transfer assets into rollups, we call them native chain bridges. As the assets using this process inherit the chain security, users will likely converge to use these tokens as the canonical representation of the token on L2.

Generic bridges protocols, which are the focus of this article, aim to convert L1 tokens to their canonical L2 representations and not just create a new representation on the new chain. Thus, when non-canonical representations are used, the protocol will need to implement a market and attract liquidity to support active trade between their token vs. canonical token pairs.

Generic bridges also assume the role of bridging tokens between two scaling solutions (L2->L2) using the underneath layer. In this case, generic protocols can offer some improvements compared to transferring assets using cross-domain message passing:

• It allows users to get upfront liquidity without waiting for finality on the underneath layer;
• It improves scalability, aggregating multiple transfers in one proof;
• It can increase capital efficiency by settling transactions that cancel each other.

The process of bridging tokens is very capital intensive and requires liquidity for two main processes, which will be better explained below:

• Anticipating liquidity while the final guarantees are achieved through message passing and;
• Supporting a market for trading between the representation and canonical tokens.

If not enough liquidity is available for a trade, the bridge process will suffer high slippage, high fees and deteriorate the user experience. Thus, protocols that manage to attract the most liquidity will likely be the most successful.

Generic bridges approach

The basic idea of a generic token bridge consists of locking a native token (e.g., DAI) in the native chain and minting a wrapped asset (e.g., wDAI) in the secondary chain. Or making the opposite transfer, burning the wrapped asset and unlocking the native token in the native chain.

Transferring between two secondary chains combines the above actions; burning wrapped assets in the originating chain and minting the corresponding amount of wrapped assets in the target chain. If a canonical token exists in the secondary chain, the process also includes trading between the wrapped asset and the canonical asset (e.g., wDAI — L2DAI).

The protocol needs to ensure that the total supply of each wrapped asset is always backed by the same amount of collateral in the native chain. Thus, the most critical step of the process is watching for events on the originating smart contract and relaying the information to the target blockchain. Only after this proof is submitted, the following chain can mint/release tokens. If the oracle is cheated, a malicious user can withdraw the protocol collateral or mint an arbitrary amount of wrapped assets and drain the trading pools.

In decentralized protocols, there must be a method in which oracles are financially liable for the proper operation of the protocol. Those methods are the main differentiator between projects. This post will drive on some of the approaches taken by some of them below.

Trading markets

Users are likely to use the canonical token of the chain. Thus, a trading market between each wrapped token and the canonical token needs to be available. Autonomous market makers (AMM) for similar assets are the usual market construction used in this case as, under normal conditions, the relationship between the tokens is worth close to 1 (assuming 1:1 construction). Any LP of these pools needs to trust the protocol’s security mechanism because they assume the risk of wrapped assets losing the peg. A premium relative to the canonical token is likely to reflect the system’s trustiness.

Risk assessment for each actor.

To compare different bridge models, one differentiator is the level of security provided for each actor. The risk of collusion or oracle cheating is very different from bridge users and LP / token holders.

First, bridge users can be defined as the actors that just use the bridge for the specific cross-chain transaction but, once in the new chain, they use the canonical tokens. LP/holders are the actors that hold the wrapped asset for a more extended period.

Bridge users face a lower risk than LP because they have much lower exposure to the protocol. They are only exposed from depositing their asset until they receive the canonical/native token. In case of any catastrophic system malfunction, other users or the market are likely to raise an alarm on the severity of the flaw, preventing other users from using the bridge after. LP/holders have a continuous exposition to the system security guarantees. A user that uses the bridge but then holds the wrapped token faces the same risk as a LP/Holder.

Projects designs

Centralized wrapped tokens (like WBTC)

• Bridge user risk: low.
• LP/Holder risk: Centralized trust assumptions

In a centralized bridge, the protocol authority is responsible for two roles, the custody of the funds and the bridge oracle’s correct behavior. Any minting/burning of pegged assets is done in a centralized manner. Security is based on Proof of Authority (PoA) taken to the extreme. Another disadvantage of this system is that minting/burning is not permissionless. Centralized bridges are currently the most popular security model of BTC on ETH, with the caveat that bitcoin is not Turing complete.

Ren Project

• Bridge user risk: very low.
• LP/Holder risk: PoS — Governance

Ren protocol is very specialized in UTXO blockchains such as Bitcoin, where the custody of the asset is a problem. In Ren, darknodes assume the role of a multi-sign custodian of the assets in the UTXO chain. Although it’s a critical role, the custodian is outside the scope of this post. Darknodes also act like oracles for transactions in the other chain and stake REN as an incentive to act correctly. RenVM can use an off-chain governance process to slash the bonds of malicious darknodes and may use this capital to restore the one-to-one peg by buying back and burning the same amount of pegged assets. Lastly, Ren allows the minting/burning of pegged assets by anyone, which increases the volume going through the bridge and increases protocol revenue.

deBridge Finance

• Bridge user risk: very low.
• LP/Holder risk: PoS — Governance

deBridge relies on a set of Chainlink validators to attest that a token has been locked up in its native environment and then mint a token representation in the destination environment. Validators place collateral as a guarantee and it may be used for slashing and compensation in case of an incorrect operation.

As a method to avoid validators submitting transactions to Ethereum, validators submit transactions and signatures to a cheap blockchain (Arbitrum), where they are stored (proof of data availability). Users claiming or minting assets can provide this data to enable their action. In this case, the user bears the cost of taking the proof to Ethereum and validating the signatures.

Oracle staking collateral can be deposited in two ways, validators staking their own capital and also any user can help increase the collateral of a validator. Users staking need to trust the validator’s actions and are rewarded with a portion of the validator payout. Strangely, this capital does not discourage collusion, as the validator does not own it, although it may help the system restore its peg in case of an attack. The system relies on governance to punish malicious behavior. Governance can also change parameters in the incentive mechanism; there is no smart contract enforced way of resolving disputes.

In addition, as governance can change the stake sizes, there is no explicit cryptoeconomics imposition, defined as: malicious behavior should cost more for the attacker than what the upside is. However, staked collateral can provide some level of financial incentive depending on its size relative to the volume going through the bridge and the liquidity of trading pools.

Hop Protocol

• Bridge user risk: none.
• LP/Holder risk: underlying blockchains.

Hop is very focused on rollup chains but can be used on any chain with cross-chain communication. It uses intermediary tokens called Hop Tokens (hETH). A bonder provides up-front liquidity on the destination rollup for a small fee while the transfer propagates through the chains using message passing. The bonder is responsible for being the oracle to the destination chain. Eventually, when the transfer reaches finality on its destination, the Bonder’s funds are restored.

Bonders watch both chain events and need to lock collateral matching all assets going through the bridge to which he is attesting. Fees for this front liquidity are embedded in the pair premium. The system relies on arbitrageurs to take advantage of the price difference and rebalance liquidity across the supported chains. Security is entirely based on the underlying blockchains smart contracts.

Celer Network

• Bridge user risk: none.
• LP/Holder risk: underlying blockchains.

cBridge extends Celer’s state channel network’s functionality by enabling LP nodes to “multi-home” their assets in different chains. Being a state channel solution, it never creates a wrapped token and uses the canonical token or relies on another wrapped token.

When you need to transfer some assets from chain A to chain B, your assets will first be sent to a relay node on chain A. Since the relay node also has liquidity on chain B, it will further send the same amount of assets to your destination on chain B.

Relay nodes are the liquidity providers in cBridge and need to run special software watching the chains and the channel state, making it challenging to attract liquidity. The relayer node for each transfer request is currently selected off-chain by a gateway server, representing a DoS vector. The selection criteria are based on the historical relay success rate, the charged transaction fee rate and the number of relayed transfers.

If unidirectional transfers are frequent, liquidity might get exhausted and relay nodes need to rebalance using a native bridge or the wrapped token method. A major disadvantage is that it requires bridge users to be online and report malicious behavior in the channel.

Connext Network

• Bridge user risk: none.
• LP/Holder risk: underlying blockchains.

Connext uses a similar architecture to a state channel but with an interactive process. The user broadcasts an intention to do a transaction to the network. Routers respond with sealed bids with a specific time and price range commitment. After, the user submits a transaction to the Transaction Manager contract, locking up the funds on the sending chain together with the bid. The Transaction Manager on the receiver-side chain locks up the router’s corresponding liquidity amount, incentivizing him to complete the transaction. The user is now able to send a message claiming the locked funds on the receiver-side chain. Then, the router submits the same signed message and unlocks the original amount. If a transaction is not fulfilled within a fixed expiry, it will revert and each part can reclaim funds. Transactions can also be canceled unilaterally from either actor.

Conclusion

We hope that with this post that you’ve managed to create a better framework on how to evaluate each bridge design. It is possible to see how diverse they can be, spanning over a large decentralization and trustlessness spectrum. Right now, the first projects are already being launched and testing on the vast chain’s options. There are several other specific details in each bridge project which we’ve glossed over entirely in this post. We are excited to watch and learn how each solution will play out.