Bridges in Crypto-Space

Authored by Ben Adar

An analysis of the many cross-chain communication protocols connecting crypto-space

But first, what is a bridge?

A bridge in the crypto world is like a bridge in the physical world. They connect two distinct locations or communities so that traffic and resources can go back and forth freely. More often than not, blockchains develop in isolated environments, and chains that operate under different consensus rules have no way of communicating with each other. The need to connect these isolated environments becomes critical to ensure scalability and connectivity. Why shouldn't someone on Bitcoin be able to access the information and resources on Ethereum? How should a blockchain communicate between its own Layer 1 and 2?

This is where bridges come into play.

Bridges allow for the sharing of valuable data and traffic between the many blockchains and layers. More clearly put, with a bridge, someone in Chain A can receive data from Chain B and back, achieving what is known as interoperability. Other than wrapping a token like BTC and bridging it to ETH and then moving that newly minted tBTC over to any DeFi protocol, the central importance of interoperability between blockchains is that it increases the rate of mass adoption in the space. Users don't need to hesitate to start on one chain if it's just as easy to access protocols, information, and value from any other chain.

Bridges communicate information between networks. This made me consider the history of inter-network communication, which inevitably looks at the history of the internet, a series of separate networks working together and sharing information. Today in the Web 2.0 world, these inter-network communications are happening behind all of our favourite websites and apps. The Internet Protocol (IP) is a communication protocol widely used for relaying datagrams (a basic transfer unit) across network boundaries. While IP does not precisely use bridges, they have a routing function that enables networks to communicate with each other. This internetworking function of IP binds together what the world now knows as the internet. It is only natural that inter-network communication comes to Web 3.0 with decentralized technology and the blockchains that power them.

So, how do bridges work?

Bridges exchange information either remotely or locally, which is to say they are bridging between different domains. Local domains are the different layers, tools, and protocols within a single blockchain, while remote domains are separate blockchain ecosystems entirely. Either way, bridges connect these domains and establish communication between them. For this article, we will mainly focus on the bridging happening on a remote level, i.e., across separate blockchains.

Remote bridging that's happening from Chain A to Chain B, is generally structured for the bridge to lock the token in Chain A and mint a fresh one onto Chain B. The total amount of circulating tokens remains the same but is split between the two chains, in this case, Chain A and Chain B. If Chain A had ten tokens and then sent five over to Chain B, Chain A would still have ten tokens (five locked), but an additional five of them would be minted on Chain B. If at any point the holder of the minted tokens wants to redeem them, they can burn them from Chain B and unlock them on Chain A. Since Chain A always had a locked copy of the token, the token's value stays consistent with the chain A market price. This lock-and-mint/burn-and-release process is how the amount and cost of the tokens sent between the two chains remain the same.

Bridges communicate with blockchains in many different ways. Primarily, these processes for data exchange can be broken down into trustless and trusted. Trusted bridges usually have a federation of relayers communicating, bringing information and tokens from one chain to another. On the other hand, in a trustless system, the users and developers do not need to trust a federation or any centralized entity to move data and tokens from one chain to the next.

Before moving on, as a valuable primer, Summa founder, cLabs protocol engineer, the best hair in Ethereum 2019, and Ethereum core developer, James Prestwich, shares his expertise on cross-chain communication at both CSCON[0] & EthCC:

Real quick, let's break down some technical terms.

SPV

SPVs (Simple Payment Verifications) allow clients to verify a transaction on the blockchain without downloading the entire thing. Users only require the block's header to confirm that the transaction exists on the block entirely.

Relayed

A Relayed SPV works by submitting and verifying headers through the sending chain. A smart contract on the sending chain stockpiles the headers and sends an SPV proof to the smart contract counterpart on the receiving chain. This way, there are no intermediaries in the movement between chains. The information gets relayed across all the connected chains.

Stateless

