L2BEAT vs. LayerZero: The Debate
L2BEAT vs. LayerZero: The Debate
Shared Security or Isolated Security? What is better for Cross-Chain Apps?
Welcome to LI.FI’s Cross Chain Insider newsletter. If you want to join this community of cross-chain aficionados learning about bridges, interoperability, and the multi-chain ecosystem, subscribe below:
You can also check out LI.FI’s research articles, and follow us on Twitter!
In Crypto, it’s essential and healthy for the ecosystem to debate critical topics related to security and protocol development. This week, L2BEAT’s research team kick-started a heated discussion on isolated security and how it can be misused by dApp developers by taking LayerZero’s architecture as an example.
The topic of the Debate: shared security models of cross-chain applications (shared security vs. per-application security).
Let's look at this from both L2BEAT’s and LayerZero’s perspectives and try to conclude:
L2BEAT’s Argument: Shared security > Isolated security
According to L2BEAT, the isolated security model creates more problems than it solves. By enabling each app to define its unique security policies, we’re expanding the attack surface given:
dApp developers can adopt sub-par security policies that expose users to exploits.
dApp developers can change the security model anytime and rug the users.
It becomes the users' responsibility to ensure either 1) the dApp conforms to the security parameters set by the underlying layer (in this case, LayerZero), and if it doesn’t, then 2) access the security of the dApp given its unique security policies.
Thus, L2BEAT believes that every dApp using isolated security should be considered “risky by default until proven otherwise.” In this case, the argument is specific to dApps built on LayerZero, suggesting that all dApps built on LayerZero (like Stargate) should be considered risky since the developers behind these dApps can freely change the security model and potentially rug users.
L2BEAT also conducts a comprehensive experiment to prove that such a scenario is, in fact, possible for dApps built on LayerZero.
LayerZero’s Counter-Argument: We don’t want to pick a side; we offer both, let the devs decide.
As it should be, LayerZero had their own opinion on this discussion, shared via a thread and Bryan’s responses to questions on numerous threads. LayerZero doesn’t deny that such a scenario is possible for dApps built on top of LayerZero; however, the way they think about having standards when it comes to setting security parameters is different:
Like the internet can be used for building websites, Ethereum can be used to build smart contract applications, LayerZero is just an enabler to build cross-chain applications. Along the same lines, just like people can build malicious websites on the internet and malicious applications on Ethereum, it is possible for someone to build a malicious cross-chain application on LayerZero.
Being an infrastructure protocol, LayerZero makes it possible for devs to create applications with any type of security parameters and wants to stay completely unopinionated on application security configurations.
Shared security mechanism in a cross-chain ecosystem can potentially be attractive honey pots for attackers (as we’ve seen with >$2 lost in bridge hacks in 2022).
Thus, LayerZero believes that instead of choosing between shared vs. isolated security mechanism, it’s better to offer flexibility in terms of being able to set security parameters is vital for dApps as different use cases have different requirements. For instance, a money market dealing in 8-9 figure liquidations prices security differently than an NFT project dealing in $0.10 NFTs, and thus would require different security parameters that fit their requirements.
What Does Twitter Say?
Twitter, as always, has a voice of its own, and often the consensus on Twitter (sometimes wrongly) is taken as the final decision for a debate. For this argument, Twitter is heavily favored towards a shared security model. Even then, let's look at some of the different perspectives on Twitter:
Camp 1: say no to isolated security — Letting dApp developers determine security parameters can be irresponsible as most devs don’t want to be involved in this decision and simply want to build on top of a secure and robust infrastructure. Rollups are a good example of a shared security model where everyone that’s building a Rollup or on it embraces the shared security of Ethereum as the L1.
Camp 2: isolated security is useful — However, the counter-argument to this sentiment is offered in the form of app chains where certain like dydx teams prefer having control over all the parameters, and the users have to do their own due diligence.
Camp 3: apps with isolated security can be risky, but for some use cases, an isolated security mechanism might make sense — It’s essential to recognize the risks of an isolated security model and use dApps that have adopted it with caution. However, there’s a world where application or use-case specific might benefit more by adopting an isolated security model than shared security.
Is there a conclusion?
The debate boils down to whether an industry-wide standard on application security configurations should exist. Right now, there’s no right or wrong answer to this question, and we hope that the discussion between L2BEAT and LayerZero can bring us closer to a solution.
A possible consideration to meet somewhere in the middle of this debate could be to establish a process to verify relayer and oracle combinations being used by different dApps built on LayerZero. This would work similarly to how source code verification currently works on explorers like Etherscan. It would allow users to check if a dApp is using the default relayer/oracle combination advised by LayerZero (considered secure) or if it is using a unique combination. While this doesn’t completely solve the problem, as the users will still need to manually check from time to time if the combination is verified. However, it does offer some resolve in the form of a guarantee that the current combination is safe to use.
Moreover, as suggested by many others and Bryan himself, it’s crucial that LayerZero updates its website and marketing material, like the white paper, to reflect these issues in order to better inform the users about the risks of using LayerZero or any dApp built on it.
We appreciate and applaud the work done by the L2BEAT team. It’s important to have difficult discussions on critical topics such as this one, and L2BEAT has done a commendable job with its research work. Additionally, we must recognize and appreciate LayerZero’s positive response to this debate and an openness to listen to criticism and other design ideas.
Get Started with LI.FI Today
To learn more about us,
Head to our link portal at Link3.to/lifi
Read our SDK ‘quick start’ at docs.li.fi
Join the official Discord server
Follow our Telegram Newsletter
or try our any-2-any swaps NOW at transferto.xyz