Axelar Network, LayerZero and the future of interoperability
How to stop North Korea from attacking our blockchain bridges
Blockchain bridges have been in the news recently for the wrong reasons. It was recently revealed that March’s $540M hack of the Ronin Bridge was likely carried out by the Lazarus Group, a group of North Korea-sponsored hackers, who used a PDF containing a fake job offer to steal validator keys from an employee of Axie Infinity. This single point of compromise allowed them to obtain 4 of the 5 multi-sig keys, out of 9 total, needed to unlock funds from the bridge run by one of the world’s most popular play-to-earn games1.
This situation wasn’t by any means unique. The same group was also behind Harmony’s $100M bridge hack, another social engineering attack which compromised 2 out of 5 multi-sig keys2 3. Not to suggest that all bridge compromises are due to multi-sig failures or social engineering, March’s $325M Wormhole bridge hack occurred after a security fix was uploaded to Github pre-release, likely alerting a hacker who then exploited the vulnerability before the fix went live4.
Frictionless interoperability is the long-term vision
Interoperability refers to the ability for users and dapps to interact across blockchains. A few key capabilities include the ability to read the state of external blockchains, send messages across blockchain system boundaries and move assets between blockchains.
Consider a wallet “aggregator” app built on Ethereum which allows you to manage your Solana and Polkadot wallets, without additional logins. Today, this experience isn’t possible on blockchains, but for something like the Internet, we take this type of connectivity for granted. Despite being composed of distinct local networks, the Internet is connected together smoothly via routing protocols so that accessing a site hosted in France from the US doesn’t take any extra effort. Indeed, this is why it’s always referred to as the Internet (singular) instead of the Internets (plural) and there is no specific “US network” or “Canadian internet”. Though some connectivity exists today between chains, the degree of connectivity, as well as the safety of those connections can be improved.
Bridges let you move assets across chains
Say there are two chains, a source chain (Ethereum) and a destination chain (Solana). If a user has 10 ETH which they need to send to Solana, they can start by sending them to a deposit address on Ethereum specified by the bridge operator, while also specifying the address on Solana where they’d like to receive the output. Once the bridge operator, who is monitoring Ethereum transactions, observes that the transaction with 10 ETH has been finalized, they send a message to their smart contract on Solana to send “wrapped ETH” to the output address. With this, 10 ETH on Ethereum has been converted into 10 “wrapped ETH” on Solana. Note that “wrapped” assets are meant to represent the original asset (ETH), but on another chain (Solana) where the asset is not native.
Building bridges one by one is inefficient
Define a “bridge point” as a location on a given chain that serves as both an entrance and exit for assets moving between chains, with a “bridge” being any pair of “bridge points” which can communicate in order to move assets between them. Notably communication between bridge points isn’t a given, as it requires bridge points to be using a similar technical framework.
Take an example with 3 chains, Avalanche, Bitcoin, and Cosmos. Let’s say you want to be able to move assets from any chain to and from any other chain. If the bridges are all built by people who don’t coordinate their technical approaches, this requires 6 bridge points to be built by 3 people. In the section below, bridge points 1 & 2, 3 & 4, and 5 & 6 are built by John, Kevin, and Larry respectively.
Let’s assume John finishes building his bridge first (bridge points #1/#2). If Kevin doesn’t make his Cosmos bridge point (#4) compatible with John’s Avalanche bridge point (#2), then he will have to create a duplicate bridge point on Avalanche to connect to the Cosmos chain (#3). However, if Kevin does make their Cosmos bridge point compatible, then the duplicate Avalanche bridge point is avoided since assets can be sent directly between Avalanche and Cosmos using existing bridge points. Moreover, since the existing Bitcoin bridge point can now send assets to the newly compatible Cosmos bridge point, Larry’s (yet unbuilt) bridge points (#5/#6) become entirely unnecessary. In other words, if everyone coordinates, only 3 rather than 6 bridge points are needed to achieve interoperability between all blockchains.
More generally, if you build separate pairwise bridges for each pair of blockchains, you need N*(N - 1) bridge points, but if all bridge points use a standardized protocol and can inter-operate, then you only need N bridge points. For very large values of N, building bridges in an uncoordinated way quickly becomes impractical, while coordinating to build bridges remains efficient.
Admittedly the above example is overly simplistic. In real life rather than allowing one party to control all bridges, we would instead look for non-centralized means like open source and community-reviewed bridge smart contract templates or decentralized bridge networks to achieve technical coordination.
Adhoc bridge building also harms security
Beyond reducing the amount of redundant effort used to build bridges, having a standardized protocol for “bridging” also reduces security risks.
Since bridges need to lock up large amounts of capital as inventory to facilitate transfers, they make attractive targets for attackers. Smart contract risk arises from bugs in the smart contract code used to implement bridges leading to money being stolen. When frequently built adhoc by inexperienced project teams, bridges are more likely to have vulnerabilities, which are then less likely to be spotted since attention will be spread across a large number of adhoc implementations. In contrast a standardized bridging protocol would concentrate risk in a fewer, but more well-defended and battle tested smart contract implementations.
Despite the issues with bridges, people keep using them! From here we’ll review two exciting projects, Axelar Network and LayerZero, to see how they might help.
Axelar Network - a decentralized bridge network
Axelar Network describes itself as a “decentralized cross-chain read-write oracle” which can help users move assets more safely between a larger number of blockchains 5 6. Oracles let an individual blockchain interact with the external world, including separate blockchains, both by receiving information (“reading”) and sending updates to external locations (“writing”). Though Axelar supports both reading and writing, below we’ll focus primarily on the “bridging” subset of its “write” functionality.
Axelar Network runs its own independent blockchain, where validators are responsible for monitoring the state of external blockchains (e.g. Bitcoin, Ethereum, Polkadot). When enough validators agree for example on the latest blocks added to Ethereum, these updates are written to Axelar’s chain. With knowledge of external transactions, validators are also able to approve cross-chain transactions on Axelar’s network of “bridge accounts” across supported blockchains. Once they see initial deposit transactions finalized, validators use use “threshold signatures” to release assets from the bridge accounts.
A threshold signature schemes mean that all of Y participants start by receiving a distinct “fragment” of a private key, then if at least X of Y possible validators put their “fragments” together they can create a private key which can be used to sign and unlock a given transaction (e.g. unlock tokens) [6]. Since it’s always possible based on the final private key created to see which participants helped create a signature, this makes it easier to detect misbehavior. As threshold signatures are implemented more offchain compared to multi-sig, some have also argued that they lead to less complex and safer smart contracts 7 8.
Once X or more validators see that the the transaction on the source chain is finalized, they can unlock the transaction. Security is ensured by the system and incentives which Axelar Network puts in place for validators to behave properly, which are covered in more detail in their white paper linked in the footnotes.
Axelar Network solves a few major problems. Besides reducing the inefficiency of pairwise bridging by creating a standardized interoperable bridge network, it also reduces “multi-sig risk” by increasing the number of validators who can sign for assets to be released. Whereas Harmony and Ronin had relatively low multi-sig thresholds, Axelar Network can create a much larger pool of global validators and then draw from this pool to secure each bridge account. Another benefit is that since these validators can be somewhat pseudonymous and are no longer tied to emails, employees, computers, or physical offices associated with specific organizations like Axie, it will be harder to target these validators via social engineering.
LayerZero - a technical primitive for building safer bridges
In contrast to Axelar Network, which maintains both an entire blockchain storing external blockchain state and a set of bridge accounts, LayerZero is focused on building a single interoperability “primitive”. The company provides a trustless implementation of “valid delivery”, which states that given a chain A and chain B, we can monitor a transaction T on chain A and send a message M to a smart contract address on Chain B when T is finalized, but not otherwise. This is a primitive because the message M can be used to trigger a smart contract to do anything - it doesn’t necessarily need to be used to unlock assets on the receiving end of a bridge.
For the bridging use case, LayerZero also needs to determine in a secure way when a specific transaction has been finalized on the initial chain. Rather than outsourcing this job to multiple validators, LayerZero assigns this job to two independent entities, an “Oracle” and a “Relayer”. The Oracle retrieves block headers, including the root hash, from external blockchains and tracks when blocks are finalized. Relayers independently compute a Merkle proof which confirms that a transaction was included in a block. This entire setup is claimed to be trustless, since the “Oracle” role is played an external “oracle” service like ChainLink, which maintains its own network of decentralized oracles with its own security guarantees, and the relayer can be implemented by anyone (although LayerZero will provide an implementation to start) 9.
Security is based on the logic that assuming the Oracle and Relayer are independent, then the root of the Merkle proof and the state root of the block header matching guarantees the transaction is valid. Let’s say that the two roots match, since if they are inconsistent the results are thrown out. If they match, then there are then two possible cases, as the transaction is then either valid or invalid. If the transaction is valid, we are done. If the transaction is invalid, note that due to how collision-resistant hashing functions like SHA-256 work, statistically this cannot be an accident - the relayer and oracle must have coordinated as to what the matching root needed to be. Therefore, this violates our security assumption as the relayer and oracle are now colluding and aren’t independent. In short, if our assumptions are true then a match between Relayer and Oracle means the transaction is valid. Once the transaction is finalized, LayerZero sends a user-defined message to the user-provided address.
To get into an example of how this could work, let’s consider our bridge example again. If we want to send an asset from chain A to chain B, let’s start by sending some ETH to an address. The bridge smart contract on the sending side could be implemented so that on observing this transaction T enter this address, we submit to LayerZero the following: A) the transaction T, B) the address S of receiving side smart contract, and C) an optional payload P (e.g. the message “convert this to wETH and send to recipient_addr”). Once the transaction is finalized, thanks to the Oracle and Relayer, LayerZero will send a message M containing containing the payload to the receiving bridge smart contract, which can then send wEth to the recipient’s address.
Note that as LayerZero is a programmable primitive, not a pre-designed system like Axelar, you can add more functionality into the bridge - for example, you can let the initial ETH sender specify the output they want (e.g. BTC), instead of automatically giving them wETH. More generally, you can use this primitive for other non-bridge use cases. LayerZero highlights Stargate Finance as an example of a cross-chain DEX using the primitive. While today’s cross-chain DEXes like Thorchain or AnySwap all involve an intermediate chain and token, the LayerZero approach allows you to create a cross-chain DEX using just smart contracts on each chain. Rather than handling inter-chain communication via an intermediate chain and security by requiring separate stakes, you can just send the message directly with transaction finality guaranteed by LayerZero’s Relayer and Chainlink’s Oracle.
While primitives are awesome, LayerZero unfortunately doesn’t directly increase interchain connectivity or reduce the risks from adhoc bridge smart contract code. However, it does make designing secure bridges easier. If implemented into bridge smart contracts it reduces the need to find an independent set of validators like Wormhole Guardians to monitor transactions coming into the bridge. Though suitable oracles like Chainlink are probably easy to find, the bridge implementer will still need to choose a good relayer. More details could probably be provided about how to create a decentralized network of relayers, but this type of setup is an otherwise novel approach to interoperability.
Conclusion
LayerZero and Axelar Network take fairly different approaches to interoperability - while Axelar Network includes a network of interoperable bridges, LayerZero is a technical primitive which makes building bridge smart contracts easier.
Axelar Network improves efficiency compared to pairwise bridges, while also reducing smart contract code risk by providing a more standardized contract which can be used to add blockchain bridging support. Both Axelar and LayerZero reduce multi-sig validator risk, albeit in different ways, with Axelar Network creating a larger professional pool of validators who are more difficult to attack, while LayerZero replaces validators effectively with Oracles and Relayers. Although we’ve been mostly analyzing bridges, it is worth keeping in mind that LayerZero is likely to have a lot of value even outside this use case, since it’s primitive can be combined with non-bridge smart contracts to build cool new things.
Overall, the very value of interoperability depends on if usage will consolidate towards fewer, larger chains, or if it will trend towards a larger number of use-case or even application-specific L1s. Commenters are still divided on if inter-chain asset movements will remain popular, even if the world is likely to be multi-chain10. While bridges may forever be prime targets for hackers, it’s great to see newer ideas about how to address the hacks we’ve been seeing.
Disclaimer
I’m not a paid shill for Axelar Network or LayerZero (besides neither currently have a token), I’m writing about these mostly because they are two of the more interesting examples of interoperability tech I’ve found recently. There may certainly be other interesting projects I’ve missed (like nomad.xyz, which relies on Optimistic proofs of transaction finality), but hopefully these can be covered in future work.
A very good article that has benefited a lot！
Nice writeup. was also spending some time digging into these two and coincidentally came across this. DM if active on Twitter, would love to chat: https://twitter.com/unisock_uniform