On the other hand, a Stateless SPV works by submitting only the relevant headers of a specific transaction. Meaning that the receiving chain does not have to store a complete record of headers, lowering the storage requirements. This method is only valid for PoW systems. In a Stateless model, the assumption is that the amount of work required to produce a sequence of valid headers that prove a fraudulent transaction (one that did not occur on the origin chain) exceeds the value of the transaction itself. For honest transactions, the origin chain produces sequences of headers for free as part of the PoW consensus. Like the Relayed SPV, no intermediaries control the movement between chains; instead, it's through smart contracts.

Federation

A Federation is when a group of participants work together to verify and confirm transactions between chains. This can be any n amount of signers which change based on the security model's requirements. The individuals in these federations work as nodes, operating the flow of information between chains.

Bonded

In a Bonded Federation, the signers have to stake a certain amount of money to verify transactions between chains. This increases the level of security as staked funds get slashed from the malicious actors signing fraudulent transactions.

Trusted

Trusted Federations are trusted to have the best interest of the bridge at heart. These groups have no incentives to commit or protect from fraud, merely to keep the transactions going.

Let's look at some bridges!

tBTC

Let us Start with tBTC, which is known as a wrapped token. What this means is that tBTC is a Bitcoin token that is usable on Ethereum. One BTC equals exactly one tBTC. If users want to move their tokens from Bitcoin onto Ethereum, a bridge locks up the BTC on Bitcoin and Mints the equivalent tBTC tokens on Ethereum.

Security Model

tBTC has minimized trusted features. In this model, for one tBTC minted on Ethereum, a bonded ECDSA (Elliptic Curve Digital Signature Algorithm) keep is requested from the Keep network to sign for 1 BTC. Smart contracts use an ECDSA keep to communicate with each other cross-chain, while the Keep network is the infrastructure behind tBTC, ensuring privacy during exchanges. After the bonded ECDSA keep is requested, a signer group is selected randomly from a pool of validators and puts down 150 percent of the value of 1 BTC in ETH as collateral. The signer group will then generate a bitcoin wallet using a threshold ECDSA protocol. The user sends 1 BTC to the Bitcoin wallet. Next, the user generates an SPV proof of their deposit transaction and sends it to the Ethereum chain. The user is then able to mint the equivalent tBTC. If users want to do the opposite and redeem tBTC back into BTC, they must undergo the same process.

Signer groups of three nodes, randomly selected from a large pool of validators, hold Bitcoin deposits. The nodes are then randomly selected from a large pool, reducing any negligence or manipulation.

Incentives

Over-collateralizing, the signers put up 150 percent of the value of the bitcoin deposited, which incentivizes honest behaviour on the network. This over-collateralizing means that signer fraud will receive harsh penalties, like the slashing of their collateralized funds.

Limitations

One of the limiting factors for tBTC is the steep ratio of collateral that signers must stake. While the tBTC developers are working on a solution to reduce the amount of collateral needed, this problem will continue to persist as long as there is some form of a trusted communication protocol in place.

Cosmos IBC

The Cosmos IBC (Inter-blockchain communication) protocol, on the other hand, is used very differently. Cosmos is an internet of sovereign blockchains (called Zones) centred around the "Hub" chain, whose primary function is to facilitate communication between zones. That's where the Cosmos IBC comes in. IBC ensures that all the ledgers supported on the network can actively communicate with each other. To understand more about how Cosmos IBC works, check out their Github.

Security Model

Cosmos IBC uses relayed SPVs to maintain a trustless connection between zones (Cosmos supported blockchains). To communicate with another zone, the blockchain sending the data needs to commit some state to a defined path dedicated to a specific message type and destination. A relayer process then monitors for updates on these paths and relays messages by submitting the data stored under the path and proof of that data to the correlating chain.

Below is a short description of how a token transfers through IBC:

1. Tokens on Chain A are locked in escrow by the IBC module. An outgoing packet containing the sender, receiver and amount is produced.

Relayer receives and transfers packet

2. Packet gets received on Chain B. If verified, new tokens of the same amount are minted and transferred to the receiver on Chain B.

3. Chain B's IBC module will produce an outgoing packet to acknowledge the transfer of tokens.

Relayer receives and transfers packet

4. Packet gets received on Chain A, and the transfer gets completed.

Note: If the packet included a code to identify that the transfer failed, the transfer would get undone on Chain A. Also, if Chain A did not receive the Acknowledgement within a timeout period, the transfer will get undone.

