The Importance of Cross-Chain Protocol Security and the Limitations of LayerZero

The security issues of cross-chain protocols have received significant attention in recent years. Based on the losses caused by security incidents on various blockchains over the past two years, the losses related to cross-chain protocol security incidents rank highest. The importance and urgency of resolving security issues in cross-chain protocols even surpasses that of Ethereum's scalability solutions. The interoperability between cross-chain protocols is an inherent requirement for connecting the Web3 ecosystem into a network. Such protocols often receive substantial financing, and their total locked value (TVL) and transaction volume are also increasing under the impetus of rigid demand. However, due to the general public's low recognition of these protocols, it is difficult to accurately assess their security levels.

Let’s first look at a typical cross-chain product design architecture. In the communication process between Chain A and Chain B, specific operations are executed by the Relayer, while the Oracle supervises the Relayer. The advantage of this architecture is that it avoids the complex process of needing a third chain (usually not deploying dApp) to complete the consensus algorithm and multiple node validations, thus providing end users with a "fast cross-chain" experience. Due to the lightweight architecture, small amount of code, and the ability to directly use existing Chainlink as the Oracle, this type of project can be quickly launched but is also easily imitated, with almost zero technical barriers.

However, this architecture has at least two issues:

1. The verification process of dozens of nodes has been simplified to a single Oracle verification, significantly reducing the security factor.

2. After simplifying to a single verification, it must be assumed that the Relayer and Oracle are independent of each other. This trust assumption is difficult to maintain permanently, does not align with the native philosophy of cryptocurrency, and cannot fundamentally guarantee that the two will not collude to do harm.

Some cross-chain protocols have adopted this basic model. As an "ultra-lightweight" cross-chain solution of independent security type, they are only responsible for transmitting messages and do not bear responsibility for the security of applications, nor do they have the capacity to assume such responsibility.

Even allowing multiple parties to run relayers cannot fundamentally solve the above problems. Firstly, decentralization does not merely mean an increase in the number of operators or that anyone can connect. The demand side has always been permissionless; making the supply side permissionless is not a revolutionary change; it is merely a change in the market, which is largely unrelated to the safety of the product itself. The Relayers of certain protocols are essentially just intermediaries responsible for forwarding information, similar to Oracles, and are considered trusted third parties. Attempting to improve cross-chain security by increasing the number of trusted entities from 1 to 30 is futile, as it does not change the product characteristics and may even lead to new problems.

If a cross-chain token project allows the modification of configuration nodes, it may be possible for attackers to replace them with their own nodes, thereby forging any messages. As a result, projects using this protocol may still face significant security risks, and this issue could become even more serious in more complex scenarios. In a large system, as long as one link is replaced, it could trigger a chain reaction. Some cross-chain protocols themselves do not have the capability to address this problem, and if a security incident does occur, they are likely to shift the responsibility to external applications.

If a protocol cannot share security like Layer 1 or Layer 2, it cannot be called infrastructure. The reason infrastructure is considered "fundamental" is that it can share security. If a project claims to be infrastructure, it should provide consistent security for all its ecosystem projects like other infrastructures do, meaning all ecosystem projects share the security of that infrastructure. Therefore, to be precise, some cross-chain protocols are not infrastructure but middleware. Application developers who access this middleware SDK/API can indeed freely define their security policies.

Some research teams have pointed out that it is incorrect to assume that application owners (or those who hold the private keys) will not act maliciously. If a malicious actor gains access to the configuration of the cross-chain protocol, they may change the oracles and relayers from default components to components they control, thereby manipulating the smart contracts that use this mechanism, resulting in the theft of user assets.

In addition, studies have shown that certain cross-chain protocols have critical vulnerabilities in their relayers. Although currently in a multi-signature state, these vulnerabilities can only be exploited by insiders or team members with known identities, but there remains a potential risk. These vulnerabilities may allow fraudulent messages to be sent from multi-signatures, or modify messages after oracles and multi-signatures sign messages or transactions, which could lead to the theft of all users' funds.

Tracing back to the origins of Bitcoin, we can see the core concept proposed by Satoshi Nakamoto in the white paper: a completely peer-to-peer electronic cash system that allows online payments to be sent directly from one party to another without going through a financial institution. This concept emphasizes the characteristics of decentralization and trustlessness, which has also become the shared goal of all subsequent infrastructure developers.

However, certain cross-chain protocols require that the roles of Relayer and Oracle do not collude to commit malicious acts during actual operation, while also requiring that users view developers who build applications using the protocol as trustworthy third parties. The trusted entities involved in "multi-signature" are all pre-arranged privileged roles. More importantly, no fraud proofs or validity proofs are generated throughout the cross-chain process, let alone putting these proofs on-chain and conducting on-chain verification. Therefore, these protocols do not actually meet the "Satoshi consensus" and cannot be called truly decentralized and trustless systems.

When facing security issues, the response of some cross-chain protocols is often "deny" and then "deny" again. However, history tells us that many electronic currencies attempted before Bitcoin have failed because they did not achieve the goals of decentralization, attack resistance, and inherent value. The same applies to cross-chain protocols; regardless of the scale of financing, the number of users, or how "pure" the lineage is, as long as the product cannot achieve true decentralized security, it is highly likely to fail due to insufficient attack resistance.

Building a truly decentralized cross-chain protocol is a complex challenge. Some emerging solutions, such as using zero-knowledge proof technology to upgrade cross-chain protocols, may bring new breakthroughs to this field. However, the key lies in whether the protocol developers recognize their own issues and are willing to take the necessary measures to improve.