Jump Crypto: Analyzing the Pros and Cons of Cross-Chain Bridges like LayerZero and Wormhole

Original Title: ++Security Stack-Up: How Bridges Compare++

Original Authors: Jonathan Claudius, Anirudh Suresh, Eric Wong, Akshath Sivaprasad

Compiled by: 0x9F, 0x214, BlockBeats

In both the physical and crypto worlds, bridges are built to connect two places separated by obstacles. Physical bridges connect lands divided by natural barriers such as valleys and rivers, while cross-chain bridge protocols connect blockchains that otherwise cannot communicate or synchronize. The importance of bridges is highlighted whenever they suffer destruction or attack. In the physical world, historically documented ++catastrophic bridge collapses++ demonstrate how crucial they are and how dangerous poorly designed or constructed bridges can be.

The same applies to cross-chain bridge protocols in the crypto world. Cross-chain bridges are particularly vulnerable to security risks. From the perspective of potential vulnerabilities in smart contracts and the scale of attacks, cross-chain bridges present a quadratic risk surface: as the number of bridged blockchains increases, the number of smart contracts required to maintain the operation of the cross-chain bridge also grows quadratically (at least in a peer-to-peer model). The rapid increase in the number of smart contracts written for different runtime configurations also quickly escalates the risks associated with cross-chain bridges. In a hub-and-spoke model, a vulnerability related to the central chain/network can lead to asymmetric risks.

As demonstrated by the recent ++Nomad attack++, a single mistake can lead to the loss of most or all funds in a bridge. However, the vulnerability may not be related to the cross-chain bridge itself and could simply stem from an operational oversight. In the case of the Ronin cross-chain bridge, ++poor operational security measures++ allowed phishing attacks to take place, and ++hackers gained control of most of the validating nodes securing the network++, enabling them to abscond with over $500 million in value. Similarly, the Wormhole attack in February was due to a lack of validation checks, allowing attackers to create a fake signature and ++steal over $320 million++.

If security is not prioritized, more oversights will inevitably occur, leading to attacks and losses. For hackers, the massive TVL of cross-chain bridges is more attractive than that of ordinary protocols.

The aforementioned attacks are unrelated to the bridging logic of the protocols but rather to vulnerabilities in smart contracts and operational negligence. Even with the most meticulously written code and the best security audits, as the number of connected blockchains and enabled features increases, there will inevitably be overlooked vulnerabilities. For this reason, cross-chain bridges need to be configured to operate securely not only under normal conditions but, more importantly, to handle extreme situations.

When using cross-chain bridges, users primarily focus on the following features: good user experience, low slippage and high efficiency, and asset security. Among these, security is the top priority when evaluating cross-chain bridges.

With this in mind, let’s examine how different bridges stack up their security. We will discuss and compare the security of different cross-chain bridges from the following three levels:

1. Trust assumptions
2. Code assurance
3. Security features

The first two will discuss whether cross-chain bridges adequately consider the sources of their vulnerabilities at the trust layer and source code level. The last point involves whether a protocol acknowledges that, regardless of how carefully it is coded and audited, vulnerabilities are inevitable, and whether it has established additional safeguards to minimize potential losses for users.

To maintain complete transparency, before delving into the discussion, we acknowledge that Jump Crypto is indeed the operational steward of the Wormhole project and one of its core contributors, but we will strive to assess this article as objectively as possible. We welcome and accept any feedback on how to improve this article to showcase the differences between cross-chain bridges in detail.

Trust Assumptions

At its core, a cross-chain bridge can be broken down into three components:

1. Smart contract: Issues/receives information from each blockchain
2. Oracle: Validates whether the information comes from the original chain
3. Relayer: Submits messages to the target chain

In practice, there may be significant differences in how cross-chain bridges achieve consensus on oracles (regarding whether the information is valid), which further affects relayers.

Before we dive deeper, here’s a quick introduction to the consensus mechanisms used by some of the most popular bridge operators in the field.

Axelar

Axelar operates on the Cosmos PoS network, where validators are elected by token holders and receive voting power proportionally, with voting weight calculated based on delegated stakes. The Axelar network verifies cross-chain information through a (t,n) threshold signature scheme, where the voting power of signers is normalized to n, which must be greater than t, the protocol threshold, to sign a message. The Axelar network currently has a maximum of 50 validators, and a majority vote of over 66.67% is required to sign a message (both variables can be modified through governance voting).