Incentives

The main incentive for IBC is that it allows blockchains to communicate with each other through complete trustlessness and with no friction.

Just like a port city is valued by the amount of trade that flows through it, the Cosmos Hub's value is measured by the value of blockchain economies that conduct business on the Hub through IBC.

• Peng Zhong, CEO of Tendermint

Limitations

The only limitation is that users need to have their blockchains built on top of the Cosmos network to communicate through Cosmos IBC.

Cosmos Gravity Bridge

The Cosmos Gravity bridge transfers funds and data between Ethereum and Cosmos. With millions of Atoms staked on the Cosmos Hub, the Gravity bridge will be highly secure. The Gravity bridge, explicitly designed for the Cosmos Hub to pull as many transactions and data from Ethereum as possible, consists of 4 parts:

• Gravity.sol is the smart contract on ETH for updating the Merkle roots of Cosmos. Controlled by the validator set on Cosmos, the security depends on the security of the PoS implemented on the Cosmos chain.

• The Gravity module is implemented on the Cosmos chain and runs alongside validators. It's responsible for minting tokens.

• The orchestrator works alongside the Gravity module. Validators are required to run the full ETH node, which the orchestrator uses to listen to events from Gravity.sol and broadcasts it to the Cosmos chain.

• Relayers - Gravity works with transaction batching to save gas cost for token exchange from Cosmos -> Eth. Batching of transactions is done by a set of relayers who submits the batch to Gravity.sol.

Security Model

[I]f you trust the [Cosmos] Hub to secure your bridged assets, you can trust Gravity to bridge them.

-Co-Founders of Althea, Jehan Tremback, Deborah Simpier, Justin Kilpatrick

The Gravity bridge uses almost the same Relayed SPV model as IBC. The big difference is that Gravity uses an Ethereum smart contract with the primary function to lock up ERC-20 tokens on Ethereum to be minted on Cosmos. If a user wants to move their tokens from Cosmos back onto Ethereum, the smart contract will release the locked tokens and send them to the correlating address.

Incentives

The Gravity bridge is not yet live, but the Althea team has announced an upcoming incentivized testnet that will offer validators, relayers, and hackers prizes.

There are no clear incentives for when the network goes live at this point.

Limitations

While Gravity connects two huge communities, Ethereum and Cosmos, the bridge is limited to those two communities alone.

Rainbow Bridge

The Rainbow bridge connects Ethereum to the NEAR network and allows for assets to flow freely between the two chains while allowing users to bridge any ERC-20 token onto NEAR. ERC-20 tokens are Ethereum tokens made for deploying smart contracts. Many wrapped tokens, like tBTC, are ERC-20 tokens that are accessible across chains. Users and developers might want to push their traffic through NEAR to take advantage of low-gas fees while still enjoying high-speed performance and Ethereum's smart contract capabilities.

Security Model

The Rainbow bridge uses trustless relays to bridge NEAR and Ethereum while requiring PoW to validate the transaction. The bridge also uses an Ethereum light client on the NEAR side, allowing any to submit headers that can get validated on-chain. This EthOnNear client uses DAGs which are precomputed to make the computation of Ethash (a space hard hashing algorithm) viable on-chain on NEAR.

With finality assumed after twenty-five block confirmations for relayed Ethereum blocks on NEAR, headers from either Ethereum or NEAR can get relayed by any actor and rejected if invalid according to the previous headers and proofs.

Rainbow uses optimistic fraud proofs to avoid performing the costly Ed25519 signature verification on-chain on the Ethereum side. Relayers must bond some ETH with their header proposal, either burnt or claimed by an actor who submits a valid proof within some challenge window. The bond must be enough to cover the gas required to make a challenge. After the window expires, the signature is deemed valid. Note this will not be needed if an Eth Ed25519 precompile is added (EIP-665).

Incentives

Currently, there are no incentive schemes announced.

Limitations

Rainbow only stores seven days' worth of headers on the NEAR side (to prevent unbounded state growth). Any actor must complete a transfer from Eth to NEAR within seven days or potentially lose assets. The EthOnNear client will expire after four years due to reaching the end of precomputed DAGs. This setback Requires posting a bond and a four-hour challenge window until EIP-665.

