On L2 Security and the Trade-offs Between Tech and Business/Growth
To be or not to be, that’s the dilemma.
For Layer 2s (L2s) things are a bit more complex than that…
It’s not only about being, but also about how they want to be, which technological components to prioritize, and how to approach their product roadmap.
As a new technological primitive, that comes with its own trade-offs.
Before we start diving into the discussion, it’s important to mention that in the current conditions, all L2s have made some technical trade-off that in one way or another impacts their security.
L2Beat offers a comprehensive picture of these risks in its Risk Analysis page.
Be it a centralized sequencer, the lack of fault proofs to determine valid transactions or external state validation - each makes its own trade-offs according to its preferences.
During last week, there’s been a lot of debate among different L2 teams about each other’s strategy, particularly with many criticizing Optimism for their lack of fraud proofs.
While this article does not take any sides, I believe these discussions to be extremely healthy and necessary. They highlight important aspects that the majority of users are not aware of (and should not necessarily be), but are still essential for a deeper perspective.
I want to start with this quote by Mudit because it captures the essence of blockchains and crypto: users don’t really know what’s going on in the background and don’t need to understand it.
Very Optimistic
Optimism and its OP Stack continue to make headlines.
After Base, both Binance Chain, and DeBank have chosen the OP stack to build their own L2s.
Given the incredible traction of the chain, some have voiced criticism regarding their approach.
What is the issue at hand?
As we briefly mentioned above, the main criticism directed towards OP is the lack of fraud proofs, a fundamental component for rollups.
What are fraud proofs?
Optimistic Rollups are called such because “they assume off-chain transactions are valid and don't publish proofs of validity for transaction batches posted on-chain”.
By default, they assume that all transactions are valid, and they rely on a system of fraud proofs to challenge and detect incorrect transactions.
Once transactions are submitted, L2s have a time window, called a “challenge period” where anyone can challenge the results of transactions by running a fraud-proof.
If the challenger succeeds with the fraud-proof, then the protocol “re-executes the transaction(s) and updates the rollup's state accordingly”. The sequencer which included the incorrect transaction then will be penalized.
If the transaction batch goes unchallenged (all transactions are valid) until the challenge period it’s over, it’s considered valid and gets accepted on Ethereum.
No Fraud-Proofs in OP
The lack of fraud proofs in OP effectively means that challenging transaction remains permissioned - in the hands of the OP team.
The sequencer could unilaterally stop transactions or appropriate user funds.
Without fraud-proofs, this effectively means that the security model on OP currently relies on social pressure not to steal user funds.
Of course, there are some limits to the extent of the issues, namely the fact that transactions are eventually settled on L1 and can’t be reversed.
Below is an extract from a post by Jesse Pollack from BASE where he is very transparent on the current situation of the chain’s decentralization and offers a summary of the situation.
I also advise you to take a look at the video linked below because it’s an interesting blueprint for how BASE and other OP projects are progressing toward decentralization:
The thesis from the OP team is that of “progressive decentralization”, and that OP is currently on “training wheels”.
In fact, OP is considered to be a Stage 0 Rollup in full training wheels.
Practically this means that if anything goes wrong, there are additional points of centralization that allow the protocol to respond quickly.
However, their competitors hold a different view.
Both Marc’s (above from Polygon) and Ed's (below from Arbitrum) argue that fraud-proofs are not just “about decentralization” but effectively represent a pre-requisite for a working optimistic rollup.
To their defense, the OP team mentioned that they have been working on implementing the Cannon upgrade, their interactive fault-proof system, as the #1 priority.
Furthermore, dcbuilder points out that Arbitrum proofs are not totally permissionless either, as well as the issue with zk systems.
In fact, it’s important to mention that at the current state, no rollup is actually more secure than the others.
While OP is lacking fault proofs, Arbitrum contracts for instance can still be upgraded by the multi-sig controlled by Offchain Labs and they are still in the process of making fault proofs permissionless.
Arbitrum has been working on decentralizing its validation by introducing BOLD.
For more information on Arbitrum BOLD you can refer to the article I wrote about it:
A.J. Warner from the Arbitrum team took a great deal to explain where the general criticism comes from.
According to his account, the main issue with OP is the fact that having a prover should be a necessary step to qualify as a rollup.
Therefore, launching a roadmap where it will take yields to build a prover (Cannon is expected since March 2022 at least) could have done so without a rollup, which is what the ZK team is doing (and is costing them significant market share).
Instead, on top of it, the OP team also launched a token and massive incentives to build an ecosystem around their stack.
As of today, the security assumptions of the OP stack also impact anyone using it.
The main point can be summed up as: “Why are we strongly advocating for the adoption of technology that everyone acknowledges is nowhere near complete?”
According to AJ this approach has put pressure on all other teams, especially those on ZK rollup to accelerate their business development and adoption plans even though they had other priorities.
He ends up by acknowledging that the OP strategy can be basically summed up as an “aggression in emphasizing growth”, while others might have preferred different tradeoffs.
OP-inions
For once, I agree with AJ that the impact of the approach chosen by OP goes far beyond their tech trade-offs and inevitably impacts any other builder and competitors.
The traction they gathered with the OP stack is currently unrivaled.
Idan Levin offers some interesting points for reflection:
We have seen this many times: the value of a network is tied to its users.
The ultimate goal for rollups is to manage to get as many users as possible.
While fine-tuning the technical aspects of a rollup is invaluable, end users rarely care about it. Probably 90% of OP users don’t even know what fraud-proofs are, and that’s how it should be if we ever hope to achieve mainstream traction for crypto.
One must be pragmatic in their approach and find the right balance between the two.
In the end, it only matters if people use your protocol.
You can always improve the decentralization of your tech during your growth push.
This reminds me of my recent criticism of Friend.tech.
I have been vocal about my dislike for the fact that the app is not decentralized, nor does it effectively disclose how they treat users’ data.
For those interested in my complaint you can find it here:
Well, guess what, in a couple of days EVERYONE on CT joined Friend.tech and started pumping their own shares.
How many of these people checked the privacy policy?
The product is also arguably slow and frustrating from a UX perspective
Ultimately, the only thing that matters is that people are using it.
The Friend team could have taken another approach, focusing on a decentralized way for users to connect their social networks, while also drafting a thorough privacy policy.
However, this might have meant sacrificing their golden timing and a once-in-a-lifetime opportunity.
Sure, tomorrow they could steal all of your data and potentially sell it to North Korean hackers - but who cares right? Everyone is having fun.
Of course, the stakes for OP are not the same given that behind the protocol there’s an established company that we can “trust”.
But this line of reasoning works until it doesn’t.
So I can somewhat sympathize with the Arbitrum and Polygon team, as an approach focused on security is what we should all ideally aspire to.
Ultimately as the legendary Ethereum developer Sassal0x mentioned to me, the whole debate can be summed up as:
It all boils down to a trade-off between Business and Tech.
In crypto, it’s not the first time we’ve seen companies focusing on attracting users, building their platforms, and becoming behemoths before fine-tuning every aspect of their products.
Ethereum is a prime example of it!
While I agree in principle that fraud-proofs are fundamental for a rollup, we have to be pragmatic: what are going to do about it? Cutting OP off Ethereum and preventing them from acquiring clients for their stack?
We should therefore assume that these teams have carefully weighted their risks, as they are infinitely smarter than us (than me at least).
In my humble opinion, there’s no clear answer to this dilemma, and pragmatically, I can see both points.
Everyone has their own roadmap: some may be more focused on the tech, while others prefer a lean approach centered on growth. Who am I to judge?
As Sassal0x mentioned, in the endgame, everyone will keep iterating until they will perfect their stack and live happily ever after.
As Idan Levin noted above:
The question is not how centralized you are *now*, but how decentralized you *will be* in 5/10 years from now
Beyond taking sides, what I wish to show with this article is that the conversation goes far beyond the classic “Top 10 Projects building on OP Stack”.
There are many factors to consider when discussing L2s and their development.
I hope that this article can help readers delve deeper into their reasoning and shed light on the trade-offs that these teams are making along the way.
Thank you for the writing, very good article.
So good for reading, thanks