This article discusses the security mechanism of 5 message cross-chain projects
Author: Ailsa
The prosperity of multi-chain ecology has given birth to users' demand for cross-chain. The cross-chain interaction between chains is increasing day by day, but at the same time, cross-chain security incidents are frequently heard, and cross-chain security has become the focus of market attention. According to the "2022 Global Web3 Blockchain Security Situation Report and Encryption Industry Supervision Policy Summary" jointly issued by Chengdu Lianan and others, the total loss caused by various attacks in the Web3 field in 2022 will reach 3.6 billion US dollars, of which cross-chain application security The losses caused by incidents accounted for 52.5%, ranking first among all project types.
image description

Figure 1 Top 10 Cross-chain Projects by Loss Amount
Usually, cross-chain projects bring together a large number of assets, and their TVL (Total Value Locked) far exceeds that of general blockchain protocols, which makes cross-chain projects easy to become the first choice for hackers. Cross-chain security is of paramount importance.
Security not only comes from the security brought by the cross-chain solution itself, but also rooted in the security policies designed by project decision makers to prevent and prevent security crises.
The current market demand for cross-chain is mainly for digital assets, but cross-chain is not limited to the transfer and exchange of assets. Chain, developed to message cross-chain and function cross-chain, from cross-chain of single type of data to cross-chain of general data.
first level title
1. Security brought by cross-chain solutions
Cross-chain technology mainly solves the problem that assets or information cannot be exchanged between different blockchains. A cross-chain process consists of multiple different blockchain transactions, which run on different blockchain systems. Due to the differences in consensus mechanisms and rules between different chains, in the cross-chain process, it is necessary to The content is verified to ensure the security of the cross-chain process.
secondary title
1.Axelar
image description

Figure 2 Axelar Technology Stack Diagram
The Axelar network itself is an L1 blockchain based on the PoS consensus. Axelar consists of validators of the decentralized network, security gateway contracts, unified translation, routing architecture, and a set of programming interfaces (APIs) for protocols and applications.
Axelar runs nodes of different chains through its validators to obtain and synchronize state information in each blockchain system. Validators are elected by Token holders and have voting rights in proportion. The voting weight is calculated by weighting the entrusted rights and interests. There are currently 70 active validators on the Axelar network, and a majority vote of more than 66.67% must be obtained to sign a message.
secondary title
2.Celer IM
Celer IM is Celer Network's developer-oriented tools and infrastructure, and cBridge can be regarded as an asset bridge built on Celer IM.
Celer has set up double security for all users.
The first is that the security of cBridge is guaranteed by the State Guardian Network (SGN for short). SGN is a PoS blockchain based on tendermint. Other products of Celer Network, including cBridge and Celer IM, highly utilize SGN's PoS security, fast confirmation and low-cost features in cross-chain transactions.
SGN has 21 verifiers, and a message must be approved by 2/3 of the verifiers. Verifiers who want to become SGN need to stake the token CELER. In addition, Axelar has set up a pledge and slashing mechanism. If the verification fails or is maliciously damaged, it will bear the risk of being confiscated. The more CELR is pledged, the more secure the network will be.
Currently, the Celer State Guardian Network 2.0 has been successfully upgraded. Compared with SGN 1.0, SGN 2.0 focuses on optimizing its ability to capture value from transactions: for cBridge, the value captured by SGN is based on the size of each transaction it processes in the cBridge fund pool mode; for Celer IM , value capture is based on the size of cross-chain messages.
secondary title
3.Layerzero
image description

Figure 3 Layerzero communication process (source: Layerzero white paper)
secondary title
4.Multichain anyCall
Multichain, formerly known as Anyswap, is an infrastructure focused on cross-chain tracks, and is committed to becoming the ultimate router for Web 3. anyCall is a new generation of comprehensive message cross-chain interaction protocol abstracted by Multichain based on its Bridge and Router products.
Multichain's cross-chain technology solution adopts the Secure Multi-party Computation (SMPC) solution. Through the unique key sharding technology, the key shards are distributed on different nodes, and each node independently owns Part of the private key and the complete private key will not appear during the entire MPC network life cycle. Through the SMPC secure multi-party computation + TSS threshold signature technology, the whole process of key generation, storage and verification is guaranteed, and in this security guarantee Based on the realization of interoperability between nodes.
image description