Learn more here.

Parity Bridges

Parity bridges use off-chain actors to relay headers, and GRANDPA finality proofs from A to B. B use these headers to run a light client of A and inside the runtime of B. This process is known as header sync. Proofs of specific transactions get relayed from A to B, and their validity gets checked against the light client.

Security Model

Any actor can relay headers and finality proofs. If the light client gets correctly initialized, it's possible to check and reject invalid headers or proofs on B. Header relay messages need not even be signed.

Provided the header sync is maintained, B can verify an inclusion proof of any transaction in A. Making the protocol essentially trustless as any transaction message can be verified on-chain.

Incentives

There are no incentives for relaying headers, although the headers must be relayed before incentives can be claimed for relaying messages.

Incentives for relaying messages can be elegantly constructed in the case of a bi-directional bridge. (e.g. A is syncing B's headers, and B is syncing A's headers.) Relayers pick up messages from A, submit the proofs to B and then submit a proof of their submitting the message transaction back to A. Upon verifying this round trip, a contract on A can release a reward to the relayer.

Limitations

The bridge is limited to chains using Substrate's GRANDPA finality or Ethereum's proof-of-authority.

Celo Optics

Optics is the Celo-designed cross-chain communication protocol. Optics takes quite a different approach when it comes to bridging blockchains. The design for the protocol came from looking at Optimistic Rollups, an Ethereum layer two scaling solution. Optimistic rollups work by incorporating actors known as "aggregators" that compile large amounts of transactions, actively rolling them up into one block. These "rollup blocks" are then published on the main chain via a smart contract. This process gets considered optimistic because aggregators publish only the bare minimum of data needed with no proofs. If an inconsistency does arise between the state of the rollup and the state of the main chain, then the aggregator can publish a fraud-proof to dispute a fraudulent transaction. If it is indeed fraudulent, then the state will get rolled back to the previous valid state.

The Celo team built Optics to resemble optimistic systems like rollups. It aggregates events on the origin chain where they are signed by a bonded actor called the updater and replicated to other chains. Data on the destination chains is considered valid after a certain period passes. During this time, trusted participants have a chance to either attest and submit fraud proofs over the data package getting sent through Optics.

The team at Celo expects Optics to cut 90% of gas costs compared to more common header relays, like the ones discussed above. The protocol will also be available for all smart contract chains and rollups.

Security Model

Optics is usable in any chain that supports basic smart contract implementations, only has a latency of a few hours, compared to the one-week latency period that optimistic rollups provide, and requires only about 120,000 gas overhead on message senders.

The Celo team uses a notary service as a comparison to their protocol.

The Optics' notary-like system works as follows:

The sending (or "home") chain produces a series of documents ("messages") that needs notarization. A notary (called the "updater") is contracted to sign it. The notary can produce a fraudulent copy, but they will be punished by having their bond and license publicly revoked. When this happens, everyone relying on the notary learns that the notary is malicious. All the notary's customers can immediately block the notary and prevent any malicious access to their accounts.

- Celo Docs

Since Optics is working across multiple chains, the home chain acts as the source of truth. Meaning the sending chain will contain the "home" contract where the messages await to get processed. Once the messages are committed to the merklized "message tree," the root of that tree is notarized and relayed by the updater to the receiving chain in an "update." The updates are signed and approved by the updater, committing to the previous root and a new root.

Optics allows any chain to implement a smart contract with the data of the updater and the current root. Celo calls this smart contract a "Replica" contract. This "Replica" essentially ensures that the receiving chain reaches the same root as the "home" chain. Since the root will ultimately be committed to the message tree, the message will be proven and processed once it gets transmitted.

A significant difference highlighted by Celo is that Optics permits fraud. Through their security model, participants can prove fraud at any time to the home contract on the sending chain. So to curb updaters from signing off to fraud, the updater has to submit a bonded stake on the home chain, which will get slashed as a penalty for accepting a fraudulent update. Not only does a fraudulent signer's bond gets slashed, but they are also exposed to all the other participants on the network, meaning users can avoid malicious actors.

