Listen to Jump Crypto, LayerZero, Wormhole and other cross-chain bridge advantages and disadvantages

Article title: Security Stack-up: How Bridges Compare

Original article by Jonathan Claudius, Anirudh Suresh, Eric Wong, Akshath Sivaprasad, Jump Crypto

0x9F, 0x214, BlockBeats

Introduction to the

In both the physical and encrypted worlds, Bridges serve to connect two places separated by obstacles. Physical Bridges connect land separated by natural barriers like valleys and rivers, while cross-chain Bridges connect blockchains that otherwise have no way to communicate and synchronize. Every time a bridge is destroyed or attacked, its importance becomes apparent. In the physical world,Catastrophic bridge collapses are well documented in historyEnough to show how important they are and how dangerous poorly designed or built Bridges can be.

The same is true of cross-chain bridge protocols in the crypto world. Cross-chain Bridges are easy to target in terms of security risks. Cross-chain Bridges present a quadratic risk dimension in terms of the scale of possible vulnerabilities and attacks on smart contracts: As the number of blockchains bridged increases, so does the number of smart contracts needed to keep the cross-chain bridge running (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 most recentNomad Indicates the attack eventAs shown, an error can result in the loss of most or all of the bridge's funds. However, the breach is not related to the chain bridge, and may simply result from an operational error. In the case of the Ronin cross-chain bridge,Poor operational safety measuresTo allow for phishing attacks, hackersGain control over most of the verification nodes that guarantee network securityIn order to get away with more than $500 million. The Wormhole attack in February also resulted from a lack of verification checks that allowed attackers toCreate a false signature and steal more than $320 million.

Without a focus on security, it is inevitable that more negligence will occur, resulting in attacks and losses. TVL, with its large size across the chain bridge, is more attractive to hackers than ordinary protocols.

These attacks are not related to protocol bridging logic, but to smart contract vulnerabilities and operational negligence. Even with the most carefully written code and 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 conditions, but more importantly to cope with extreme situations.

Users focus on the following features when using a cross-chain bridge: good user experience, high efficiency with low slip points and asset security. Among them, safety is the top priority in evaluating cross-chain Bridges.

With that in mind, let's look at how different Bridges stack up their safety. We will discuss and compare the safety of different chain Bridges from the following three levels.

1. Trust assumptions

2. Code quality assurance

3. Security features

The first two will discuss whether cross-chain Bridges have adequately considered the source of their vulnerability/vulnerability at both the trust and source levels. The final point concerns whether a protocol recognizes that vulnerabilities are inevitable, no matter how carefully coded and audited, and can accordingly establish additional safeguards to minimize potential losses to users.

In order to be completely transparent, and before going further, we acknowledge that Jump Crypto is indeed the operational guardian of Wormhole and a core contributor to Wormhole, but we will be as objective as possible in this post. We welcome and accept any feedback on how to improve the post. To show the differences between chain Bridges in detail.

Trust assumptions

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

1. Smart Contract: Send/receive each blockchain message

2. Oracle: Verify whether the information comes from the original chain

3. Relayer: delivers messages to the target chain

In practice, cross-chain Bridges can vary greatly in achieving consensus (around whether the information is valid) on the predictor, which further affects the repeater.

Before we dive in, here's a quick introduction to the consensus mechanisms used by some of the most popular Bridges in the field.

Axelar

Axelar operates on a Cosmos based PoS network, where verifiers are elected by Token holders and are given proportional voting rights, with voting weights calculated by weighting delegated interests. The Axelar network verifies cross-chain information through a (t,n) threshold signature scheme, where the signer's voting power, weight is normalized to n, and n must be greater than t, the protocol threshold, in order to sign a message. The Axelar network currently has a maximum of 50 verifiers and must obtain a majority vote of more than 66.67% to sign the message (both variables can be modified by governance voting).

In theory, the number of verifiers can be infinitely large, but in practice, because verifiers don't need to run nodes for each blockchain, voting power is skewed. At Axelar's presentList of verifiersThere are 47 verifiers, but only 20 have actual voting rights. On a particular blockchain, the number is even smaller. For example, if we only think about verifying the information on Aurora, it only takes eight nodes to successfully send a message, and only four nodes to review the message.

LayerZero

LayerZero is a cross-chain interoperable protocol that reduces the trust-free communication between blockchains to an independent problem between two entities: an Oracle and a Relayer. The prophecy machine forwards the block header to the target chain, while the repeater forwards the proof of transaction to the target chain. Together, they prove that the message is valid and that the information is indeed submitted to the original chain. User applications (UA) are free to use LayerZero's default predictor and repeater, or they can create and run their own predictor and repeater.

The default predictor is a Chainlink decentralized predictor network (DON) that uses a Threshold signature scheme among three participants (FTX, Polygon, and Sequoia). At the time of this writing, due to the closed-source nature of the LayerZero codebase, I had little knowledge of its execution. For specific application versions of the prophecy machine, LayerZero's own AckeeThe auditIt is pointed out that it is not difficult for applications that create and run their own prophecies and Repeaters to successfully submit an invalid transaction proof and block header. However, this modularity does provide the benefit that if any future vulnerabilities occur, they will only apply to those applications that use the affected prophesy-repeater pair.

LayerZero's trust assumption depends on the behavior of the two entities -- as long as the predictor and repeater operate independently of each other, it is impossible to successfully send invalid messages. On the other hand, because the system requires both the predictor and the relay to be working properly, either can delete the information at will.

Multichain

Multichain is a cross-chain information transfer protocol derived from Anyswap. Multichain uses Secure Multiparty computing (SMPC) to run a threshold signature scheme, create a public key and sign messages passing from chain to chain. These nodes control the user account (EOA) in a trust-free manner, and the wallet address corresponds to the split private key. These accounts are used to store assets and transfer them to the target chain, which simply checks whether the sender's address is trusted, rather than verifying the message itself.

The Multichain network currently consists of 24 SMPC nodes, run by different institutions, and requires a majority of nodes (the quantification criteria for "majority" does not appear to be public) to jointly verify messages. Therefore, the security of this protocol depends on the reputational security of SMPC nodes, and it assumes that more than half of all nodes are honest. It takes 13 signers to send data across the chain and 12 nodes to censor messages.

Nomad

Nomad is an EVM-focused cross-chain information transfer protocol that employs optimistic mechanism to verify messages, where messages are added to the Merkle tree and are hashed into a new root to be published on the original chain by Updater. Upgraders must post a deposit, which gives them an incentive to post valid certifications and minimize downtime. The Watcher will then have time to dispute the new root and submit proof of fraud. Once the time frame is exceeded, this Merkle root is considered valid and forwarded to the target chain for publication, allowing the original message (since the Merkle root is only an "avatar representative" of the message) to be published to the target chain.

This optimistic model requires only an honest observer to verify that an invalid update has been released. The trade-off for this security model is that the observer has about 30 minutes to submit proof of fraud, which delays the transmission of the message by 30 minutes. Because observers can prevent messages from being processed by sending false proof of fraud to the target contract, Nomad uses a set of authorized observers specified by the application. The security of the protocol is based on the possibility of having at least one honest observer and the economic security of the renewers reduced by malicious actions.

Nomad smart contract can be approvedMulti-sign management modeFor an upgrade, three of the five signers are required to perform governance changes and handle recovery management.

It should be noted that the recent Nomad hack has nothing to do with the security of the consensus mechanism; It is an unfortunateContract configuration error, resulting in malicious behavior on the smart contract terminal.

Wormhole

Wormhole utilizes a network of Proof of Authority (PoA) guardians as predictors and a permissionless repeater network to transmit messages across the chain. Each of the 19 Guardians runs a full node for each of the chains Wormhole supports, and listens for messages from the Wormhole core contract on each chain. These guardians verify and sign the messages and then pass them on to each other over the P2P network. Once a message receives more than 2/3 of the Guardian signatures (at least 13), it is forwarded to the target chain. As a by-product of this design, it allows a completely trust-free repeater network to post messages to the target chain. Since the messages are signed by the guardian, the message content can neither be changed nor censored, since anyone can run a repeater to submit any information.

The security of the agreement comes from the reputation and authority of the Guardian. In the Wormhole case, this is a case made byThe 19 largest pledge and infrastructure providers in Web3To form a group. It takes 13 guardians to sign false messages and 7 guardians to censor messages. In addition, existing guardians have the ability to vote to remove or replace other guardians.

The code quality assurance

Code warranty refers to the work that needs to be done before the code is deployed on the chain. This may involve the following aspects:

1. Audit: Conduct multiple, independent quality audits of the disclosed core functions and new functions

2. Bounties: These include attractive rewards for bug debtors and an industry reputation for being able to readily pay large bounties

3. Testing: Test as many protocol stacks as possible on each code change to perform regression testing in a growing software ecosystem

4. Deployment security: development in an open environment, review before merging code, contract bytecode verification, simulation testing before upgrading

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

Axelar

Axelar has many open and reputableThe auditAnd run a fairly robust (though less active in recent months) test suite: continuous integration (CI) and continuous Delivery (CD) runs, bash build scripts, and checksum validations. Axelar partnered with Immunefi to set upBug bounty program, which offers rewards of up to $1 million for serious bug disclosures, but smaller rewards for other levels. The Axelar Repo has contributors who regularly submit code,Pull RequestApproval by at least 1 reviewer is required.

LayerZero

LayerZero seems a little opaque in terms of code deployment. Although there were several from top auditorsPublic audit, but lack overt 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 performed seem relatively old-fashioned and limited to JavaScript testing. The Pull Request seems to lack a mandatory peer review step. LayerZero did announce a $15 million bug bounty program in partnership with Immunefi in April. However, no projects have been publicly released to date, and there are no instructions on how to submit bugs to earn a bounty.

Multichain

Multichain has been exposed several timesThe audit, and Immunefi has a bounty program of up to $2 million. MultichainTests performedIt looks stagnant and seems to be limited to general ABI and simple transition testing. While there are continuous integration (CI) and continuous delivery (CD) runs and limited unit and integration testing, the deployment process appears to be largely manual. The MultichainrepoThere are contributors who regularly submit code, but it seems that only one party is required to merge the code (the original developers can merge their own code).

Nomad

Nomad recently accepted the publication of QuantstampThe auditAnd has a bug bounty program from Immunefi that offers bounties of up to $1 million. The NomadThe test suiteIncludes some testing around routing and messaging using Foundry, as well as Bash build scripts to build and validate bytecodes like Axelar. Nomad's Repo has contributors regularly submitting code, and its Pull Request requires at least two parties to merge code (the original developer plus one independent reviewer).

Wormhole

The WormholeSecurity pageHighlights their completed and ongoing audits from industry-leading audit firms. Wormhole has one at ImmunefiA $10 million bounty program. Wormhole has paid out more than $11 million in bug bounties since the February attack, including one paid to a white hat hacker in May10 million dollars. Wormhole's REPo uses hybrid unit and integration testing, has a scalable continuous integration (CI) and continuous Delivery (CD) suite, and ran a series of simulation tests to verify the backward compatibility of the upgrade andFuture upgrade capability. In addition, Wormhole enables transparent code review and responsible disclosure through active submissions and contributor submissions to the open build. Wormhole's Pull Request required at least three parties to merge the code (the original developer plus two independent reviewers).

Note that the protocol's code warranty approach can be significantly improved after a serious security incident. Wormhole's code warranty, for example, improved rapidly after the attack. Similarly, in the wake of this week's attack, the Nomad protocol is likely to adopt more code warranties in the near future. These are obviously best done before the event occurs, but unfortunately they are not always on the priority list.

Safety features

As mentioned above, safety problems with chain Bridges are extremely costly. The above code assurance measures are essential to the safety program of the cross-chain bridge supplier. In this section, we take a closer look at the in-protocol security features being developed or deployed for each cross-chain bridge to see how these cross-chain Bridges enable multiple layers of defense when core trust assumptions and code warranties are fundamentally inadequate.

Axelar

In the white paper, Axelar describes a pool of funds allocated by the network as a backstop 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 the Axelar verifier) is shared with the auxiliary recovery user set. If needed, this queue may expand to thousands of individuals and institutions who can collectively control the network to:

1. Set rate limits for the amount of capital that can be transferred into/out of a particular chain

2. Determine the packaging form of the native asset on the chain

These features appear to be proprietary and not yet open source. In addition, these proposed features do not provide passive security to limit risk, but are activated in life-or-death situations.

LayerZero

LayerZero's bridging model includes a requirement for the trading application to select a repeater on the target chain. Therefore, in this model, the key to security within the protocol is the repeater.

In April, the LayerZero team introduced their approach to in-protocol security, called "The Dome" and "Pre-Crime." There's very little public information about the dome's function, butBlog postsProvides clues to how precrime works. The precriminal model basically allows the user application (UA) to define a specific set of states against which the repeater must authenticate. If these states are not verified, the repeater will not relay the transaction.

Note that these features appear to be proprietary and are not currently open source. While conceptually powerful, it is difficult to independently assess its effectiveness.

Multichain

In a recent article by Multichain,Disclosure of theDiscusses some of their security measures, including mentioning some of the security features of their bridge configuration:

1. Volume limit and total volume limit: This feature allows blockchains with large volume of transactions to be capped at a specific cap. In addition, for the blockchain with low transaction volume, the total transaction volume limit is adopted.

2. On-chain monitoring: This mode involves monitoring software and on-chain watchdogs to detect abnormal behavior and trigger emergent response behavior.