Figure 4 anyCall technical architecture (source anyCall white paper)
The underlying fastMPC decentralized trust machine ensures the decentralized nature of anyCall's comprehensive message cross-chain interaction protocol. Currently the Multichain network consists of 21 nodes, run by different institutions, and requires a majority of nodes to jointly verify messages. The security of Multichain relies on the reputation of nodes. SMPC node members do not need to pledge and are relatively fixed. The security of AnyCall is based on the assumption of trust in SMPC nodes.
secondary title
5.Wormhole
image description

Figure 5 Security brought by cross-chain solutions
first level title
2. Security Incident Response Policy
The cross-chain solution of the cross-chain project itself does not mean that all risks can be avoided, and other security policies need to be added to actively prevent and respond to security risks. The design of security policy can provide users with stronger security guarantees, and the security policy should run through before, during and after the occurrence of security incidents.
Before a security incident: There may be security risks in the project at this stage, but they have not been discovered or exploited. The project carries out the security operation of the project in accordance with the security policy determined in advance.
A security incident is occurring: a security incident is occurring at this stage, but the project party may not be aware of it. It is very important to take measures to allow the project to discover the security incident in a timely manner.
secondary title
1.Axelar
Axelar's security incident response policy mainly focuses on security incidents before they occur. The main measures include conducting security audits, enabling bug bounties, frequent key rotation, and rate limiting.
(1) Security audit. At present, Axelar's security audit coverage covers its core protocol, smart contract, cryptographic library, front-end and back-end code, etc. From August 2021 to August 2022, Axelar has conducted more than 27 audits, and audit agencies include Ackee Blockchain, Chaintroopers , Certik, etc. See detailshttps://github.com/axelarnetwork/audits。
(2) Bug bounty. Starting from March 10, 2022, the cooperation between Axelar and Immunefi has set up a bounty program with a maximum value of 2.25 million US dollars, seehttps://immunefi.com/bounty/axelarnetwork/. Axelar also clarifies how to submit vulnerabilities in its official documents, but by submitting tosecurity@axelar.networkvulnerability, Axelar clearly stated that the maximum reward is $100. For details, seehttps://docs.axelar.dev/bug-bounty。
(3) Frequent key rotation. Attackers may attempt to amass malicious keys by sequentially compromising validators Key rotation can protect the Axelar network from persistent attackers.
secondary title
2.Celer Network
Celer Network's Security Incident Response Policy focuses on the pre- and during-security incident incidents.
Celer's main measures before the security incident include conducting security audits, enabling bug bounty, building a risk control system, application layer traffic limiting, 24-hour monitoring and active front-end and DNS integrity checks.
(1) Security audit. For Cbridge, Celer has only conducted 3 audits so far, and the cooperative audit agencies are CertiK, PeckShield and SlowMist. See detailshttps://cbridge-docs.celer.network/reference/audit-reports. For CelerIM, Celer currently has 2 audits with PeckShield and SlowMist. See detailshttps://im-docs.celer.network/audit-reports。
(2) Bug bounty. Since November 18, 2021, Celer has partnered with Immunefi to set up a bounty program of up to $2 million. See detailshttps://immunefi.com/bounty/celer/。
(3) Build a risk control system. The overall liquidity, asset information and changes of the bridge can be monitored through the wind control system.
(4) Current limiting function. The security barrier set by Celer at the application layer makes it impossible to exceed a certain threshold per unit time, and if it exceeds, the time delivery will be postponed.
(5) 24-hour monitoring mechanism. Suspicious problems can be found in the first time.
(6) Proactive front-end and DNS integrity checks. This is a feature that Celer added in response to the attack that occurred in August 2022 to prevent similar incidents from happening again.
secondary titlehttps://mp.weixin.qq.com/s/SInU_o 3 Ct-7 A 6 pFbKLqzHQ。
3.Layerzero
Layerzero's security incident response policy mainly focuses on security incidents before they occur, and the main measures include conducting security audits and opening bug bounties.
(1) Security audit. LayerZero Labs stated that it has commissioned more than 35 audits, but LayerZero is relatively opaque in terms of code deployment, and its security audit content cannot be publicly queried on its Github. For details, seehttps://github.com/LayerZero-Labs/Audits。
(2) Bug bounty. In the official layerero document, it is stated that a real-time bug bounty program with a maximum reward of 15 million US dollars will be established, and the report submission address is given. See detailshttps://layerzero.gitbook.io/docs/bug-bounty/bug-bounty-program。
secondary title
4.Multichain
In August 2022, Multichain Algorithm & Security Officer X Chang clearly mentioned Multichain’s security strategy in his official blog, dividing the time of hacking into three stages, namely: before the occurrence, when it occurs, and after it occurs , and each stage has corresponding coping steps and strategies.
Security measures before security incidents include security company audits and internal developer audits, opening bug bounties, public opinion monitoring of security incidents, cross-chain amount limits, and chain capital flow and total amount limits.
(1) Company-wide audit and internal developer audit. Up to now, Multichain has conducted a large number of external audits. The external audit partners include BlockSec, Certik, Dedaub, PeckShield, SlowMist, TrailofBits, Verichain and many other well-known institutions. AnyCall, Router V 7, VeMulti, Multichain V 6, Threshold-DSA, V 5 ERC 20, Cross Chain-Bridge and other products launched by Multichain have all undergone strict external audits. See detailshttps://github.com/anyswap/Anyswap-Audit/. At the same time, the Multichain team has set up periodic internal audit meetings, at least once a month.
(2) Bug bounty. Multichain runs two bug bounty programs. The first is that since March 16, 2022, Multichain has formally established cooperation with Immunefi, setting up a bounty program with a maximum value of 2 million US dollars, and according to the specific analysis of the severity of the submitted bugs, the reward There is no cap on gold. See detailshttps://immunefi.com/bounty/multichain/. In addition, Multichain also provides an optional bug bounty program, MultichainRewards of up to $1 million will be awarded for qualifying vulnerability discoveries. See detailshttps://docs.multichain.org/getting-started/security/bug-bounty-alternative。
(3) Public opinion monitoring of security incidents. By setting keywords to monitor public opinion on major media platforms, we hope to obtain the latest security incidents in the industry as soon as possible, draw inferences from one instance, reflect on whether there are similar problems in Multichain products, and respond to incidents in a timely manner.
(4) Cross-chain amount limit and chain capital flow and total limit. For cross-chain transactions of large amounts of funds, the platform adopts the rule of delaying the arrival of funds. For a newly developed chain or a chain with a slightly lower security rating, within a certain period of time, the total amount of cross-in or cross-out is limited within a certain range.
Security measures in the event of security incidents include monitoring abnormalities on the chain and mobilizing the power of the community and DAO to feedback abnormal behaviors of platform products.
(1) Monitoring of abnormal conditions on the chain. By setting up a series of on-chain monitoring strategies Watchdogs, it is hoped that data anomalies can be detected in a timely manner.
(2) Mobilize the power of the community and DAO, and feedback the abnormal behavior of platform products. Distribute the power of community users and DAO to give feedback on the abnormal situation of Multichain products, and the team will make timely response measures after analyzing the abnormal behavior verification.
The security measures after the security incident include suspending all related platform products and security funds covering user asset risks.
(1) Suspend all related platform products. After knowing the existence of the vulnerability in the first time, shut down the product in a timely and effective manner.
secondary titlehttps://medium.com/multichainorg/detailed-disclosure-of-multichain-security-policy-bde 0397 accf 5 。
5.Wormhole
Wormhole's Security Incident Response Policy focuses primarily on pre- and post-security incidents. Security measures before security incidents include security audits, enabling bug bounties, social media monitoring, setting heterogeneous monitoring policies, and rolling out Governor functions.
(1) Security audit. Wormhole also attaches great importance to security audits, and has cooperated with Certik, Coinspect, Hacken, Halborn, Kudelski, Neodyme, OtterSec, Trail of Bits, and Zellic in security audits. See detailshttps://medium.com/@wormholecrypto/wormhole-security-program-end-of-year-update-212116 ecfb 91 。
(2) Bug bounty. The Wormhole project also runs two bug bounty programs, the first with Immunefi starting February 11, 2022, with a maximum bounty program of $2.5 million. See detailshttps://immunefi.com/bounty/wormhole/. In addition, you can also browse relevant information and submit reports on its official website. See https://wormhole.com/bounty/ for details. In addition Wormhole provides the use ofWormhole's list of strategies, which can lower the threshold for white hat hackers to find security holes in Wormhole.
(3) Social media monitoring. Wormhole maintains a social media monitoring program so that the Wormhole project is notified of vulnerabilities in dependencies that could negatively impact Wormhole, its users, or the chains Wormhole is connected to.
(4) Set heterogeneous monitoring strategy. Wormhole sets up heterogeneous monitoring policies in Guardian, increasing the likelihood of detecting fraudulent activity. Wormhole expects all Guardians to develop and maintain their own security monitoring strategy.
(5) Introduce the Governor function. The core reason for creating and deploying this feature is to help protect against the existential risk of smart contract or L1 compromise. This feature allows Wormhole Guardians with the optional ability to rate limit the flow of nominal value of any registered asset on a per-chain basis.
The security measures of Wormhole in the event of a security incident are unclear, but the Wormhole attack in February 2022 was a vulnerability identified by Wormhole network contributors who noticed a discrepancy in outstanding funds during routine checks and immediately launched an investigation.
Security measures after a security incident include establishing an incident response mechanism and emergency suspension.
(1) Incident response mechanism. Wormhole maintains an incident response program in response to vulnerabilities or active threats to Wormhole, its users, or its connected ecosystem.
(2) Emergency timeout. The Wormhole project evaluates concepts with safety features that allow Wormhole smart contracts to be suspended during existential crisis states without contract upgrades.
image description