Theoretically, the number of validators can be infinitely large, but in practice, since validators do not need to run nodes for each blockchain, voting power can become skewed. In Axelar's current ++validator list++, there are 47 validators, but only 20 have actual voting power. For a specific blockchain, this number is even smaller. For instance, if we only consider validating information on Aurora, only 8 nodes are needed to successfully send a message, and just 4 nodes are required to review that message.

LayerZero

LayerZero is a cross-chain interoperability protocol that simplifies the trustless communication problem between blockchains into an independence issue between oracles and relayers. The oracle forwards the block header to the target chain, while the relayer forwards the transaction proof to the target chain, with both proving that the message is valid and that the information was indeed submitted to the original chain. User applications (UAs) can freely use LayerZero's default oracle and relayer or create and run their own.

The default oracle is a Chainlink decentralized oracle network (DON), which uses a threshold signature scheme among three participants (FTX, Polygon, and Sequoia). At the time of writing, due to the closed-source nature of the LayerZero codebase, the author lacks insight into its execution. Regarding specific application versions of the oracle, LayerZero's own Ackee audit points out that it is not difficult for applications that create and run their own oracles and relayers to successfully submit an invalid transaction proof and block header. However, this modularity does provide benefits, as any future vulnerabilities will only affect those applications using the affected oracle-relayer pairs.

LayerZero's trust assumptions depend on the behavior of the two entities—so long as the oracle and relayer operate independently of each other, it is impossible to successfully send an invalid message. Conversely, because this system requires both the oracle and relayer to operate normally to validate information, either party can arbitrarily delete information data.

Multichain

Multichain is a cross-chain information transmission protocol that originated from the previous Anyswap. Multichain uses secure multi-party computation (SMPC) to run a threshold signature scheme, creating public keys and signing messages transmitted between chains. These nodes control user accounts (EOA) in a trustless manner, with wallet addresses corresponding one-to-one with split private keys. These accounts are used to store assets and transfer assets to the target chain, which only needs to check whether the sender's address is trustworthy, without needing to validate the message itself.

The Multichain network currently consists of 24 SMPC nodes operated by different entities, requiring a majority of nodes (the quantification standard for "majority" does not seem to be publicly available) to jointly validate messages. Therefore, the security of the protocol relies on the reputation security of the SMPC nodes, assuming that honest nodes constitute more than half of all nodes. Cross-chain data transmission requires 13 signers, while message review requires 12 nodes.

Nomad

Nomad is an EVM-focused cross-chain information transmission protocol that employs an optimistic mechanism to validate messages, where messages are added to a Merkle tree and hashed into a new root, published to the original chain by an updater. The updater must post a bond to incentivize them to publish valid proofs and minimize downtime. Observers then have time to dispute the new root and submit fraud proofs. Once the time window exceeds, this Merkle root is considered valid and forwarded to the target chain for publication, allowing the original message (since the Merkle root is merely a "representative" of the message) to be published on the target chain.

This optimistic model only requires one honest observer to verify whether an invalid update has been published. The cost of this security model is that observers have about 30 minutes to submit fraud proofs, which delays the transmission of messages by 30 minutes. Since observers can prevent messages from being processed by sending false fraud proofs to the target contract, Nomad employs a set of application-specified, permissioned observers. The security of the protocol is based on the likelihood of at least one honest observer being present, as well as the economic security of the updater being diminished due to malicious actions.

Nomad smart contracts can be upgraded through ++multi-sign governance mode++, requiring 3 out of 5 signers to execute governance changes and handle recovery management.

It should be noted that the recent Nomad hacking incident was unrelated to the security of its consensus mechanism; it was an unfortunate ++contract configuration error++ that led to malicious behavior at the smart contract terminal.

Wormhole

Wormhole utilizes a proof of authority (PoA) guardian network as an oracle and employs a permissionless relayer network to transmit messages across chains. Each of the 19 guardians runs a full node for each chain supported by Wormhole and listens for messages emitted by the Wormhole core contract on each chain. These guardians validate and sign these messages, then relay them to each other over a P2P network. Once a message receives signatures from more than 2/3 of the guardians (at least 13), it is forwarded to the target chain. A byproduct of this design is that it allows a completely trustless relayer network to publish messages to the target chain, as the information is signed by the guardians, making it impossible for the message content to be altered or censored, since anyone can run a relayer to submit any information.

