Gnosis Founder's EthDenver Notes: Limitations of L2s, and an Alternative Scaling Approach
TechFlow Selected TechFlow Selected
Gnosis Founder's EthDenver Notes: Limitations of L2s, and an Alternative Scaling Approach
The founder of Gnosis gave a presentation at EthDenver on March 4 about the limitations of L2s and an alternative scaling approach.
Navigating Web3 tides with focused insightsText: Luyao
Compilation: TechFlow
yu, founder of Gnosis, gave a talk at EthDenver on March 4 about the limitations of L2s and an alternative scaling approach. I found it very interesting—here are some excerpts and notes:
The original purpose of L2 was to batch-process a large number of transactions and then synchronize the results back to L1. It was meant to be a temporary space, not a new permanent layer for storing assets.
In the long run, even if perfectly implemented, L2s still have fundamental issues. For example:
Problem 1
This model only works well for applications whose state doesn't grow significantly—like exchanges (which only need final trade results, not full transaction history). But for applications where state grows continuously, this method cannot scale effectively.
Take ENS as an example:
If 10% of the world’s population (800 million out of 8 billion) wanted to register an ENS name, Ethereum’s entire transaction capacity would be consumed by these requests for two years. During that time, no other transactions could be processed.
Take stocks as another example:
If all global stocks (around 45,000) used Ethereum as their settlement layer, each stock could process fewer than 30 transactions per day—even with L2s in place.
Problem 2
Transaction costs: L2 peak gas prices can exceed $1. Even after EIP-4844 reduces fees by up to 90%, two issues remain:
1. It’s still too expensive for use cases requiring sub-cent gas fees,
2. As demand increases, gas prices will rise again.
Problem 3
Asset withdrawal from L2:
1. Small balances may not cover the gas cost to withdraw,
2. Withdrawal bandwidth is limited—if everyone tries to exit at once, congestion occurs...
Problem 4
Some apps simply cannot be rolled up.
For example, CirclesUBI and POAP generate massive amounts of state data that cannot be compressed—making L2s ineffective for them.
But what if we just stay on L2 permanently—treat it as a standalone, permanent environment? Would that work?
That introduces several new problems:
Problem 1
L2 sequencers are highly centralized.
They can’t steal your funds, but they wield significant power—they decide whether to include your transaction, how much gas to charge, and the ordering of transactions…
He also took a jab at Coinbase, pointing out that if you’re running an exchange on BASE, they could easily prioritize their own trades ahead of yours…
Moreover, centralized sequencers are vulnerable to censorship and could even enforce mandatory KYC—only accepting transactions from KYC-compliant addresses.
The speaker emphasized that, given current regulatory trends, this is highly likely.
Problem 2
Here’s a particularly interesting question raised by the speaker:
If we issue an asset natively on L2—one that doesn’t exist on L1—then what’s the point of L2?
The security of L2 comes from L1. If you don’t rely on L1 at all, why use L2 in the first place?
Problem 3
(This next point is especially interesting!) The rigidity problem.
Ethereum L1 is still evolving and will undergo many changes over the next 5–10 years—posing major challenges for L2s.
For example, Snapshot currently performs voting on L2 and syncs state back to L1 using Merkle proofs.
However, Ethereum L1 plans to migrate from Merkle Trees to Verkle Trees within the next year or two—rendering the current version of Snapshot incompatible.
Thus, L2s may require some kind of “upgrade” mechanism—but that contradicts their trustless design principle.
Solution
The speaker proposed a fascinating alternative—similar to Cosmos’ IBC model.
Instead of building on top of Ethereum, create a separate chain that runs the same execution environment, and connect it via a trustless ZK-bridge—forming an “Ethereumverse.”
To me, the implementation of zk bridges initially sounded like science fiction—but now such systems actually exist.
It involves running a light client of one chain inside another chain using zk proofs to verify state—completely trustless and far more secure than traditional bridges.
Personal opinion: This is a very interesting and underappreciated solution. If you think deeply about it, you’ll realize it could address most of the issues outlined above.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
