Bridges: Designs & Risks

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.

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?

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.

Risks Associated with Bridges

Given the technical complexity involved in navigating cross-chain message passing, there are various risks involved when using bridges. Some of the main risks include:

Bridge Risks

To mitigate censorship risks and halting risks, users can simply limit their use of trusted bridges and optimistic bridges. However, security risks can never be completely avoided, so it is important to understand the possible attack vectors to assess which security systems are more robust than others.

The two main attack vectors that are used to undermine a bridge’s security are 1) smart contract exploits and 2) root of trust exploits.

Two Main Attack Vectors for Bridges

A smart contract exploit occurs when a malicious actor successfully attacks a bridge at its application layer. Because most bridges must deploy secure smart contracts on all the chains that they connect, newer blockchains are easier targets for attacks. Languages such as Rust, CosmWasm, and Substrate all have growing developer communities but they do not possess the same number of developer tools and auditing firms as mature languages like Solidity, so the likelihood of a bug slipping through to mainnet is higher. When one factors in the elements of speed and competition when developing a bridge, it is easy to understand why smart contract exploits are the most common attack vector for hackers.

As for root of trust exploits, these hacks require a malicious actor to successfully attack the underlying verification method used by a bridge. In the case of the Ronin hack, the malicious actor attacked the honest majority assumption by accessing 5 out of 9 of Sky Mavis’, the studio behind Axie Infinity, private keys. Once the hacker breached Sky Mavis’ centralized security system, the rest was history.

As one can see, the vulnerabilities are not easily seen from the outside in, but the costs associated with poor security systems can be enormous. Over the last year, the cumulative cost of bridge exploits has exceeded $1.5 billion dollars.

TVL Dilemma

To make matters worse, unaware web3 users could easily feel safer when using higher TVL/TVB bridges because it appears that these bridges are robust enough to handle large volumes of token transfers; however, there is not a clear correlation between TVL/TVB and security. In fact, one could argue that the security of the bridge is at a greater risk as the TVL/TVB increases given the larger economic incentive for a malicious actor to find a vulnerability.

Therefore, understanding the underlying security system of the bridge one uses should be considered when transferring funds. If a retail trader needs to send 0.5 ETH quickly to ensure a NFT mint, then security does not need to be the top priority. However, if a DAO plans on transferring 10,000 ETH to a contract on a different chain, then the underlying security of the bridge should be carefully examined.

Conclusion

Cashmere uses Layerzero with trustless design. In this way, users can make cross-chain swaps of their assets without any trust.You will be able to transfer between chains without using Bridge or CEX. Cashmere Labs solves one of the most important problems in the DeFi industry of the future. Users will be able to make all their transfers with the Cashmere Cross-chain swap without any trust.