By Angela Potter, Lead Product Manager at ConsenSys and EEA member, with input from the EEA Crosschain Interoperability Working Group
The future of blockchain is multichain. Layer 2s are a key part of the Ethereum scaling strategy, and we’ve seen significant growth of sidechains and alternative Layer 1s over the past year. Although there is some debate about what this multichain world will look like in the future, we know that new blockchain networks are emerging rapidly, and users have an increasing need to interact with multiple heterogeneous blockchains in a cohesive way.
Today, the main crosschain use case is to bridge assets from one chain to another in order to access some opportunity that’s only available on a particular chain. The opportunity might be purchasing a digital asset; participating in a high-yield defi protocol; playing a blockchain-based game; or simply doing business with an individual on a different chain.
We’re just scratching the surface of the opportunities (and risks) of crosschain bridges. In the last few months, two massive bridge hacks resulted in ~ $ 1 billion in total stolen funds. The Wormhole bridge hack ($ 320M) was due to a smart contract bug; whereas the Ronin bridge hack could have been prevented with a more decentralized bridge design (see more discussion in the External Validators section below). Transparent and trust minimized bridge design has never been more important.
What does it mean to bridge assets?
Though we can imagine countless ways that multiple blockchains may need to interact, today’s technologies are primarily focused on enabling users to move funds from one chain to another. How do bridges actually accomplish this? There are two high-level methods that we see today.
1. Asset transfer
Asset transfer involves locking tokens in escrow on Chain A, and minting some equivalent (“wrapped”) tokens on Chain B. When bridging in the opposite direction, wrapped tokens are burned on Chain B and unlocked from escrow on Chain A. With this method , the tokens on Chain B are always directly backed by funds held in the bridge contract on Chain A.
The main drawback of this approach is that there may be a large store of value locked in the bridge contract on Chain A. If these tokens were to be compromised, all wrapped tokens on Chain B would lose their value.
2. Asset exchange
With an exchange, a user on Chain A trades tokens with a user on Chain B. No funds are escrowed beyond the execution of the exchange, and no tokens need to be minted or backed; any two native tokens can be directly traded. The disadvantage is that if I want to move funds to another chain, I need to find a user (or liquidity provider) on my destination chain to fulfill the other half of my trade.
How are bridges validated?
In order to conduct an asset transfer or an asset exchange across two blockchains, parallel transactions must occur on each chain. There must be some mechanism to ensure that funds have in fact been paid on the source chain, so that corresponding assets can be minted, released, or transferred on the destination chain. These methods vary in their trust models: a trust minimized bridge adds no new trust assumptions beyond the two chains involved in the transfer, which is ideal; but this can be difficult to achieve in practice as discussed below.
There are four primary methods for validating the source transaction and kicking off the destination transaction.
1. External validators
A trusted set of validators verify that tokens have been deposited on the source chain, allowing tokens to be minted or withdrawn on the destination. This method can be used for asset transfer or asset exchange, and it’s easy to set up; but it adds additional trust assumptions beyond the two chains involved in the transfer. This is the most common verification method among bridges on the market today, with the total number of validators generally ranging from one to fifty depending on the bridge, and some majority needing to sign each transaction in order for it to go through.
The recent Ronin bridge hack for $ 650M occurred when a malicious actor acquired the keys for 5 of 9 validators, which enabled them to sign a fraudulent transaction. This highlights the importance of having a large number of independent parties securing the bridge (or using one or more of the other validation methods outlined below).
In this method, transactions are assumed to be valid unless flagged by a watcher. Each submitted transaction has a challenge period during which watchers get rewarded for identifying fraud. Once the challenge period ends, the transaction is finalized. This approach has fewer trust assumptions than external validators, as it only requires a single honest party to prevent fraud. However, transactions take longer (anywhere from 30 minutes to a week) due to the challenge period, and watchers must be properly incentivized to continuously monitor transactions. A native exit from an optimistic rollup is the classic example, using the underlying security of the rollup to move from L2 to L1; but you can also have a standalone optimistic bridge protocol with its own set of external watchers, which can be used across any two chains.
3. Atomic swap
Used for asset exchange, this method relies on contract code for its security. The most common approach is a hash timelock contract (HTLC), where users may only retrieve funds on their respective destination chains after both parties have deposited funds on their source chains. If one party fails to deposit, everything is reverted after a timeout period. This method is trust minimized, but requires both parties to stay online for the duration of the swap in order to withdraw funds on the other side, which can cause friction for end-users.
4. Light client relay
Block headers and proofs are forwarded from the source chain to a contract on the destination chain, which verifies them by running a light client of the source chain’s consensus mechanism. This method is trust minimized and most commonly used for asset transfer, but it can be applied to asset exchange or other more general use cases. However, implementation comes with a lot of overhead: a light client must be developed for every pair of source / destination chains that the bridge supports; and once developed it can be computationally intensive to run.
There are many approaches to bridging, some of which combine several of the designs outlined above. There are many crosschain projects out there, including interoperability networks like Cosmos, Polkadot, Chainlink CCIP, and Hyperledger Cactus; but for the purposes of this overview we’ll focus on bridges that support Ethereum mainnet. Here are some examples of bridges in the market today that support bridging between these networks.
Connext plans to release a new upgrade in June called Amarok, switching their design from atomic swaps to an asset exchange network that uses Nomad’s optimistic protocol to settle fraud claims. Liquidity providers enable fast transfers by fronting funds while awaiting the 30-minute challenge period on Nomad.
Funds in Hop are locked on Ethereum and secured by the native rollup bridge, while liquidity providers allow fast transfers between L2s by fronting funds to mint tokens. Wrapped tokens are automatically swapped back into canonical tokens via AMMs as part of the bridge transaction.
NEAR Rainbow Bridge
Rainbow Bridge enables asset transfer between the Ethereum and NEAR networks via light client relay. A NEAR light client runs in a contract on the Ethereum network, and an Ethereum light client runs in a contract on the Near network. A relay service forwards block headers from one network to the other to be verified by the light clients on each side. This is combined with an optimistic design, where watchers can challenge invalid transactions from Near to Ethereum within a 4-hour period.
Stargate is an implementation of LayerZero, which is an asset exchange protocol that requires an oracle and a relayer (two separate parties) to validate each transaction. Stargate also recently rolled out a Pre-Crime System that simulates each transaction and checks that the resulting bridge state is considered valid before finalizing it.
Wanchain enables asset transfer between multiple Layer 1 and Layer 2 networks. A threshold number of external validators must sign off on each transaction using multiparty computation. Validators must stake collateral for each transaction they process to incentivize acting in good faith.
The crosschain space is evolving quickly, and the fragmented and ever-changing nature of crosschain technology has made it challenging for enterprises to participate. As the space matures, enterprises have an opportunity to use crosschain technologies to unlock value in all corners of the blockchain ecosystem; but in order to do so, we’ll need to solve the top barriers to adoption that enterprises face:
- Security concerns and unclear best practices
- Disparate bridge approaches that are not flexible or consistent enough to build on
- Privacy and regulatory requirements
The EEA has released crosschain security guidelines and is working on draft interoperability standards to start addressing these barriers. Stay tuned for the next article in the series on the EEA Crosschain Interoperability Working Group.
To learn about the many benefits of EEA membership, reach out to team member James Harsh at [email protected] or visit https://entethalliance.org/become-a-member/.
Follow us on TwitterLinkedIn and Facebook to stay up to date on all things EEA.