The industry that originated with the Bitcoin whitepaper published by Satoshi Nakamoto and the birth of the first Blockchain has evolved into a wide-ranging assembly of various teams, blockchains, and technologies. There is a prevalent argument suggesting that most activity will eventually consolidate into a handful of networks – essentially mirroring the development of computer and mobile operating systems. However, there are numerous reasons to believe that we might instead progress towards a multichain future, one that demands interoperability across chains. As blockchains become more nuanced, it's plausible that we'll see ecosystems more suited for specific functions, such as NFTs, gaming, DeFi, and so on. Moreover, even if activity were to focus predominantly on a single ecosystem like Ethereum, the necessity for seamless interoperability and bridging across its varied scaling solutions will persist.
Interoperability principally refers to a blockchain's ability to freely exchange data, assets, and information with other blockchains. An early example of successful interoperability was the emergence of Bitcoin units on other blockchains in wrapped forms, such as wBTC (widespread adoption but centralized) or RenBTC (more decentralized implementation). This facilitated the usage of Bitcoin on different (smart contract) blockchains – for instance, to be used as collateral in DeFi on Ethereum.
Approaches to Cross-Chain Interoperability
Different approaches are being explored for the implementation of cross-chain functionalities. Broadly speaking, when considering more decentralized methods, many implementations take their ideas from two concepts: middle chains and on-chain light nodes.
- Middle Chain: As the name implies, a middle chain is a blockchain that operates between two or more other blockchains. This means that this middle chain has its own set of validators and is built to read and interact with the connected chains. The middle chain's validators usually have full signing power over all messages. Therefore, if there's corruption, all connected liquidity is at risk. This situation can be problematic because, in many current implementations, such chains are secured by only a fraction of the value they protect, making them attractive targets for malicious actors.
- On-Chain Light Node: Contrary to middle chains, on-chain light nodes validate the transactions directly on the source and destination chains. Therefore, they gain the security guarantees from these chains instead of relying on their own set of validators. These nodes store the block headers of each block on-chain and can verify the validity of provided transactions themselves. Therefore, transaction data can't be tampered with during the transfer. In theory, this is a highly secure method to implement; however, relying on the source and destination chains' consensus can be costly, and thus, this is not feasible at scale.
An example of a protocol that utilizes a sort of middle ground approach is LayerZero, which will now be examined in more detail.
LayerZero is an interoperability protocol that relies on on-chain ultra-light nodes. This method preserves the main security guarantees similar to those of light nodes while outsourcing the storage of (unverified) block data to off-chain providers. Instead of storing all block headers on-chain, these ultra-light nodes depend on an external service (oracle) to stream such block data on-demand, while the subsequent verification remains on-chain.
LayerZero's implementation is remarkably lightweight while at the same time allowing for more complex and integrated transaction types than other bridges. This won't be covered to avoid getting too technical – however, additional resources are linked below. The protocol's design consists of three main parts: LayerZero Endpoints (i.e., ultra-light nodes on each connected chain), oracles, and relayers. Figure 1 provides a schematic overview of a transaction using the LayerZero protocol.
- LayerZero Endpoints: These are the ultra-light nodes that are deployed on each chain where the protocol is implemented. They consist of a set of smart contracts, including communicator, validator, network, and libraries modules. The first three modules are required to ensure the correct delivery and verification of messages, while the libraries module is used to be able to expand the network and incorporate new blockchains in the future.
- Relayer: The relayer is a service provider that retrieves proof of a specified transaction on the source chain (e.g., proof that a user has locked certain assets in the endpoint on chain A) and transmits it to the endpoint on the destination chain for verification. There are no restrictions on who can offer relayer services, and developers are free to choose any provider or run the service themselves.
- Oracle: The oracle transmits block headers from one chain to another on an on-demand basis. These headers are required on the destination chain's endpoint to verify the respective transaction details provided by the relayer. The oracle service, in a sense, is the "outsourced" part when comparing light nodes and ultra-light nodes. At present, LayerZero supports both Chainlink and Band Protocol as oracle services, and the choice between those oracles is left up to the respective application's developers as well.
Figure 1: LayerZero communication flow. Source: LayerZero Whitepaper.
Within LayerZero's implementation, the most significant security assumption lies in the independence of the relayer and oracle services. Should these two collude, they could alter the forwarded messages, and all assets utilizing the respective combination of relayer and oracle would be at risk. However, in such a scenario, the rest of the network (i.e., all other combinations of relayer and oracle services) would continue to function normally.
The beauty of LayerZero lies in its comparatively simplistic implementation, which leads to scalability, easy implementation for developers in their applications, and the potential to build true cross-chain applications using LayerZero's cross-chain communication standards.
Competing and Similar Projects
Several projects are working on cross-chain interoperability, each with different approaches and use cases. Some focus on bridging assets, while others aim to create a comprehensive foundational layer for cross-chain interactions. Some well-known projects in this space include:
- Wormhole: Wormhole is a cross-chain bridge that relies on a consortium of "guardians" to verify transactions and lock the respective native tokens in a smart contract on the source chain. Subsequently, wrapped assets are minted on the target chain. It is a widely used bridge, offering a broad range of connectivity and assets, including NFTs. Furthermore, it allows for the development of applications directly atop Wormhole, thereby tapping into various blockchains and liquidity sources. On the downside, Wormhole has faced security issues, notably a $320m hack in 2022, one of the biggest DeFi hacks in history. Additionally, the Ronin bridge, which was hacked for $622m, is based on a similar protocol design, although the attack vector used for this hack was different.
- Cosmos: Cosmos goes beyond being a "simple" cross-chain bridge – the project aspires to build the "internet of blockchains", an ecosystem comprised of compatible blockchains. These chains can be tailored to their respective use cases while employing a similar, fast-finality consensus mechanism and integrating the Inter-Blockchain Protocol (IBC) for interoperability. The main chain, which uses the ATOM token, acts as the gateway and hub within the ecosystem.
- Polkadot: Similar to Cosmos, Polkadot also acts as a connection layer to provide interoperability within its ecosystem of blockchains. In its implementation, Polkadot serves as the relay chain to which independent, application-specific chains can connect for shared security and communication with other chains through the relay chain.
Risks and Potential Attack Vectors
Cross-chain interoperability and bridging are still in the nascent stages and carry substantial risks. Often, the respective protocols are not as decentralized as they appear – for example, Wormhole relies on a setup of only 12 guardians. In the case of LayerZero, a significant advantage is that the application can select respective sets of relayers and oracles, and in case of an attack, only the respective combinations are affected. However, the number of parties needed to collude is small, a fact that especially needs to be considered when using its standard configuration of relayer and oracle. In this standard setup, the team and its investors wield a lot of influence. The overall security issues are amplified by the fact that bridges can attract large amounts of liquidity, which can quickly exceed the value securing the network. Such pots of liquidity, coupled with complex implementations, can make them attractive targets for hackers.
Conclusion and Outlook
Looking ahead, interoperability is a key development in the continued adoption of blockchain technology – be it for the seamless usage of Ethereum scaling solutions or for the connection of various application-specific blockchains. Simple and secure bridging and interoperability capabilities are vital for the continued adoption of Layer 2, onboarding of new users, and the emergence of multi-chain applications with shared liquidity. However, it needs to be acknowledged that there is still further development and trust-building needed on the journey towards a fully realized, battle-tested, and decentralized solution.
With most blockchains currently operating largely in isolation, interoperability stands as a critical hurdle on the path to a truly interconnected blockchain universe. As the landscape expands, the ability for these individual chains to communicate and transact effectively becomes increasingly important. It will be interesting to see the ongoing innovations in this space and how the multi-chain future will be connected.