Incentives

The main incentive that Optics brings to the table is its security model. By focusing on fraud publication instead of fraud proofs, Optics can increase speed and lower costs for sending messages. This also allows Optics to handle any fraud coming through the bridge by adding cost penalties to all conspiring updaters. Users will always learn of any potential attacks and fraudulent transactions long before any harm occurs.

Limitations

Currently, Optics is getting developed to bridge Ethereum to Celo. But a fascinating aspect of the project is that it uses a single message sending mechanism for communicating with other chains, which means that adding an additional chain is easy and will not require any modifications to the sending process. So while Optics might currently be focusing on Ethereum and Celo, the future is looking very promising as any number of platforms can take advantage of Optics and join the wider crypto-space.

ChainBridge

ChainSafe's ChainBridge is highly compatible with any number of networks. This compatibility is due to the modular and multi-directional design of the bridge, allowing it to be super composable. If Chain A can connect to Chain B, Chain A should also join Chain C and vice versa. The most remarkable thing about ChainBridge is that adding a new type of transfer should not require a full re-deployment of the suite of tools, instead, requiring only relatively minor modular upgrades, making it accessible to nearly any blockchain!

Currently, ChainBridge can connect all Substrate and EVM-based chains. Meaning, any blockchain built on top of Substrate can use Chainbridge with any blockchain built on top of the EVM and back. But, because of ChainBridge's modular design and multi-directional flow, it has the potential to connect any type of chain in any direction!

Teams from all over the space have already started implementing ChainBridge's protocol into their projects, modulating it to their specific needs, with many more to come!

To learn more about the future vision for ChainBridge, check out Timothy Hao Chi Ho's excellent article! A 2.0 Vision for ChainBridge.

A 2.0 vision for ChainBridge

Security Model

A bridge contract (or pallet in Substrate) on each chain forms either side of a bridge. Handler contracts allow for customizable behaviour upon receiving transactions to and from the bridge, such as locking up an asset on one side and minting a new one. It's highly customizable - you can deploy a handler contract to perform any action you like.

In its current state, ChainBridge operates under a trusted federation model. Deposit events on one chain get detected by a trusted set of off-chain relayers who await finality, submit events to the other chain and vote on submissions to reach acceptance triggering the appropriate handler.

Research is currently underway to reduce the levels of trust required and move toward a fully trustless bridge.

Incentives

In ChainBridge's trusted federation form, there are some minor incentives. There are currently fees for using the bridge, and these usually get distributed to relayers in most deployments. These fees incentivize the relayers to keep sending data across the bridge.

In the future, this will change to a trustless system where incentives might be further integral to the transfer of data and the network's security.

Limitations

The only limitation that ChainBridge has is its trusted federation of relayers. Users need to trust outside actors to move their data and tokens between chains. Again, this will not be a problem soon when ChainBridge moves to a trustless security model.

Every single one of these bridges has its use-cases and brings its benefits to the table. Bridges offer decentralized communities choice and freedom of growth. Every bridge opens up a community to the larger blockchain universe.

Every bridge fosters growth!

As the blockchain space continues to grow, so do the individual communities around these blockchains. But for the blockchain world to be truly decentralized and open, these communities need to open up to each other. The wonderful thing about the blockchain universe is that the people in these communities, the developers, and the users, must cooperate to grow their communities. Bridges cover the gaps between ecosystems so that growth is not limited to one singular chain. Bridges spread growth to every corner in the blockchain world, ensuring widespread scalability and cooperation!

Get Involved!

You can check out the ChainBridge GitHub repo here.

If you have any questions, please pop into our Discord. We will be more than happy to answer any queries!

You can also reach out to us if you want to explore bespoke implementations of ChainBridge to suit your use case. Also, feel free to contact us if you would like to get involved in the project in some other capacity.

Learn more about ChainSafe by visiting our website, through our Medium, via Twitter, or visiting the ChainSafe GitHub.

Acknowledgements

Special thank you to Timothy, Lerna, Willem, Taha, Cindy and Thomas for making this piece possible!