Jump Crypto: Detailed analysis of the security of LayerZero, Wormhole and other cross-chain bridges
Original title: "Security Stack-Up: How Bridges Compare"
Introduction
Original compilation: 0x9F, 0x214, BlockBeats
Introduction
In both the physical and encrypted worlds, bridges are meant to connect two places separated by a barrier. Physical bridges connect land separated by natural barriers such as valleys and rivers, while cross-chain bridge protocols connect blockchains that have no way to communicate and synchronize. Every time bridges are destroyed and attacked, their importance is demonstrated. In the physical world,Historically documented catastrophic bridge collapsesSuffice it to say how important they are, and how dangerous bridges are if they are not designed or built properly.
The same is true for cross-chain bridge protocols in the encrypted world. Cross-chain bridges are extremely easy to be targeted in terms of security risks. From the perspective of the possible vulnerabilities of smart contracts and the scale of attacks, the cross-chain bridge presents a quadratic risk aspect: as the number of bridged blockchains increases, the number of smart contracts required to maintain the operation of the cross-chain bridge also increases. Power of growth (at least in the peer-to-peer model). More smart contracts written at different runtimes based on custom configurations also rapidly increase cross-chain bridge risk. In the hub-and-spoke model, a vulnerability related to the central chain/network leads to asymmetric risk.
as the recentNomad attack incidentAs shown, one mistake could result in the loss of most or all of the bridge's money. However, the vulnerability has nothing to do with the cross-chain bridge, and may just stem from an operational error. In the case of the Ronin cross-chain bridge,poor operational securityAllowing phishing attacks to exploit, hackersGained control over the majority of validators securing the network, so that they were able to escape with funds worth more than 500 million yuan. The Wormhole attack that occurred in February was also due to the lack of authentication review, allowing attackers toCreate a Fake Signature, Steal Over $320 Million。
If no attention is paid to security, more negligence will inevitably occur, resulting in attacks and losses. For hackers, the huge TVL of cross-chain bridges is more attractive than ordinary protocols.
The above-mentioned attack events are not related to the bridging logic of the protocol, but to smart contract vulnerabilities and operational negligence. Even with the most well-written code, with the best security audits, as the number of connected blockchains and enabled functionality grows, there are bound to be bugs that get missed. For this reason, cross-chain bridges need to be configured not only to work safely under normal circumstances, but more importantly to handle extreme situations.
When using the cross-chain bridge, users mainly focus on the following features: good user experience, low slippage, high efficiency, and asset security. Among them, security is the top priority in evaluating cross-chain bridges.
With this in mind, let's look at how different bridges stack up to their safety. We will discuss from the following three levels to compare the security of different cross-chain bridges.
1. Trust Assumptions
2. Code Warranty
3. Security features
The first two will discuss: whether the cross-chain bridge has fully considered the source of its vulnerability/vulnerability at the two levels of trust layer and source code. The last point concerns whether a protocol recognizes that, no matter how carefully coded and audited, bugs are inevitable, and accordingly builds in additional safeguards to minimize potential losses to users.
first level title
trust assumption
From its core composition, the cross-chain bridge can be broken down into three components:
1. Smart contract: send/receive each piece of blockchain information
2. Oracle: verify whether the information comes from the original chain
3. Relayer: submit the message to the target chain
In practice, cross-chain bridges can vary greatly in terms of achieving consensus on oracles (around whether information is valid), which further affects relayers.
secondary title
Axelar
Axelar runs on the Cosmos PoS network. Validators are elected by Token holders and get voting rights in proportion. The voting weight is calculated by entrusting the rights and interests. The Axelar network verifies cross-chain information through the (t,n) threshold signature scheme, in which the signer's voting rights and weights are normalized to n, and n must be greater than t, which is the protocol threshold, to sign a message. The Axelar network currently has a maximum of 50 validators and must obtain a majority of more than 66.67% of the votes to sign a message (both variables can be modified through governance votes).
In theory, the number of validators can be infinite, but in practice, since validators don't need to run nodes for each blockchain, voting power can be skewed. In Axelar's currentvalidator listsecondary title
LayerZero
LayerZero is a cross-chain interoperability protocol that simplifies the problem of trustless communication between blockchains to the independence problem between two entities, the oracle (Oracle) and the relayer (Relayer). The oracle forwards the block header to the target chain, and the relayer forwards the transaction proof to the target chain, and the two together prove that the message is valid and that the information was indeed submitted to the original chain. User Applications (UA) are free to use LayerZero's default oracles and repeaters, or to create and run their own oracles and repeaters.
The default oracle is a Chainlink Decentralized Oracle Network (DON) that uses a threshold signature scheme (Threshold signature) among three participants (FTX, Polygon, and Sequoia). At the time of writing, due to the closed-source nature of the LayerZero codebase, I lack knowledge of its implementation. For application-specific version oracles, LayerZero's own AckeeauditPoint out that it is not difficult for an application to create and run its own oracles and relayers to successfully submit an invalid transaction proof and block header. This modularity does provide the benefit, though, that any future vulnerabilities will only affect those applications that use the affected oracle-relay pairs.
secondary title
Multichain
Multichain is a cross-chain information transfer protocol, derived from the previous Anyswap. Multichain uses Secure Multi-Party Computation (SMPC) to run threshold signature schemes, create public keys and sign messages passed from chain to chain. These nodes control the user account (EOA) in a trustless manner, and the wallet address corresponds to the split private key one by one. 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 verifying the message itself.
secondary title
Nomad
Nomad is an EVM-focused cross-chain messaging protocol that uses an optimistic mechanism to verify messages, where messages are added to the Merkle tree and hashed into a new root, which is published by the Updater to on the original chain. Updaters must post a security deposit, thereby incentivizing them to issue valid proofs and minimizing downtime. The Watcher will then have time to dispute the new root and submit a proof of fraud. Once the time frame is exceeded, this Merkle root is considered valid and forwarded to the target chain for publication, causing the original message (since the Merkle root is just an "incarnation" of the message) to be published on the target chain.
This optimistic model only requires an honest observer to verify whether an invalid update has been published. The price of this security model is that observers have about 30 minutes to submit fraud proofs, which delays the transmission of messages by 30 minutes. Because observers can prevent messages from being processed by sending false proofs of fraud to the target contract, Nomad uses a set of application-specified, permissioned observers. The security of the protocol is based on the probability that at least one honest observer exists, and the economic security of slashing updaters due to malicious behavior.
Nomad smart contracts can be accessed viaMulti-signature governance modelFor an upgrade, 3 out of 5 signers are required to perform governance changes and handle recovery management.
It should be noted that the recent Nomad hack had nothing to do with the security of its consensus mechanism; it was an unfortunateContract misconfigurationsecondary title
Wormhole
Wormhole utilizes a network of Proof-of-Authority (PoA) guardians as oracles and a network of permissionless relayers to transmit messages across chains. Each of the 19 Guardians runs a full node for each chain Wormhole supports and listens for messages from the Wormhole core contract on each chain. These guardians verify and sign the messages, which are then passed on to each other on the P2P network. Once a message is signed by more than 2/3 of the guardians (at least 13), it will be forwarded to the target chain. A by-product of this design is that it allows a completely trustless network of relayers to publish messages on the target chain, and because the messages are signed by guardians, the content of the messages can neither be altered nor censored, because Anyone can run a relayer to submit any information.
The security of the protocol comes from the guardian's reputation authority. In Wormhole's case, it was aThe 19 largest staking and infrastructure providers in Web3first level title
Code Warranty
Code Assurance refers to the work that needs to be done before code can be deployed on-chain. This may involve the following aspects:
1. Audits: Multiple, independent quality audits of published core and new features
2. Bounty: including providing attractive rewards for vulnerability disclosers, and the industry reputation of being able to readily pay large bounties
3. Testing: Test as many protocol stacks as possible on each code change, enabling regression testing in a growing software ecosystem
4. Deployment security: development in an open environment, code review before merging, contract bytecode verification, simulation testing before upgrading
secondary title
Axelar
Axelar has multiple public and reputableauditBug bounty programBug bounty program, with rewards of up to $1 million for critical vulnerability disclosures, but other levels of rewards are relatively small. The Axelar repo has contributors committing code regularly,Pull Requestsecondary title
LayerZero
LayerZero seems to be somewhat opaque when it comes to code deployment. Although there were several occasions from top auditorspublic auditsecondary title
Multichain
Multichain made multiple publicaudit, and has a bounty program of up to $2 million with Immunefi. Multichaintests performedLooks stagnant, seems to be limited to general ABIs and simple transfer tests. While there are continuous integration (CI) and continuous delivery (CD) runs and limited unit and integration testing, the deployment process appears to be mostly manual. Multichainreposecondary title
Nomad
Nomad recently accepted Quantstamp's publicaudit, and has an Immunefi bug bounty program with rewards of up to $1 million. Nomad'stest suitesecondary title
Wormhole
Wormhole'ssecurity pageHighlights their completed and ongoing audits from industry-leading audit firms. Wormhole has one on Immunefi$10 million bounty program. Since being hacked in February, Wormhole has paid out more than $11 million in bug bounties, including a payout to a white hat hacker in May.$10 million. Wormhole's repo uses a mix of unit and integration tests, has an extensible continuous integration (CI) and continuous delivery (CD) suite, and runs a series of mock tests to verify backwards compatibility andfuture upgradeability. Additionally, Wormhole makes transparent code review and responsible disclosure possible through active commits and contributor submissions to open construction. Wormhole's Pull Request requires at least three parties to merge the code (original developer plus 2 independent reviewers).
first level title
security function
secondary title
Axelar
In the white paper, Axelar describes a pool of funds allocated by the network as a safeguard and backup mechanism for governance control to provide users with guidance to restore governance in the event of an Axelar outage. In such a crisis, the "emergency unlock key" deposited by the threshold contract (managed by Axelar validators) will be shared with the auxiliary recovery user set. If needed, this cohort could potentially expand to thousands of individuals and institutions, who could collectively take control of the network to:
1. Set a rate limit on the amount of funds that can be transferred in/out of a particular chain
2. The situation of determining the packaging form of native assets on the chain
secondary title
LayerZero
LayerZero's bridging model includes a requirement for transaction applications to select relayers on the target chain. Therefore, in this model, the key point of the security function in the protocol is the repeater.
blog postblog postprovides clues as to how pre-crime works. The pre-criminal model basically allows the user application (UA) to define a specific set of states against which the relayer must authenticate. If these states are not verified, relayers will not relay transactions.
secondary title
Multichain
disclosuredisclosureSome of their security measures are mentioned, including mentioning some security features of their bridging configuration:
1. Transaction volume limit and total transaction volume limit: This feature allows blockchains with large transaction volumes to be limited to a specific upper limit. In addition, for blockchains with a low transaction volume, the method of limiting the total transaction amount is adopted.
2. On-chain monitoring: This mode involves monitoring software and on-chain watchdogs to detect anomalous behavior and trigger incident response actions.
3. Product Suspension: This feature allows suspending all products and effectively suspends all products while an Incident Response action is in place.
secondary title
Nomad
Nomad usesoptimistic verification model, that is, the message is signed on the original chain, and there is a built-in time window that will be enforced on the target chain. In a way, we can observe that this is akin to "do not open this letter earlier than this time". This period of time is useful to implement an "automatic circuit breaker" and stop transferring assets until the Merkle root is considered valid. this is inNomad Documentationsecondary title
Wormhole
Wormhole's messaging model is multi-cast, i.e. messages are notarized by a network of guardians/oracles from the origin chain and relayers that bring that message to the destination chain are not trusted. This model basically requires a very powerful network of oracles on which the in-protocol security features depend.
The Wormhole project has three main in-protocol security features being developed: governance, accounting, and emergency shutdown. These features were developed with public visibility, which gave us insight into how they would ultimately work. These features are waiting to be developed and adopted by Guardians.
1. Custody: This functionality is implemented in guardians/oracles, allowing guardians to monitor the notional amount of value flows from any chain of custody within a window of time. Guardians can set an acceptable upper limit for each chain, and once this upper limit is reached, the flow of assets beyond this chain will be prevented.
2. Accounting: This functionality is implemented in guardians/oracles, allowing guardians to maintain their own blockchains (aka "wormchains") that serve as cross-chain ledgers between different chains. This ledger not only allows guardians to act as on-chain validators, but also acts as an accounting plugin. Guardians can reject cross-chain transactions where the original chain does not have sufficient funds (validation is independent of smart contract logic).
epilogue
epilogue
Original link
