Author: Kang Shuiyue, Founder of Fox Tech and Way Network, Chairman of Danyang Investment
Adam Back (leader of the Bitcoin core development team, BlockStream CEO) said something that impressed me: "Great designs look very simple, but the process of designing them is actually extremely complex." However, not all seemingly simple product designs can be called great, such as LayerZero.
Before cross-chain protocols go wrong, everyone thinks they are safe and there is no problem, but once something goes wrong, it is a big shock. Judging from the amount of losses caused by security incidents on various chains in the past two years, the losses caused by security incidents on cross-chain protocols rank first. The importance and urgency of solving cross-chain protocol security issues even exceed the Ethereum expansion plan. Interoperability between cross-chain protocols is an inherent requirement for Web3 to be connected. Such protocols often raise huge amounts of funds, and TVL and the number of transactions are also growing under the rigid demand. However, due to the low recognition of the public, it is impossible to identify the security level of these cross-chain protocols.
Let's first look at a product design architecture. The communication process between Chain A and Chain B is performed by Relayer, and Oracle supervises Relayer. First of all, this architecture has an advantage that it eliminates the traditional communication between ChainA and ChainB, which is completed by a third chain (usually dApp is not deployed on this chain) to complete the consensus algorithm and dozens of node verifications, so it can bring a "fast cross-chain" user experience to end users. Because the architecture is light, the amount of code is small, and Oracle has a ready-made Chainlink, this type of project is easy to launch, but it is also easy to be imitated, and the technical threshold can be said to be zero.
Figure 1: Basic version of pseudo-decentralized cross-chain protocol
There are at least two problems with the above architecture:
LayerZero reduces dozens of node verifications to a single Oracle verification, which greatly reduces the security factor.
After simplifying to a single verification, it must be assumed that the Relayer and Oracle are independent. This trust assumption cannot be established forever, is not Crypto Native enough, and cannot fundamentally guarantee that the two cannot collude to do evil.
This is the basic model adopted by LayerZero. As an independent security type of "ultra-light" cross-chain solution, it is only responsible for transferring messages and is not responsible for the security of the application, nor is it capable of being responsible.
If we release the Relayer and allow everyone to run the relayer, can the above problems be solved? Figure 2 shows that the number in Figure 1 has increased. First of all, Decentralized does not mean that the number of operators has increased. Anyone can access it, which is called Permissionless. The demand side has always been Permissionless. Letting the supply side also be Permissionless is not an epoch-making change. This is a change on the market side and has nothing to do with the security of the product itself. LayerZero's Relayer is just an intermediary responsible for forwarding information. In essence, it is the same as Oracle, both are Trusted Third Parties. Trying to improve cross-chain security by increasing the number of trusted entities from 1 to 30 is futile. Not only does it not change the product characteristics, but it will also bring new problems.
Figure 2: Advanced version of the pseudo-decentralized cross-chain protocol
If a cross-chain token project allows modification of the configured LayerZero node, it is possible that it can be replaced by an attacker's own "Layerzero" node, thereby forging arbitrary messages. As a result, projects using Layerzero still have huge security issues, and this problem will be more serious in more complex scenarios. In a huge system, as long as one link is replaced, it may cause a chain reaction. LayerZero itself does not have the ability to solve this problem. If a security incident really occurs, LayerZero will naturally push the responsibility to external applications. Because end users need to carefully judge the security of each project using LayerZero, those "user-oriented" projects will carefully connect to LayerZero to avoid being contaminated by malicious applications belonging to the same ecosystem, which makes it difficult to build an ecosystem.
If Layer0 cannot share security like Layer1 and Layer2, then this Layer0 cannot be called Infrastructure, because the reason why infrastructure is "basic" is that it can share security. If a project claims to be Infrastructure, it should provide consistent security for all its ecological projects like other infrastructures, that is, all ecological projects share the security of the infrastructure. So, to be precise, LayerZero is not an infrastructure, but a middleware. Application developers who access this Middleware SDK/API can indeed freely define their security policies.
The L2BEAT team published an article on January 5, 2023 titled Circumventing Layer Zero: Why Isolated Security is No Security, pointing out that their assumption that the application owner (or the person with the private key) would not do evil is incorrect. The bad guy Bob gained access to the LayerZero configuration. The bad guy Bob can change the oracle and relayer from the default components to the components controlled by him, and convince the smart contract using the LayerZero mechanism on Ethereum to let him withdraw all the tokens of the good guy Alice on Ethereum. Original link: The Nomad team published an article on January 31, 2023, pointing out that there are two critical vulnerabilities in the LayerZero relayer, which is currently in a two-party multi-signature state, so these vulnerabilities can only be exploited by insiders or team members with known identities. The first vulnerability allows fraudulent messages to be sent from LayerZero multi-signatures, and the second vulnerability allows messages to be modified after the oracle and multi-signature sign the message or transaction, both of which can lead to the theft of all user funds.
When you are confused by fancy appearances, try to trace back to the origin.
2008 年10 月31 日，比特币白皮书问世。 2009 年1 月3 日，BTC 创世区块诞生。《比特币：一种点对点电子货币系统》白皮书里的摘要如下：Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.摘要中文翻译如下：一种完全的点对点电子货币应当允许在线支付从一方直接发送到另一方 而不需要通过一个金融机构。数字签名提供了部分解决方案，但如果仍需一个 可信任第三方来防止双重支付，那就失去了电子货币的主要优点。我们提出一 种使用点对点网络解决双重支付问题的方案。该网络通过将交易“哈希”（动词）进一条持续增长的基于哈希的工作量证明链来给交易打上时间戳，形成一条除非重做工 作量证明否则不能更改的记录。最长的链不仅是被见证事件序列的证据，而且也是它本身是由最大 CPU 算力池产生的证据。As long as the majority of CPU power is controlled by nodes that are not trying to coordinate an attack on the network, these nodes will generate the longest chain and outpace attackers. The network itself requires minimal architecture. Information will be broadcast as best it can, and nodes can leave and rejoin the network at any time, simply accepting the longest proof-of-work chain as evidence of what happened while they were away.
From this paper, which was of great significance to later generations, people extracted the widely known "Nakamoto Consensus" from this abstract, whose core feature is to eliminate the emergence of A Trusted Third Party and achieve Trustless and Decentralized. The "center" here is A Trusted Third Party. The cross-chain communication protocol is essentially the same as Bitcoin, which is a Peer to Peer system. One party sends directly from Chain A to the other party on Chain B without going through any trusted party.
The "Nakamoto Consensus" with decentralized and trustless features has become the common goal pursued by all infrastructure developers. It can be said that cross-chain protocols that do not meet the "Nakamoto Consensus" are fake decentralized cross-chain protocols, and cannot use advanced words such as decentralized and trustless to describe their product features. LayerZero introduces itself as Omnichain communication, interoperability, decentralized infrastructure. LayerZero is an omnichain interoperability protocol designed for lightweight message passing across chains. LayerZero provides authentic and guaranteed message delivery with configurable trustlessness.
In fact, LayerZero requires that the two roles of Relayer and Oracle will not collude to do evil, and requires users to trust developers who use LayerZero to build applications as a reliable third party, and the trusted subjects participating in the "multi-signature" are all pre-arranged privileged roles; at the same time, no fraud proof or validity proof is generated during the entire cross-chain process, let alone putting these proofs on the chain and verifying them on the chain. Therefore, LayerZero does not meet the "Nakamoto Consensus" at all, and is not Decentralized and Trustless at all.
After the L2BEAT team and the Nomad team published a well-intentioned article from the perspective of the problem discoverer, LayerZero responded with "denial" and "denial". There were many electronic currencies before Bitcoin, but they all failed. Because they failed to achieve the goals of decentralization, anti-attack and intrinsic value. The same is true for cross-chain protocols. No matter how much financing, how much traffic, and how "pure bloodline", as long as the product cannot achieve Real Decentralized Security, it is likely to end due to insufficient resilience against attacks.
A friend whose stance should have been highly consistent with LayerZero once asked me a question: "If LayerZero wants to use zero-knowledge proof to upgrade their cross-chain protocol like Way Network, will it be difficult and what obstacles will there be?" This is an interesting question, and the key to the problem is that they don't think they have any problems.
As for how to build a truly decentralized cross-chain protocol, you can refer to my previous article "Why use zero-knowledge proof to develop cross-chain protocols?"