This blog is a part of our “Engineering at Arcana” series where our developers write about all things technology. This week, we have our blockchain developer Rohith Narahari write about bridges in blockchains, why they’re needed, and the different kinds of existing bridges being implemented.

One of the biggest limitations of many blockchains is interoperability. Both assets and data cannot be securely transferred from one blockchain to another, whether it is for scalability, participating in DeFi transactions on another chain, or securely storing files. Naturally, this makes it hard to build cross-chain applications as well.

Blockchain bridges essentially eliminate the interoperability limitations in blockchains. With the help of bridges, cross chain applications that consist of smart contracts deployed across multiple blockchain networks can be built. It is worth noting that the speed of data transfer as well as the level of security of a cross chain application is also determined by the bridge type.

Before moving on to the various types of bridge designs, it is important to understand the text-book, technical definition of a blockchain bridge.

A blockchain bridge is a connection between two blockchains that allows the transfer of arbitrary data and/or tokens from one chain to another.

But why do we need bridges? It is because smart contracts only work with on-chain data.

Let’s say you have two smart contracts that are trying to communicate with each other, and each belong to a different chain. Since these contracts are on different chains, they can’t facilitate data transfer or token exchange. Through an off-chain component (which is a bridge in this case), you can facilitate communication between smart contracts existing on different chains.

While building an off-chain component solves the interoperability problem up to a great extent, there are some trade-offs to be made.

Bridge Design Trade-Offs

Here are the list of trade-offs we’re currently facing when building blockchain bridges:

• Latency: The time taken for data to reach from one chain to another.

• Security: Security vulnerabilities during chain-to-chain data transfer.

• Complexity: How complex is the bridging solution? If a solution exists, how easy it is to build it for a new chain?

• Overhead: What are the costs required to validate messages or gas fees applicable for bridging a message?

• Reusability: How easy it is to integrate the existing solution with other chains?

The bottomline: Not all the aforementioned trade-offs can be solved at once; not for now at least. That being said, based on the application use case, one has to go with a suitable solution and the trade-offs to be made.

Types of Bridges

Trusted bridges

Trusted bridges rely on a central entity for their operation. In a trusted setup, users are expected to hand control over assets such as funds and data to the bridge operator and bank on their reputation. If the bridge is compromised, then the data and assets will be compromised. Cross-chain applications on these bridges are less secure but since they are easy to be implemented, they can be customized to improve the performance accordingly.

Trust-less bridges

Trustless bridges do not require a user to place authority in a single entity or authority. Trust is placed on smart contracts and cryptography. How can this be done? We have to somehow prove to the destination chain that the data that it received from the bridge is actually from the source chain and is added to a block and finalized (it’s part of a block that cannot be changed).

One way of dealing with this is through a light client. A light client is a software that allows users in low-capacity environments to maintain a high-security assurance about the current state of some particular part of the state or verify the execution of a transaction. This can either be done by the bridge itself or by the smart contract on the destination chain.

Cosmos IBC (Inter-Blockchain Communication) is one such light client-based solution. In IBC, relayers run light clients that track the consensus states of other blockchains and the proof specs of those blockchains. These proof specs are required to properly verify proofs against the client’s consensus state. The data along with the proof will be transferred to the destination chain by the relayers. Osmosis is a cross-chain decentralized exchange built for the Cosmos ecosystem using IBC. But the main disadvantage of using IBC is that it works only for the Tendermint consensus algorithm because of its fast finality. Because of its difficulty and complexity to build one for other chains like Ethereum, some serious work is being done in this area.

Trade-offs for Cosmos IBC are low latency, high security, high complexity, mid-high overhead, and high reusability (only in the Cosmos ecosystem).

Trust minimized bridges

Most of the existing bridge solutions currently come under this category. We will go through some of the solutions.

Celo Optics bridge uses off-chain components to maintain the network. Updater is responsible for signing attestations of new roots. This works as an optimistic approach where the malicious updater will be slashed, watchers can report malicious activity to the Home contract. More details here. Trade-offs for Optics are medium latency, medium security (one edge case where watchers miss the malicious activity), high reusability, low overhead, and low complexity.

Chainsafe Chainbridge currently works on a trusted federation model, where relayers vote on the proposal so that not a single relayer but a threshold number of relayers approve the transfer of the data. The advantage of Chainbridge is that it can be integrated easily. Trade-offs for Chainbridge are medium latency, low-medium security (Cross-chain applications built on Chainbridge should run their own relayers), high reusability, low overhead, and low complexity.

LayerZero uses UltraLightNode design to relay data from source to destination chain, This design uses oracles to relay generic information like block headers, and relayer to relay transaction proofs against the relayed information by the Oracle. This model assumes that the oracles and relayers will not collude. This is more efficient and more reusable for any application as it is a core generic message transfer. Application logic can be built on top of it. Block finality can be mentioned in the application logic itself. More details here. Trade-offs for LayerZero are optimizable latency (we can change the waiting time for blockchain finality), mid-high security (Oracles and relayer should not collude with each other), high reusability, less overhead, and low complexity.

Where does Arcana stand in this cross-chain world?

Among the many things we do at Arcana, we provide encrypted storage for dApps and also for NFTs. So, the application logic lies on popular blockchains like Ethereum or Polygon, and the storage layer will be Arcana. So, there has to be a way of communication between Arcana and other popular blockchains. We will be collating our learnings in another blog post due soon. Stay tuned.