The security of the protocol is derived from the reputation authority of the guardians. In the case of Wormhole, this is a group composed of ++19 of the largest staking and infrastructure providers in Web3++. Signing false messages requires 13 guardians, while reviewing messages requires 7 guardians. Additionally, existing guardians have the ability to vote to remove or replace other guardians.

Code Assurance

Code assurance refers to the work that needs to be completed before deploying code on-chain. This may involve several aspects:

1. Audits: Multiple, independent quality audits of publicly available core functionalities and new features
2. Bounties: Providing attractive rewards for vulnerability disclosers, as well as a strong industry reputation for promptly paying out large bounties
3. Testing: Testing as many protocol stacks as possible on each code change to conduct regression testing in an ever-growing software ecosystem
4. Deployment security: Reviewing, validating contract bytecode, and conducting simulation tests before merging code in a public environment

The table below summarizes the performance of five cross-chain bridge protocols in these four areas.

Axelar

Axelar has undergone multiple public and reputable audits and operates a fairly robust (though less active in recent months) testing suite: continuous integration (CI) and continuous delivery (CD) runs, bash build scripts, and checksum verification. Axelar has partnered with Immunefi to establish a bug bounty program, offering rewards of up to $1 million for serious vulnerabilities, but the bounty amounts for other levels are relatively smaller. The Axelar repo has contributors who regularly submit code, and pull requests require approval from at least one reviewer.

LayerZero

LayerZero appears somewhat opaque in terms of code deployment. While there have been several public audits from top auditors, there is a lack of publicly available continuous integration (CI) and continuous delivery (CD) processes. The code seems to be released as a one-time public release rather than an agile development process. The testing conducted appears relatively outdated and is limited to JavaScript tests. Pull requests seem to lack a mandatory peer review step. LayerZero did announce a $15 million bug bounty program in partnership with Immunefi in April. However, no related projects have been publicly released so far, nor are there any instructions on how to submit vulnerabilities for bounties.

Multichain

Multichain has undergone multiple public audits and has a bug bounty program with Immunefi of up to $2 million. The testing conducted by Multichain appears stagnant and seems limited to general ABI and simple transfer tests. While there are continuous integration (CI) and continuous delivery (CD) runs and limited unit and integration tests, the deployment process appears to be primarily manual. The Multichain repo has contributors who regularly submit code, but it seems that only one party is required to merge code (the original developers can merge their own code).

Nomad

Nomad recently underwent a public audit by Quantstamp and has a bug bounty program with Immunefi, offering rewards of up to $1 million. Nomad's testing suite includes tests around routing and messaging using Foundry, and like Axelar, it has bash build scripts to build and verify bytecode. Nomad's repo has contributors who regularly submit code, and its pull requests require at least two parties to merge code (the original developer plus one independent reviewer).

Wormhole

Wormhole's security page highlights the audits they have completed and are undergoing from leading auditing firms in the industry. Wormhole has a $10 million bug bounty program on Immunefi. Since being hacked in February, Wormhole has paid out over $11 million in bug bounties, including a $10 million payment to a white hat hacker in May. Wormhole's repo employs a mix of unit and integration testing, has a scalable continuous integration (CI) and continuous delivery (CD) suite, and runs a series of simulation tests to verify backward compatibility and future upgradeability. Additionally, Wormhole achieves transparent code review and responsible disclosure through active submissions and contributions. Wormhole's pull requests require at least three parties to merge code (the original developer plus two independent reviewers).

It is worth noting that the methods of code assurance for protocols can significantly improve after experiencing serious security incidents. For example, after being hacked, Wormhole's code assurance methods were rapidly enhanced. Similarly, following this week's attack, the Nomad protocol is likely to adopt more code assurance practices in the near future. Clearly, it is best to adopt these practices before incidents occur, but unfortunately, they are not always prioritized.

Security Features

As mentioned above, when security issues arise with cross-chain bridges, the costs can be extremely high. The code assurance measures outlined above are crucial to the security plans of cross-chain bridge providers. In this section, we will closely examine the security features being developed or deployed within each cross-chain bridge protocol to understand how these bridges achieve multi-layered defenses in the face of fundamental inadequacies in core trust assumptions and code assurance.

