As more and more blockchains are developed with different designs, programming languages, and consensus mechanisms, blockchain interoperability has become an integral part of the ecosystem. Without interoperability, value exchange between different blockchains will become complicated and asset liquidity will be fragmented. Interoperability is essential to realizing the full potential of blockchain technology because it allows data and assets to move seamlessly between different blockchains, increasing interconnectivity and improving asset liquidity.
Cross-chain interoperability refers to the ability of different blockchains to communicate and exchange value with each other. It involves building cross-chain bridges between other blockchains to allow assets and data to move seamlessly between them. These cross-chain bridges serve as rule-based protocols that are the basis for scaling solutions and use messaging infrastructure to ensure secure communication between different blockchains.
There are several ways to achieve blockchain interoperability:
Interoperability protocols. These protocols are designed to facilitate communication and value transfer between different blockchains. For example, Polkadot, Cosmos, and Aion.
Sidechains. These are independent blockchains connected to the main blockchain, making it possible to conduct transactions on independent chains with the same assets. For example, RSK is a sidechain for Bitcoin, and Plasma is a sidechain for Ethereum.
Atomic swaps. This makes it possible to exchange one cryptocurrency for another without an intermediary, thus enabling cross-chain transactions. For example, the Lightning Network is used for atomic swaps on Bitcoin.
Cross-chain bridges. These cross-chain bridges are built between different blockchains, allowing assets and data to be transferred between them. For example, Wormhole was chosen by Uniswap for cross-chain governance messaging between Ethereum and Binance Smart Chain.
Cross-chain bridge
In the context of blockchain technology, a cross-chain bridge is an application built on top of a messaging protocol that facilitates interoperability between different blockchains. It is an interface that connects two or more blockchain networks, allowing assets and data to be transferred between them. As we gradually move into a multi-chain world, cross-chain bridges have become an indispensable infrastructure for cross-chain interactions. Arjun Bhuptani, founder of Connext, divides all cross-chain bridges into three basic types based on the validator: native verification, external verification, and local verification.
Natively Verified
Native verification means that all validators of the underlying chains fully verify the data transmitted between chains. The usual practice is to deploy the light node of the source chain in the target chain virtual machine to verify the information of the source chain.
Figure 1: Natively Verified
A light node is a small node that only stores block header information. A light node does not store all transactions on the chain, but can verify whether a transaction exists on the chain through block header information. A light node contract is a smart contract that contains a light node and is used to verify the information of the source chain. By deploying the light node contract of the source chain on the target chain, the authenticity of the source chain information can be verified.
When source chain A requests to transfer a cross-chain transaction information to target chain B, the transaction initiator submits the transaction details, block height, and SPV proof of the transaction to chain B;
The A-chain light node contract deployed on the B-chain recalculates the block header hash value of the block where the transaction is located through SPV proof;
The obtained hash value is compared with the corresponding block header hash value in the light node. If they are consistent, it means that the transaction did occur in the block. If they are inconsistent, it means that the transaction does not exist in the block.
Although anyone can submit transaction details and their SPV proof to the target chain, in actual cross-chain applications, there is often a dedicated role to do this, namely the Relayer. The Relayer transmits the block header of the source chain to the target chain, establishes a light node, and then when the Relayer moves the transaction information from the source chain to the target chain, it uses the block header information on the light node to verify the correctness of the transaction information.
Native verification requires at least one honest relayer, or users must transmit transactions themselves. Native verification is the most trust-minimized cross-chain communication method, but it is also costly, has low development flexibility, and is more suitable for blockchains with high state machine similarity, such as between Ethereum and L2 networks, or between blockchains developed based on Cosmos SDK. For example, Cosmos IBC and Near RainbowBridge, the entrance and exit of Rollup are also in this special form. In addition, interoperability protocols based on zero-knowledge proofs (ZK) also use light clients and relays to verify cross-chain transfers.
Externally Verified
External verification refers to the use of an external set of validators to pass data between chains. The usual practice is to introduce a set of external validators to be responsible for verifying cross-chain information. Users must trust that these validators are trustworthy, and there may be some mechanism within the validators to reach consensus.
Figure 2: Externally Verified
There are many different ways to implement external validators, such as multi-party computing systems, oracle networks, and threshold multi-signature contracts, but these solutions all require the verification nodes to perform trust-minimized off-chain calculations and verify them on-chain.
We need to be aware that when introducing external validators, new security assumptions are introduced. External validation usually assumes that more than half of the nodes are honest in order to maintain the reliability of cross-chain interactions. However, to improve the level of trust minimization, other technologies need to be adopted, such as cryptoeconomic staking, anti-fraud networks, and optimistic bridge validation. Interoperability protocols that use external validation include: Thorchain, Multichain, PolyNetwork, etc.
Locally Verified
Local verification is when only the parties involved in a cross-chain interaction verify that interaction. Local verification protocols transform the complex n-party verification problem into a set of simpler 2-party interactions, where each party only verifies its peer. This model works as long as the two parties are economically adversarial, i.e., there is no way for the two parties to collude to obtain data from the broader chain.
Figure 3: Locally Verified
In a locally validated system, cross-chain exchanges are performed using the validator set of the underlying blockchain. Instead of the entire validator set on both chains validating a transaction, two validators (one representing each chain) will validate the counterparty on the other chain. These two validators act as "routers" in the liquidity network:
Holding liquidity pools on each chain;
Mutual verification (counterparties);
Facilitates atomic swaps.
Such systems typically use a lock/unlock mechanism and dispute resolution process to ensure the security of user data and effectively eliminate the possibility of collusion between validators on each chain to steal data. Local verification systems are effectively trustless, such as Connext, Hop, and other simple atomic swap systems.
The Impossible Triangle of Interoperability
In his article, Arjun Bhuptani proposed the famous Interoperability Trilemma, which states that any cross-chain solution can only satisfy two of the following three conditions:
● Trustless: Has the same security as the underlying blockchain and does not introduce new trust assumptions.
● Extensible: Can be deployed on many heterogeneous chains with minimal customization.
● Generalizability: Supports cross-chain general information transmission.
Figure 4: Interoperability Impossible Triangle
Similar to the blockchain scalability trilemma, all interoperability protocols can only have two of the above three properties:
Figure 5: Properties of three types of cross-chain bridges
We summarize the advantages and disadvantages of the three types of cross-chain bridges in the form of a table:
Figure 6: Advantages and disadvantages of three types of cross-chain bridges
By comparing the three cross-chain bridges, it is found that native verification has the advantages of no trust assumption and support for cross-chain general information transmission. In theory, as long as the source chain and the target chain do not reorganize, cross-chain information transmission is safe, but its scalability is poor.
External validation is highly scalable and fully supports cross-chain universal information transmission. They also generally perform well in terms of speed and cost-effectiveness. However, these come at the expense of security, as new trust assumptions are introduced and their security must rely on a third party. To improve the level of trust minimization, other technologies such as cryptoeconomic staking, anti-fraud networks, and optimistic bridge validation are also needed, which increases the cost of cross-chain.
Although local verification has the dual advantages of no trust assumption and strong scalability, it cannot support cross-chain general information transmission, so its scope of application is relatively narrow.
Security Challenges of Cross-Chain Bridges
As decentralized finance (DeFi) continues to grow in popularity and the Ethereum Layer-2 ecosystem becomes more popular, cross-chain bridge hacks are becoming more frequent. These cross-chain bridges connect different blockchains and Layer-2 solutions, each with different technologies, and connect many blockchains at the same time, exposing more attack vectors. In addition, as DeFi continues to grow in popularity, cross-chain bridges are transferring larger amounts of value, making them more attractive.
There are three pillars of cross-chain bridge security: economic security, implementation security, and environmental security.
Economic security depends on the cost of gaining control of a majority of validators, and the most common way to compromise economic security is to steal a validator's private key. Locally validated cross-chain bridges provide the best economic security, while externally validated cross-chain bridges provide the least security.
Implementation security involves the complexity of the system and the risk vectors that can compromise the security of the cross-chain bridge. Smart contract vulnerabilities and compromise of RPC endpoints are the most common ways to compromise the security of the implementation. In order to minimize the risk of security vulnerabilities, cross-chain bridges need to be audited by multiple third parties.
Environmental security involves the integrity of the cross-chain bridge operating environment, such as the security of the nodes where the cross-chain bridge runs. The cross-chain bridge requires a bug bounty program to minimize the risk of security vulnerabilities. The security of the cross-chain bridge nodes is critical to environmental security. Multiple third-party audits are also necessary for environmental security.
The future of cross-chain bridge security and cross-chain interoperability is yet to be determined. In order to overcome these challenges and achieve more efficient and secure interoperability, it is necessary to develop more flexible and efficient cross-chain bridges and continuously optimize their security mechanisms to ensure that data transmission is both secure and trustworthy.