first level title
3. Exploration of more trustless solutions
At present, the verification methods in the cross-chain market can be divided into three types, namely native verification, local verification and external verification. These three types of verification methods have their own limitations, and it is difficult to balance trustlessness, scalability, and versatility.
The external verification scheme is a very versatile and scalable cross-chain computing scheme that can support more complex cross-chain applications. The Axelar, Celer Network, Layerzero, Multichain, and Wormhole mentioned in this article all belong to the category of external verifiers. They can complete the verification under the chain, have high scalability, can cover blockchains with different technical architectures, and can Realize general message cross-chain. However, since users must trust the relay network composed of a group of external nodes, its security is weaker than trustless local authentication and native authentication schemes.
The safest cross-chain bridge design should minimize trust. However, the native verification schemes currently on the market, such as Hop and Connext, have poor versatility and are not suitable for general message cross-chains. Native verification schemes such as Cosmos IBC and Polkadot XCMP have weak scalability and are more suitable for isomorphic blockchains. , it is difficult to be compatible with many heterogeneous chains such as Ethereum and Solana.
ZKP technology brings a new path for secure cross-chain communication. ZKP cross-chain operation has the advantages of trustlessness, strong versatility, and low cost. Compared with the current cross-chain solution that achieves cross-chain communication by trusting a third party, ZKP cross-chain does not introduce any trust assumptions. Users only need to trust the source chain consensus and target chain consensus, which belongs to the category of native verification schemes. Moreover, ZKP reduces the need for Gas fees by generating concise ZKP proofs, so that the target chain can efficiently verify the target chain transactions, and the verification cost on the chain is reduced.
image description

