撰文：Jonathan Claudius, Anirudh Suresh, Eric Wong, Akshath Sivaprasad
Compile: 0x9F, 0x214, BlockBeats
In both the physical and cryptographic worlds, bridges are designed to connect two places separated by barriers. Physical bridges connect lands separated by natural barriers such as valleys and rivers, while cross-chain bridge protocols connect blockchains that otherwise have no way to communicate and synchronize. Every time a bridge is destroyed or attacked, its importance is highlighted. In the physical world, the well-documented history of catastrophic bridge collapses demonstrates just how important they are and how dangerous poorly designed or built bridges can be.
The same is true for the “ cross-chain bridge ” protocol in the crypto world . Cross-chain bridges are extremely vulnerable to security risks. From the perspective of possible vulnerabilities and attack scale of smart contracts, 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 quadratic. Quadratic growth (at least in the peer-to-peer model). More smart contracts written at different runtimes based on custom configurations also quickly increase cross-chain bridge risk. In the hub-and-spoke model, a vulnerability associated with the central chain/network can lead to asymmetric risk.
As the recent Nomad attack showed, one mistake can result in the loss of most or all of a bridge's funds. However, the vulnerability has nothing to do with the cross-chain bridge and may just be caused by an operational error. In the case of the Ronin cross-chain bridge, poor operational security measures allowed phishing attacks to take advantage. Hackers gained control of most of the verification nodes that ensure network security, allowing them to escape with more than 500 million worth of funds. The Wormhole attack in February was also due to a lack of verification review, allowing attackers to create a fake signature and steal more than $320 million.
Without attention to security, more oversights 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 attacks have nothing to do with the bridging logic of the protocol, but are related to smart contract vulnerabilities and operational negligence. Even with the most carefully written code, and with the best security audits, as the number of connected blockchains and enabled features increases, there are bound to be vulnerabilities that are missed. For this reason, cross-chain bridges need to be configured to not only work safely under normal circumstances, but more importantly, to cope with extreme situations.
Users mainly focus on the following features when using cross-chain bridges: good user experience, low slippage, high efficiency, and asset security. Among them, security is the top priority when evaluating cross-chain bridges.
With that in mind, let’s look at how different bridges stack up to their safety. We will discuss the following three levels to compare the security of different cross-chain bridges.
trust assumption
Code warranty
security features
The first two will discuss: whether the cross-chain bridge fully considers the root causes of its vulnerabilities/vulnerabilities at the two levels of trust layer and source code. The final point relates to whether a protocol recognizes that, no matter how carefully coded and audited, vulnerabilities are inevitable, and can accordingly build in additional safeguards to minimize potential losses to users.
In the interest of full transparency, before we go any further, we acknowledge that Jump Crypto is indeed the operational guardian of the Wormhole project and one of the core contributors to Wormhole, but we will be as objective as possible in this article and we welcome and accept any Feedback on how this article can be improved to show details of the differences between cross-chain bridges.
01. Trust assumption
From its core composition, the cross-chain bridge can be broken down into 3 components:
Smart contract: send/receive each blockchain information
Oracle: Verify whether the information comes from the original chain
Relayer: Submits the message to the target chain
In practice, cross-chain bridges can differ significantly in how they achieve consensus on oracles (around whether the information is valid), which further affects relayers.
Before we dive in, here’s a quick introduction to the consensus mechanisms used by some of the most popular bridges in the space.
1) Shoulders
Axelar runs on the Cosmos PoS network. Verifiers are elected by Token holders and receive voting rights in proportion. The voting weight is calculated by weighting the delegated equity. 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. n must be greater than t, which is the protocol threshold, before a message can be signed. The Axelar network currently has a maximum of 50 validators, and a majority vote of more than 66.67% is required to sign a message (both variables can be modified via governance votes).
In theory, the number of validators can be infinite, but in practice, because validators do not need to run nodes for each blockchain, voting power will be skewed. There are 47 validators in Axelar's current validator list, but only 20 have actual effective voting rights. On a specific blockchain, this number is even smaller. For example, if we only consider verifying information on Aurora, only 8 nodes are needed to successfully send a message, and only 4 nodes are needed to review the message.
2) LayerZero
LayerZero is a cross-chain interoperability protocol that simplifies the problem of trustless communication between blockchains to the independence problem between two entities: Oracle and Relayer. The oracle forwards the block header to the target chain, and the relay forwards the transaction proof to the target chain. The two work together to 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 relays, or they can create and run their own oracles and relays.
The default oracle is a Chainlink decentralized oracle network (DON), which uses a threshold signature scheme between three participants (FTX, Polygon, and Sequoia). At the time of writing this article, I lack visibility into the implementation of the LayerZero codebase due to its closed-source nature. Regarding application-specific versions of oracles, LayerZero’s own Ackee audit noted that it would not be difficult for applications that create and run their own oracles and relays to successfully submit an invalid transaction proof and block header. This modularity does provide the benefit, however, that if any future vulnerabilities arise, they will only affect those applications that use the affected oracle-relay pairs.
LayerZero's trust assumption depends on the behavior of both entities - as long as the oracle and relayer operate independently of each other, it is impossible to successfully send an invalid message. But conversely, because this system requires both the oracle and the relay to be functioning properly to verify the information, either party can delete the information data at will.
3) Multichain
Multichain is a cross-chain information transfer protocol derived from the previous Anyswap. Multichain uses Secure Multi-Party Computation (SMPC) to run a threshold signature scheme, create public keys and sign messages passed between chains. These nodes control user accounts (EOA) in a trustless manner, with wallet addresses corresponding to split private keys. These accounts are used to store and transfer assets to the target chain, which only needs to check whether the sender's address is trustworthy, without verifying the message itself.
The Multichain network currently consists of 24 SMPC nodes, run by different organizations, and requires a majority of nodes (the quantification of "most" does not seem to be public) to jointly verify messages. Therefore, the security of this protocol relies on the reputation security of SMPC nodes, which assumes that honest nodes account for more than half of all nodes. Sending data across chains requires 13 signers, and reviewing messages requires 12 nodes.
4) Nomad
Nomad is a cross-chain information transfer protocol focusing on EVM. It uses an optimistic mechanism to verify messages. The message is added to the Merkle tree and hashed to a new root, which is published by the Updater. on the original chain. Updaters must post a deposit, incentivizing them to publish valid proofs and minimize downtime. Watchers will then have time to dispute the new root and submit fraud proofs. Once the time range is exceeded, this Merkle root is considered valid and forwarded to the target chain for publication, causing the original message (because the Merkle root is just an "incarnation representative" of the message) to be published to the target chain.
This optimistic model only requires an honest observer to verify whether an invalid update has been published. The cost of this security model is that observers have approximately 30 minutes to submit fraud proofs, which delays message transmission by 30 minutes. Because observers can prevent messages from being processed by sending false fraud proofs to the target contract, Nomad uses a set of permissioned observers specified by the application. The security of the protocol is based on the probability of the existence of at least one honest observer, and the economic security of slashing updaters due to malicious behavior.
Nomad smart contracts can be upgraded through a multi-signature governance model, where 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 unfortunate contract misconfiguration that resulted in malicious behavior at the smart contract endpoint.
5) 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 supported by Wormhole and listens for messages emitted by the core Wormhole contract on each chain. These guardians verify and sign these messages, which are then passed to each other on the P2P network. Once a message receives signatures from 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 onto the target chain, and because the messages are signed by the guardian, the message content can neither be altered nor censored, because Anyone can run a relayer to submit any information.
The security of the protocol comes from the reputation and authority of the guardian. In the case of Wormhole, this is a group consisting of 19 of the largest staking and infrastructure providers in Web3. It takes 13 guardians to sign fake news and 7 guardians to censor it. Additionally, existing Guardians have the ability to vote to remove or replace other Guardians.
02. Code warranty
Code assurance refers to the work that needs to be done before code can be deployed on the chain. This may involve the following aspects:
Audit: Conduct multiple, independent quality audits of exposed core features and new features
Bounty: including attractive rewards for vulnerability disclosers and an industry reputation for being able to pay large bounties readily.
Test: Test as many protocol stacks as possible on every code change to perform regression testing in a growing software ecosystem
Deployment security: development in a public environment, code review before merging, contract bytecode verification, simulation testing before upgrades
The following table summarizes the performance of five cross-chain bridge protocols in these four aspects.
1) Shoulders
Axelar has multiple public and reputable audits, and runs a fairly robust (although less active in recent months) test suite: continuous integration (CI) and continuous delivery (CD) runs, bash build scripts, and checksums (checksum) verification. Axelar has partnered with Immunefi to set up a bug bounty program, offering bounties of up to $1 million to those who disclose serious vulnerabilities, but bounty amounts at other levels are relatively small. The Axelar repo has contributors regularly submitting code, and Pull Requests require approval by at least 1 reviewer.
2) LayerZero
LayerZero seems a bit opaque when it comes to code deployment. While there are several public audits from top auditors, there is a lack of public continuous integration (CI) and continuous delivery (CD) processes. The code appears to be a one-time public release, not an agile development process. The tests conducted appear to be relatively outdated and limited to JavaScript tests. The Pull Request appears to lack a mandatory peer review step. LayerZero did announce a $15 million bug bounty program in April in partnership with Immunefi. However, there has been no public release of the project to date, and there are no instructions on how to submit bugs for bounties.
3) Multichain
Multichain has conducted multiple public audits and has a bounty program with Immunefi worth up to $2 million. Testing by Multichain seems stagnant and seems to be limited to general ABI and simple transfer testing. While there are continuous integration (CI) and continuous delivery (CD) runs and limited unit and integration tests, the deployment process appears to be mostly manual. The Multichain repo has contributors regularly submitting code, but it appears that only one party is required to merge the code (the original developers are able to merge their own code).
4) Nomad
Nomad recently underwent a public audit by Quantstamp and has a bug bounty program with Immunefi offering bounties of up to $1 million. Nomad's test suite includes some tests around using Foundry for routing and messaging, and like Axelar has a bash build script to build and verify the bytecode. Nomad's Repo has contributors regularly submitting code, and its Pull Request requires at least two parties to merge the code (the original developer plus 1 independent reviewer).
5) Wormhole
Wormhole’s security page highlights their completed and ongoing audits from industry-leading audit firms. Wormhole has a $10 million bounty program on Immunefi. Since being hacked in February, Wormhole has paid out more than $11 million in bug bounties, including $10 million paid to a white hat hacker in May. Wormhole's repo uses a mix of unit and integration testing, has an extensible continuous integration (CI) and continuous delivery (CD) suite, and runs a series of simulated tests to verify upgrade backward compatibility and future upgrade capabilities. In addition, Wormhole builds openly through active commits and contributor submissions, allowing transparent code review and responsible disclosure. Wormhole's Pull Request requires at least three parties to merge the code (original developer plus 2 independent reviewers).
Note that the protocol's code assurance approach will be greatly improved after experiencing a serious security incident. For example, Wormhole’s approach to code assurance was quickly improved after the hack. Likewise, following this week’s attacks, the Nomad protocol is likely to adopt more code assurance methods in the near future. It's obviously best to have these practices in place before an incident occurs, but unfortunately they're not always on the priority list.
03. Security features
As mentioned above, once security problems occur in cross-chain bridges, the cost is extremely high. The above code assurance measures are critical to the security plan of the cross-chain bridge provider. In this section we’ll take a closer look at the in-protocol security features that each cross-chain bridge is developing or deploying to understand how these cross-chain bridges achieve multiple layers of defense when core trust assumptions and code assurance are fundamentally insufficient.
1) Shoulders
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 on restoring governance in the event of an Axelar outage. In such a crisis, the "emergency unlock key" stored by the threshold contract (managed by Axelar validators) will be shared with the assisted recovery user set. If necessary, this queue could expand to thousands of individuals and institutions who could collectively control the network to:
Set a rate limit on the amount of funds that can be transferred in/out of a specific chain
Determining the packaging form of native assets on the chain
These features appear to be proprietary and not yet open source. Furthermore, these proposed features do not provide passive safety to limit risk, but are activated in life-or-death situations.
2) LayerZero
LayerZero’s bridging model includes the requirement for trading applications to select a relay on the target chain. Therefore, in this model, the key to the security functionality within the protocol is the repeater.
In April, the LayerZero team introduced their approach to in-protocol security features called “the dome” and “pre-crime.” There is little public information about the dome's capabilities, but a blog post provides clues as to how Pre-Crime works. The pre-crime model basically allows a user application (UA) to define a specific set of states against which the relay must authenticate. If these states are not verified, the relayer will not relay the transaction.
Note that these features appear to be proprietary and are not yet open source. Although conceptually strong, it is difficult to assess its effectiveness independently.
3) Multichain
In a recent article, Multichain disclosed some of their security measures, including mentioning some of the security features of their bridge configuration:
Transaction volume limit and total transaction limit: This feature allows blockchains with larger transaction volumes to be limited to a specific upper limit. In addition, for blockchains with low transaction volume, the total transaction amount limit is adopted.
On-chain monitoring: This model involves monitoring software and on-chain watchdogs to detect abnormal behavior and trigger incident response behaviors.
Product Suspension: This feature allows all products to be suspended and effectively suspends all products while incident response actions are implemented.
Security Fund: This is actually a protection fund that uses 10% of all cross-chain fees to compensate users for property losses in special circumstances.
4) Nomad
Nomad utilizes an optimistic verification model, where messages are signed on the original chain and have a built-in time window that is enforced on the target chain. In a way, we can observe that this is similar to "open this letter no earlier than this time". This period is useful for implementing an "automatic circuit breaker" and stopping the transfer of assets until the Merkle root is considered valid. This has appeared as a concept in the Nomad documentation and development appears to be ongoing.
5) Wormhole
Wormhole's messaging model is multi-cast, meaning messages are notarized from the original chain by a network of guardians/oracles, and the relays that bring the message to the target chain are not trusted. This model basically requires a very powerful oracle network, on which the security features within the protocol depend.
The Wormhole project has three main in-protocol security features under development: supervision, accounting, and emergency shutdown. These features are developed with public visibility, which gives us insight into how they will ultimately work. These features are awaiting development completion and adoption by guardians.
Custody: This feature is implemented in the Keeper/Oracle and allows the Keeper to monitor notional amounts of value flow from any custodial chain within a time window. The guardian can set an acceptable upper limit for each chain. Once this upper limit is reached, the flow of assets beyond the chain will be blocked.
Accounting: This feature is implemented in guardians/oracles, allowing guardians to maintain their own blockchains (also known as "wormchains"), which can serve as cross-chain ledgers between different chains. This ledger not only allows the guardian to act as a validator on the chain, but also acts as an accounting plug-in. Guardians can reject cross-chain transactions where the original chain does not have sufficient funds (verification is independent of smart contract logic).
Shutdown: This function is implemented on the chain and allows the guardians to reach a consensus to temporarily stop the flow of assets on the cross-chain bridge after realizing the threat of the cross-chain bridge. The current implementation allows implementation via on-chain function calls in the proposed implementation.
04. Conclusion
In the coming months and years, we believe security will be where the gap widens between cross-chain bridges. Those that prioritize security are more likely to survive the crisis, while those that don't are likely to not. Security may once have been just a source of competitive advantage; however, it must now become the top priority feature for every cross-chain bridge. We hope that all cross-chain bridges will unite to jointly improve the level of cross-chain bridge security technology.
**This article only represents the views of the original author and does not constitute any investment opinions or recommendations.
-END-
[The purpose of publishing articles is to disseminate more valuable information. The copyright of the article belongs to the original author. Its content and opinions do not represent the position of Unitimes. The pictures appearing on this WeChat platform are all collected from the Internet, and the copyright belongs to the copyright owner. If the copyright owner believes that his work is not suitable for everyone to browse or should not be used for free, please add WeChat uniforms2018 to contact us, and this platform will make corrections immediately. 】
Just click " Like " when you come.
