How to build a "fake" decentralized cross-chain protocol?
Not all seemingly simple product designs can be called great, such as LayerZero.Author: Kang Shuaiyue, Founder of Fox Tech and Way Network, Chairman of Danyang Investment
Adam Back (leader of the Bitcoin Core development team, CEO of BlockStream) once 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 considered great, such as LayerZero.
Before incidents occurred, everyone felt that cross-chain protocols were very secure and had no issues, but once something went wrong, it became a shocking event. Based on the losses caused by security incidents on various chains over the past two years, the losses from security incidents on cross-chain protocols rank at the top. The importance and urgency of solving security issues in cross-chain protocols even surpass the Ethereum scaling solutions. The interoperability between cross-chain protocols is an inherent requirement for Web3 to connect into a network. Such protocols often raise huge amounts of funding, and their TVL and transaction numbers are increasingly growing under demand-driven conditions. However, due to the low public recognition, it is difficult to identify the security levels of these cross-chain protocols.
Let's first look at a product design architecture. The communication process between Chain A and Chain B is executed by a Relayer, supervised by an Oracle. The advantage of this architecture is that it eliminates the need for a third chain (usually not deploying dApps on this chain) to complete the consensus algorithm and verification by dozens of nodes, thus providing end users with a "fast cross-chain" user experience. Because the architecture is lightweight and has less code, and since Oracle has a ready-made Chainlink, this type of project can easily go live but can also be easily imitated, making the technical threshold virtually Zero.
Figure 1: Pseudo-decentralized basic version of cross-chain protocol
The above architecture has at least two problems:
- LayerZero reduces dozens of node verifications to a single Oracle verification, significantly lowering the security level.
- After simplifying to a single verification, it must assume that the Relayer and Oracle are independent, and this trust assumption cannot hold indefinitely; it is not sufficiently Crypto Native and cannot fundamentally guarantee that the two cannot collude to commit malicious acts.
This is the basic model adopted by LayerZero. As an independent security type of "ultra-light" cross-chain solution, it is only responsible for message transportation and does not bear responsibility for the security of applications, nor does it have the capability to do so.
So, if we open up the Relayer and allow everyone to run relayers, can this solve the above problems? Figure 2 shows an increase in the number from Figure 1. First, decentralized does not mean that the number of operators increases; anyone can connect, which is called Permissionless. The demand side has always been Permissionless; making the supply side Permissionless is not a revolutionary change; it is a market change and has little to do with the security of the product itself. LayerZero's Relayer is merely an intermediary responsible for forwarding information, essentially the same as an Oracle, both being Trusted Third Parties. Attempting to increase the number of trusted entities from one to thirty to enhance cross-chain security is futile; it not only does not change the product characteristics but also brings new problems.
Figure 2: Pseudo-decentralized advanced version of cross-chain protocol
If a cross-chain token project allows modification of the configuration of LayerZero nodes, it could potentially be replaced by an attacker with their own "LayerZero" node, thereby forging any message. As a result, projects using LayerZero would still face significant security issues, and these problems would be even more severe in more complex scenarios. In a large system, as long as one link is replaced, it could cause a chain reaction. LayerZero itself does not have the means to solve this problem; if a security incident occurs, LayerZero will naturally push the responsibility onto external applications. Since end users need to carefully assess the security of each project using LayerZero, those "user-oriented" projects will cautiously integrate LayerZero to avoid being contaminated by malicious applications within the same ecosystem, making ecosystem construction quite challenging.
If LayerZero cannot share security like Layer 1 or Layer 2, then it cannot be called Infrastructure, because the reason infrastructure is "fundamental" is that it can share security. If a project claims to be Infrastructure, it should provide consistent security for all its ecosystem projects, meaning all ecosystem projects share the security of that infrastructure. Therefore, to be precise, LayerZero is not Infrastructure; it is Middleware. Application developers connecting to 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 application owners (or those with private keys) would not act maliciously is incorrect. Bad actor Bob gained access to LayerZero configuration. Bad actor Bob could change the oracle and relayer from the default components to those controlled by him, convincing smart contracts using LayerZero on Ethereum to allow him to withdraw all tokens from good actor Alice on Ethereum. The original link: The Nomad team pointed out on January 31, 2023, that LayerZero relayers have two key vulnerabilities, currently in a two-party multi-signature state, so these vulnerabilities can only be exploited by internal personnel or known team members. 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 messages or transactions, both of which could lead to the theft of all user funds.
When confused by flashy appearances, try to trace back to the source.
On October 31, 2008, the Bitcoin white paper was published. On January 3, 2009, the BTC genesis block was born. The abstract of the white paper "Bitcoin: A Peer-to-Peer Electronic Cash System" is as follows:
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.
The Chinese translation of the abstract is as follows:
一种完全的点对点电子货币应当允许在线支付从一方直接发送到另一方而不需要通过一个金融机构。数字签名提供了部分解决方案，但如果仍需一个可信任第三方来防止双重支付，那就失去了电子货币的主要优点。我们提出一种使用点对点网络解决双重支付问题的方案。该网络通过将交易"哈希"（动词）进一条持续增长的基于哈希的工作量证明链来给交易打上时间戳，形成一条除非重做工作量证明否则不能更改的记录。最长的链不仅是被见证事件序列的证据，而且也是它本身是由最大 CPU 算力池产生的证据。只要多数的 CPU 算力被不打算联合攻击网络的节点控制，这些节点就将生成最长的链而超过攻击者。这种网络本身只需极简的架构。信息将被尽力广播，节点可以随时离开和重新加入网络，只需接受最长的工作量证明链作为它们离开时发生事件的证据。
From this pivotal paper, especially from this abstract, people have distilled what is widely recognized as "Satoshi Consensus," whose core characteristics are to eliminate the need for a Trusted Third Party, achieving trustlessness and decentralization. The cross-chain communication protocol, like Bitcoin, is essentially a Peer-to-Peer system, where one party sends directly from Chain A to another party on Chain B without going through any trusted party.
The decentralized and trustless characteristics of "Satoshi Consensus" have become the common goal pursued by all developers of infrastructure later on. It can be said that cross-chain protocols that do not meet the "Satoshi Consensus" are pseudo-decentralized cross-chain protocols and cannot use high-level terms like Decentralized and Trustless to describe their product characteristics. 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 both the Relayer and Oracle to not collude maliciously while also requiring users to trust developers building applications using LayerZero as trusted third parties, and the participants in the "multi-sign" are all pre-arranged privileged roles; meanwhile, throughout its entire cross-chain process, it has not produced any proof of fraud or validity, let alone put these proofs on-chain and perform on-chain verification. Therefore, LayerZero does not meet the "Satoshi Consensus" and is not Decentralized and Trustless at all.
After the L2BEAT team and Nomad team published goodwill articles from the perspective of problem discoverers, LayerZero's response was "deny" and "deny" again. There were many electronic currencies before Bitcoin, but they all failed. Because none of them achieved the goals of decentralization, attack resistance, and inherent value, the same goes for cross-chain protocols; no matter how much funding they raise, how much traffic they have, or how "pure" their lineage is, as long as the product cannot achieve Real Decentralized Security, it is highly likely to end due to insufficient attack resistance.
Once, a friend who should have maintained a high degree of consistency with LayerZero asked me a question: "If LayerZero wants to upgrade their cross-chain protocol using zero-knowledge proofs like Way Network, how difficult would it be, and what obstacles would there be?" This is an intriguing question, and the key to the question is that they do not believe they have a problem.
As for how to build a truly decentralized cross-chain protocol, you can refer to my previous article *《Why Use Zero-Knowledge Proofs to Develop Cross-Chain Protocols?》.