Figure 7 ZKP cross-chain new layout
In addition, through the information disclosed by Axelar, Celer, Layerzero, Multichain, and Wormhole, and combing their response policies to security incidents, the following problems can be found.
(1) Innovative solutions are very scarce. Multichain sets up a security fund to compensate users for any potential losses caused by multichain system and service vulnerabilities. This kind of security solution with a bottom-up nature is still rare in the industry.
(2) Not every cross-chain project covers security policies before, during, and after. Among the five projects selected in this article, only Multichain has a clear security policy before and after.
(3) The safety guarantee mechanism is not yet perfect. Opening bug bounties and conducting security audits are common operations before security incidents. However, cross-chain projects lack a comprehensive and comprehensive security response solution and security mechanism. Relevant security measures are often put forward after a security incident occurs, and there is no complete security standard and crisis response process in advance. For example, Wormhole and Multichain cooperated with Immunefi to start the bug bounty program after the security incident occurred.
Original link
references:
https://axelar.network/blog/an-introduction-to-the-axelar-network
https://axelar.network/blog/security-at-axelar-core
https://docs.axelar.dev/learn/security
https://celer.network/technology#top
https://twitter.com/CelerNetworkcn/status/1560911682339508224
https://mp.weixin.qq.com/s/SInU_o3Ct-7A6pFbKLqzHQ
https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/
https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf
https://drive.google.com/file/d/1NFFFecAjStbGMyvJVDez3xmsGSHYvNYv/view
https://medium.com/multichainorg/detailed-disclosure-of-multichain-security-policy-bde0397accf5
https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8
https://drive.google.com/file/d/1ibuHChcYcYCN6JelRAQPnM4rkaB9EgAM/view
https://github.com/wormhole-foundation/wormhole/blob/dev.v2/SECURITY.md#3 rd-party-security-audits
https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6
https://medium.com/@wormholecrypto/wormhole-security-program-end-of-year-update-212116ecfb91