Axelar

In its white paper, Axelar describes a network-distributed fund pool as a governance-controlled safeguard and backup mechanism to provide recovery governance guidance for users in the event of an Axelar disruption. In such a crisis, the "emergency unlock keys" stored by the threshold contract (managed by Axelar validators) will be shared with a secondary recovery user set. If needed, this queue could expand to thousands of individuals and institutions who could collectively control the network to:

• Set rate limits on the amount of funds that can be transferred in/out of a specific chain
• Determine the wrapping format of on-chain native assets

These features appear to be proprietary and have not yet been open-sourced. Additionally, these proposed features do not provide passive security to limit risks but are activated in critical situations.

LayerZero

LayerZero's bridging model includes a requirement for transaction applications to select relayers on the target chain. Therefore, in this model, the key aspect of protocol-level security features lies with the relayers.

In April, the LayerZero team introduced their approach to protocol-level security features, referred to as "the dome" and "pre-crime." There is little public information about the dome feature, but the blog post provides clues about how pre-crime operates. The pre-crime model essentially allows user applications (UAs) to define a specific set of states that relayers must validate. If these states are not validated, the relayer will not relay the transaction.

Note that these features appear to be proprietary and have not yet been open-sourced. While conceptually powerful, it is difficult to independently assess their effectiveness.

Multichain

In a recent article, Multichain disclosed some of their security measures, including mentioning some security features of their bridging configuration:

1. Transaction volume limits and total transaction limits: This feature allows high-volume blockchains to be capped at a specific limit. Additionally, for lower-volume blockchains, a total transaction limit is applied.
2. On-chain monitoring: This model involves monitoring software and on-chain watchdogs to detect abnormal behavior and trigger incident response actions.
3. Product pause: This feature allows pausing all products and effectively halting all products during the implementation of incident response actions.
4. Security fund: This is essentially a guarantee fund that allocates 10% of all cross-chain fees to compensate users for property losses in special circumstances.

Nomad

Nomad utilizes an optimistic verification model, where messages are signed on the original chain and have a built-in time window that enforces execution on the target chain. To some extent, we can observe this as similar to "not opening this letter before this time." This time window is useful for implementing an "automatic circuit breaker" and halting asset transfers before the Merkle root is deemed valid. This concept has appeared in Nomad's documentation, and development seems to be ongoing.

Wormhole's messaging model is multicast, meaning messages are notarized by the guardian/oracle network from the original chain, and the relayer that brings the message to the target chain is untrusted. This model fundamentally requires a very robust oracle network, and protocol-level security features rely on this.

The Wormhole project has three main protocol-level security features currently under development: oversight, accounting, and emergency shutdown. These features are being developed in a publicly visible manner, allowing us to gain insights into how they will ultimately operate. These features are awaiting completion and adoption by the guardians.

1. Oversight: This feature is implemented within the guardians/oracles, allowing guardians to monitor the nominal amounts of value flows from any regulated chain within a time window. Guardians can set an acceptable limit for each chain, and once this limit is reached, it will prevent asset flows exceeding that limit from that chain.
2. Accounting: This feature is implemented within the guardians/oracles, allowing guardians to maintain their own blockchain (also known as "wormchain"), which can serve as a cross-chain ledger between different chains. This ledger not only allows guardians to act as validators on-chain but also serves as an accounting plugin. Guardians can reject cross-chain transactions if the original chain does not have sufficient funds (verification independent of smart contract logic).
3. Shutdown: This feature is implemented on-chain, allowing guardians to reach consensus to temporarily halt asset flows across the cross-chain bridge upon realizing a threat to the cross-chain bridge. The current implementation allows this to be achieved through on-chain function calls in the proposed implementation plan.

Conclusion

In the coming months or years, we believe that security will become the differentiating factor among cross-chain bridges. Those cross-chain bridges that prioritize security are more likely to weather crises, while those that do not are likely to struggle. Security may have once been merely a source of competitive advantage; however, it must now become the foremost feature that every cross-chain bridge prioritizes. We hope all cross-chain bridges unite to collectively enhance the security technology of cross-chain bridges.