原文标题：《Circumventing Layer Zero: Why Isolated Security is No Security》
Written by Krzysztof Urbański, L2BEAT team member
Compiled by Babywhale, Foresight News
Since its inception, L2BEAT has invested a lot of energy in analyzing and understanding the risks associated with Layer 2 protocols. We always act in the best interests of our users and the ecosystem, and do our best to be an impartial, independent overseer, and not let our personal preferences for projects or related teams influence the facts. This is why even though we respect the time and effort that project teams put into their projects, we will "sound the alarm" or point out our concerns about potential risks in certain protocols. Having security-related discussions early on can allow the entire ecosystem to be better prepared for potential risks and respond earlier to any suspicious behavior.
Today we would like to discuss the shared security model for cross-chain applications. There are currently two security models: shared security and independent application security. Shared security is like all Rollups. Independent application security is mainly used by "omnichain" projects, and the main use of such projects is LayerZero.
Shared security vs. independent security
Shared security means that specific tokens or applications running on a given infrastructure, rather than being free to choose a security model, must abide by whatever security requirements the infrastructure imposes. For example, Optimistic Rollups typically impose a 7-day finality window - an application running on such Rollups cannot simply ignore or shorten this deadline. While this may seem like a hindrance, it is there for a reason. This deadline provides users with a security guarantee that no matter what the application's internal security policy is, it must abide by this set of security policies, and applications may only strengthen the security of the Rollup, not weaken it.
Independent security means that each application is responsible for defining its security, and is not constrained in any way by the infrastructure. This may seem like a good idea at first glance, after all, the application developer knows best what security measures the application may need. But at the same time, it shifts the responsibility of evaluating the risks associated with each application's security policy to the end user. In addition, if application developers are free to choose their security policies, they can also change them at any time. Therefore, it is not enough to evaluate the risks of each application once, and the application should be evaluated every time its policy changes.
Problems
We believe that an independent security model where each application is free to define its own security policy poses serious security problems. First, it increases the risk to end users because they must verify the risk of each application they intend to use.
Independent security also increases the risk of applications using this model, such as adding additional risks regarding security policy changes - if an attacker were to change the security model of the application, they might as well simply disable it, draining away funds or attacking in any other way. There is no additional security layer on top of the application to prevent attacks.
Additionally, because security policies can change at any time and on the fly, it is nearly impossible to monitor applications in real time and inform users of risks.
We find it similar to smart contract upgradeability, which we have warned about on L2BEAT. We inform users of Rollups and cross-chain bridges that have upgradeability mechanisms in their smart contracts, and the exact mechanisms that manage upgradeability in each case. This is already quite complex, and using independent security models multiplies the number and is almost impossible to track effectively.
This is why we believe that a separate security model is itself a security risk, and we assume that every app that will use such a model by default should be considered risky until proven otherwise.
Prove that a security vulnerability exists
We decided to test our hypothesis on mainnet. The LayerZero framework was chosen for the experiment because it is one of the most popular solutions with independent security at its core. We deployed a secure omnichain token and later updated the security configuration to allow malicious token extraction. The token's code is based on the examples provided by LayerZero and is very similar or identical to many other omnichain tokens and applications deployed in the wild.
But before we dive into the details, let’s take a brief look at what the LayerZero security model looks like.
As LayerZero points out in its white paper, its “trustless interchain communication” relies on two independent participants (oracle and relayer) acting together to ensure the security of the protocol.
LayerZero states on its website that its core concept is “a user application running ULN (UltraLightNode) with a configurable on-chain terminal.” LayerZero’s on-chain component relies on two external off-chain components to relay messages between chains — oracles and relayers.
Whenever any message M is sent from chain A to chain B, the following two operations occur:
First, the oracle waits until the transaction sending message M on chain A is completed, and then writes relevant information on chain B, such as the hash of the block header of chain A that contains message M (the exact format may vary between different chains/oracles).
The relayer then sends a "proof" (such as a Merkle Proof) to chain B, proving that the stored block header contains message M.
LayerZero assumes that relayers and oracles are independent, honest participants. However, LayerZero also stated in the white paper that if this assumption is not met, for example, the relayer and oracle collude, resulting in "both the block header provided by the oracle and the transaction proof provided by the relayer are invalid, but still match."
LayerZero claims that "LayerZero's design eliminates the possibility of collusion." In fact, this claim is incorrect (as we demonstrate in the experiments shown below) because each user application can define its own relayer and oracle. LayerZero does not guarantee by design that these components are independent and cannot collude, but rather it is up to the user application to provide these guarantees. If the application chooses to subvert them, LayerZero has no mechanism to prevent it.
Furthermore, by default, all user applications can change relayers and oracles at any time, completely redefining security assumptions. Therefore, it is not enough to check the security of a given application once, as it may change at any time after the check, as we will show in our experiments.
experimental design
For our experiments, we decided to create a simple omnichain token, CarpetMoon, running on both Ethereum and Optimism, and using LayerZero to communicate between the two chains.
Our token will initially use the default security model provided by LayerZero, making it identical to most (though not all) currently deployed LayerZero applications. As such, it will generally be as secure as any other token using LayerZero.
First, we deploy our token contract on Ethereum and Optimism:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221
We then set up routing so that LayerZero knows which contract corresponds to which contract on both chains.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c
The token is deployed and it looks exactly like all other omnichain tokens using LayerZero, with default configurations, nothing fishy.
We provided 1 billion CarpetMoon tokens on Ethereum to our “test user” Alice.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
Now Alice uses LayerZero to cross-chain these tokens to Optimism.
We lock the tokens in an escrow contract on Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
The message containing the transaction is being passed to Optimism via LayerZero:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7nonced10d/。
Cross-chain tokens are being minted on Optimism, and Alice now owns 1 billion MoonCarpet tokens on Optimism:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302。
Everything goes as expected, Alice crosses the tokens and sees that there are 1 billion MoonCarpet tokens in the escrow contract on Ethereum and 1 billion MoonCarpet tokens in her account at Optimism. But to make sure everything is working, she transfers half of the tokens back to Ethereum.
We start with the transaction on Optimism that destroyed 500 million tokens:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f。
Information about the transaction is passed to Ethereum:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1。
As expected, 500 million MoonCarpet tokens are returned from the escrow contract to Alice’s address:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
So far, everything works fine and exactly as assumed. Alice has checked that she can cross-chain tokens from Ethereum to Optimism and back again, and she has no reason to worry about her MoonCarpet tokens.
But let’s assume that there is a problem — for example, the team behind our token has a problem and bad guy Bob gains access to the LayerZero configuration of our application.
This way, Bob can change the oracle and relayer from the default components to components controlled by him.
It is important to note that this is a mechanism provided for every application using LayerZero and is built into LayerZero's architecture. It is not a backdoor of any kind, but rather a standard mechanism.
So Bob changes the oracle to an EOA under his control:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
Repeaters have also been changed:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
Now something strange happens. Since the oracles and relayers are now under Bob’s full control, he is able to steal Alice’s tokens. Even though no action was taken on Optimism (MoonCarpet tokens are still in Alice’s wallet), Bob is able to convince the MoonCarpet smart contract on Ethereum (using the LayerZero mechanism) that he destroyed the tokens on the other chain and he is able to withdraw the MoonCarpet tokens on Ethereum.
First, he updates Ethereum’s block hash using an oracle he controls:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
Now he can withdraw the remaining tokens from the escrow contract:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
Experimental Results
Alice doesn’t even know why and when the error occurred. All of a sudden, her MoonCarpet tokens on Optimism are no longer backed by tokens on Ethereum.
The smart contract is not upgradeable and works as expected. The only suspicious activity is the change of oracles and relayers, but this is a regular mechanism built into LayerZero, so Alice doesn’t even know if the change was intentional. Even if Alice knew about the change, it would be too late - the attacker could drain the funds before she could react.
There is nothing LayerZero can do about this - these are effectively implementations of their mechanisms, which they have no control over. In theory, applications themselves could prevent themselves from changing oracles and relayers, but to our knowledge, no deployed applications have done so.
We did this experiment to test if anyone noticed it, but as we expected, no one noticed. It is nearly impossible to effectively monitor all applications built with LayerZero to check if their security policies have changed and alert users when this happens.
Even if someone is able to discover in time that the oracle and relayer have changed and introduced security risks, it is too late. Since the new oracle and relayer can now freely choose the messages delivered or simply disable interchain communication, there is usually nothing users can do about it. Our experiments clearly show that even if Alice notices the change in the application configuration, she cannot do much with her cross-chain tokens - the new oracle and relayer are no longer accepting messages on the original communication chain, so they will not send messages back to Ethereum.
in conclusion
As we can see, even though our token was built with LayerZero and used its mechanisms as intended, we were able to steal funds from the token’s custody. Of course, this is a bug in the application (in our case, the CarpetMoon token) and not in LayerZero itself, but it proves that LayerZero itself does not provide any security guarantees.
When LayerZero describes their security model for oracles and relayers, they assume that the application owner (or whoever holds the private key) will not do anything unreasonable. But in an adversarial environment, this assumption is incorrect. Furthermore, it requires users to trust the application developer as a trusted third party.
So in practice, one cannot make any assumptions about the security of applications built with LayerZero - every application should be considered risky until proven otherwise.
Actually, the whole story started with our plan to include a PR for all omnichain tokens on the L2BEAT website — we had a hard time figuring out how to assess their risk. While analyzing the risk, we came up with the idea of an experiment.
If we go live on L2BEAT, the consequence is that we have to put alerts on top of every application built with LayerZero to warn of possible security risks. But we want to start a broader discussion about security models because we believe that standalone security is a model that should be avoided, especially in our field.
We believe that as independent security models like LayerZero become more popular, more and more projects will abuse them, causing massive damage and increasing uncertainty across the industry.