3. Product Pause: This feature allows all products to be suspended and effectively suspended when emergency response behavior is implemented.

4. Security Fund: This is actually a security fund, which takes out 10% of all cross-chain expenses to compensate users for property losses in special circumstances.

Nomad

Nomad useoptimistic verification modelThat is, the message is signed on the original chain and has a built-in time window that is enforced on the target chain. In a way, we can observe that this is akin to "open the letter no earlier than this time". This time is useful for implementing "automatic circuit breakers" and stopping the transfer of assets before the Merkle root is considered valid. This isNomad documentChina has emerged as a concept and development seems to be underway.

Wormhole

Wormhole's messaging model is multi-cast, meaning that a message is notarized from the original chain by the guardian/predictor network and does not trust the repeater that carries the message to the destination chain. This model basically requires a very powerful network of prognostic machines, on which the security function within the protocol depends.

The Wormhole project has three major in-protocol security features under development: regulatory, accounting, and emergency shutdown. These features were developed in public view, giving us insight into how they might ultimately work. These features are waiting to be developed and adopted by the Guardians.

1. Oversight: This feature is implemented in the Guardian/Prophecy Machine, allowing the Guardian to monitor the nominal amount of value flow from any regulated chain over a time window. The Guardian can set an acceptable upper limit for each chain and, once this is reached, block the flow of assets beyond that chain.

2. Accounting: This feature is implemented in the Guardian/Prophecy Machine, allowing Guardians to maintain their own blockchains (aka "Wormchain"), which can act as cross-chain ledgers between different chains. This ledger not only allows the Guardian to act as an on-chain verifier, but also as an accounting plug-in. The Guardian can reject cross-chain transactions where the original chain does not have sufficient funds (verification is independent of smart contract logic).

3. Shutdown: This feature is implemented on the chain, allowing Guardians to temporarily stop the flow of assets across the chain bridge by consensus if they become aware of a threat to the bridge. The current embodiment allows this to be done through on-chain function calls in the proposed embodiment.

conclusion

In the coming months and years, we believe security will be the place where the gap between chain Bridges will widen. Chain Bridges that prioritize safety are more likely to survive the crisis than those that don't. Security may once have been only a source of competitive advantage, however, now it must become a primary feature that every cross-chain bridge should prioritize. We hope that all cross-chain Bridges will unite and jointly improve the level of cross-chain bridge safety technology.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia