By Kang Shuiyue, founder of Fox Tech and Way Network and chairman of Danyang Investment
Adam Back (Bitcoin core development team leader, BlockStream CEO) has a sentence that impressed me, “Great design looks very simple, but the process of designing it is extremely complicated”. But not all product designs that look simple, like LayerZero, are great.
Everyone thinks it’s safe until the cross-chain protocol goes down, but when it does, it’s a big, scary thing. Security incidents on cross-chain protocols topped the list in terms of the amount of money lost to security incidents that occurred on each chain over the past two years. The importance and urgency of solving cross-chain protocol security issues is even greater than Ethereum scaling. Interoperability between cross-chain protocols is an inherent requirement of Web3 connectivity. The amount of financing for such agreements is often huge, and the number of TVLS and deals is growing, driven by rigid demand. However, due to the low recognition degree of the public, the security level of these cross-chain protocols cannot be recognized.
Let’s start with a product design architecture. The communication process between Chain A and Chain B is carried out by Relayer, and Oracle supervises Relayer. First of all, this architecture has the advantage of avoiding the traditional communication between ChainA and ChainB by the third chain (generally not deployed dApp in this chain) to complete the consensus algorithm and dozens of nodes verification, so it can bring “fast cross-chain” user experience to end users. Because the architecture is light, the code is minimal, and Oracle has a Chainlink, this type of project is easy to launch, but also easy to imitate, and the technical threshold is Zero.
There are at least two problems with the above architecture:
1. LayerZero reduces the verification of dozens of nodes to a single Oracle verification, which naturally greatly reduces the security factor.
2. After simplification into a single verification, it is necessary to assume that Relayer and Oracle are independent. However, this trust hypothesis cannot be established forever and is not Crypto Native enough to fundamentally guarantee that the two cannot conspire to do evil.
This is the basic pattern that LayerZero adopts. As an “ultralights” cross-chain solution of a separate security type, it is only responsible for transferring messages and is not responsible for the security of the application, nor is it capable of being responsible.
How about freeing Relayer so that everyone can run the repeater? Figure 2 enlarges the number of figures in Figure 1. First of all, Decentralized does not mean a decentralized number of operators so that everyone can join. It is called Permissionless. The demand side has always been Permissionless, and the supply side also Permissionless is not an epoch-making change. It is a change on the market side, which has nothing to do with the security of the product itself. LayerZero’s Relayer was simply an intermediary responsible for forwarding information, essentially a Trusted Third Party like Oracle. Trying to improve cross-chain security by increasing the number of trusted principals from 1 to 30 is a fool’s errand. Instead of changing product features, new problems will be created.
If a cross-chain token project allows the configured LayerZero node to be modified, it could be replaced with its own “Layerzero” node by an attacker, thus forging arbitrary messages. As a result, projects using Layerzero still have a huge security problem, which is worse in more complex scenarios. The replacement of just one link in a large system can cause a chain reaction. LayerZero doesn’t have the potential to solve this problem on its own. If a security incident does occur, LayerZero will naturally pass the buck to an external application. Because end users need to carefully judge the security of each LayerZero project, those “user-oriented” projects will carefully access LayerZero to avoid being polluted by malicious applications that belong to the same ecosystem, which makes it difficult to build an ecosystem.
If Layer0 can’t share security like Layer1 or Layer2, then Layer0 can’t be called Infrastructure, because infrastructure is “basic” because it can share security. If a project party calls itself Infrastructure, it should provide consistent security for all of its ecological projects like any other infrastructure, that is, all ecological projects share the security of the infrastructure. So LayerZero isn’t exactly Infrastructure, it’s Middleware. App developers who access the Middleware SDK/API do have the freedom to define their security policies.
The L2BEAT team wrote on January 5, 2023, Circumventing Layer Zero: Why Isolated Security is No Security, arguing that their assumption that app owners (or people with private keys) can’t do evil is incorrect. Bad guy Bob gains access to the LayerZero configuration. Bad guy Bob can change the seer and repeater from default components to components he controls, convincing the LayerZero smart contract on Ethereum to let him withdraw all of the good guy Alice’s tokens on Ethereum. The original link: https://medium.com/l2beat/circumventing-layer-zero-5e9f652a5d3e
The Nomad team posted on January 31, 2023, that the LayerZero repeater has two critical vulnerabilities that are currently in a two-party, multiple-signed state, so they can only be exploited by insiders or team members with known identities. The first allows a fraudulent message to be sent from LayerZero with multiple signatures, and the second allows a message to be modified after the prophecy machine and multiple signatures have signed the message or transaction, both resulting in the theft of all user funds. The original link: https://prestwich.substack.com/p/zero-validation
When confused by fancy watches, try to go back to your roots.
On October 31, 2008, the Bitcoin White Paper appeared. On January 3, 2009, BTC Genesis block was born. An excerpt from the white paper, 《Bitcoin: A Peer-to-Peer Electronic Money System》:
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.