Vitalik's Latest Long Read: Ethereum Evolution Continuation — Four Key Improvements for L2
TechFlow Selected TechFlow Selected
Vitalik's Latest Long Read: Ethereum Evolution Continuation — Four Key Improvements for L2
Ethereum scaling is no longer a "from zero to one" problem, but a "from one to many" problem.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Translation: jk, Odaily Planet Daily
On March 13, the Dencun hard fork activated, enabling one of Ethereum's long-awaited features: proto-danksharding (also known as EIP-4844, or blobs). Initially, this fork reduced rollup transaction fees by over 100x, as blobs were nearly free. In recent days, we've finally seen a surge in blob usage as the Blobscriptions protocol begins utilizing them, and the fee market has accordingly activated. Blobs are not free, but they remain significantly cheaper than calldata.
Left: Thanks to Blobscriptions, blob usage has finally reached the target of 3 per block. Right: Accompanying this is the blob fee "entering price discovery mode."
Source: https://dune.com/0xRob/blobs
This milestone marks a key shift in Ethereum’s long-term roadmap: with blobs, Ethereum’s scalability is no longer a “zero-to-one” problem, but rather a “one-to-many” challenge. From here on, important scaling work—whether increasing the number of blobs or improving rollups’ ability to utilize each blob—will continue, but it will be more incremental. Fundamental changes related to how Ethereum functions as an ecosystem are increasingly behind us. Moreover, the focus is gradually shifting—and will continue to shift—from Layer 1 issues like PoS and scaling toward problems closer to the application layer. The central question explored in this article is: where does Ethereum go from here?
The Future of Ethereum Scaling
In recent years, we’ve witnessed Ethereum’s gradual transformation into a Layer 2–centric ecosystem. Major applications have begun moving from L1 to L2, payments are increasingly defaulting to L2, and wallets are building their user experiences around the new multi-L2 environment.
From the beginning, a key part of the rollup-centric roadmap has been the concept of independent data availability space: a special section within a block that is inaccessible to the EVM, designed to store data for Layer 2 projects like rollups. Because this data space is EVM-inaccessible, it can be broadcast and verified independently from the rest of the block. Ultimately, it can be validated using a technique called data availability sampling (DAS), which allows every node to verify data publication by randomly checking small samples. Once implemented, blob space can scale dramatically; the ultimate goal is 16 MB per slot (about 1.33 MB/sec).
Data availability sampling: Each node only needs to download a small portion of data to verify overall availability.
EIP-4844 (i.e., blobs) does not yet provide us with data availability sampling. However, it does establish the foundational framework such that DAS and increased blob counts can be introduced incrementally—all without requiring any action from users or applications. In practice, the only required "hard fork" would be a simple parameter change.
From here, two directions need continued development:
-
Gradually increase blob capacity, ultimately realizing full-scale data availability sampling with 16 MB of data space per slot;
-
Improve Layer 2s to better utilize the available data space.
Bringing DAS to Reality
The next phase could involve a simplified version of DAS called PeerDAS. In PeerDAS, each node stores a significant portion (e.g., 1/8) of all blob data and maintains connections with many peers in the p2p network. When a node needs to sample specific data, it queries one of its peers known to store that segment.
If each node downloads and stores 1/8 of all data, PeerDAS theoretically allows us to scale blobs up by 8x (in practice, about 4x due to 2x redundancy from erasure coding). PeerDAS can be rolled out gradually: initially, professional stakers may continue downloading full blobs while solo stakers only download 1/8 of the data.
Additionally, EIP-7623 (or alternatives like 2D pricing) could impose stricter limits on the maximum size of execution blocks (i.e., “regular transactions”), making it safer to simultaneously increase blob targets and L1 gas limits. In the long run, more sophisticated 2D DAS protocols will allow further expansion of blob space.
Improving L2 Performance
Today, Layer 2 protocols can improve in four key areas.
1. Use Bytes More Efficiently Through Data Compression
My data compression overview diagram can still be viewed here;
Naively, a transaction takes about 180 bytes. However, a series of compression techniques can reduce this size in stages; with optimal compression, we might reduce transaction data below 25 bytes per transaction.
2. Use Optimistic Data Techniques on L1 Only in Exceptional Cases to Secure L2
Plasma is a class of techniques allowing data to stay off-chain under normal conditions while providing security equivalent to rollups for certain applications. For EVMs, Plasma cannot protect all tokens. However, Plasma-inspired designs can protect most tokens. And constructions much simpler than Plasma can greatly improve today’s validiums. L2s unwilling to post all data on-chain should explore such techniques.
3. Continue Improving Execution-Related Limits
Once the Dencun hard fork activated, rollups leveraging its newly introduced blobs saw costs drop 100x. Base rollup usage immediately surged:
This led Base to hit its internal gas limit, causing unexpected fee spikes. This brought broader awareness that Ethereum’s data space isn’t the only thing needing scaling: rollups themselves also require internal scaling.
Part of this involves parallelization—rollups could implement something like EIP-648. But storage, and the interaction between computation and storage, is equally important. This remains a major engineering challenge for rollups.
4. Continue Improving Security
We are far from a world where rollups are truly secured by code. In fact, according to l2beat, only one out of five—Arbitrum—is fully EVM-compatible and even reaches what I call “stage one.”
This must be directly addressed. While we currently lack sufficient confidence in complex optimistic or SNARK-based EVM verifiers, we can certainly reach halfway by implementing security councils that can alter code behavior only under high thresholds (for example, my proposal of 6-of-8; Arbitrum uses 9-of-12).
Ecosystem standards need to become stricter: so far, we’ve tolerated and accepted any project claiming to be “on the path to decentralization.” By year-end, I believe our standards should rise, and we should consider only those reaching at least stage one as true rollups.
Afterward, we can cautiously move toward stage two: a world where rollups are truly code-enforced, and security councils intervene only when the code is “clearly self-contradictory” (e.g., accepting two incompatible state roots, or different implementations yielding different results). One safe path toward this goal is using multiple provers.
What This Means for Ethereum Development
At ETHCC in summer 2022, I gave a talk describing Ethereum’s development state as an S-curve: we’re entering a period of rapid transformation, after which development will slow again as L1 stabilizes and focus shifts back to users and the application layer.
Today, I’d say we are clearly on the slowing, right-hand side of this S-curve. As of two weeks ago, the two largest transformations to the Ethereum blockchain—switching to proof-of-stake and restructuring into blobs—have been completed. Future changes remain important (e.g., Verkle trees, single-slot finality, protocol-level account abstraction), but they are less disruptive than PoS and sharding. In 2022, Ethereum was like an airplane replacing its engines mid-flight. In 2023, it replaced its wings. The transition to Verkle trees is the last remaining major transformative step (we already have testnets); everything else is more like replacing tail fins.
The goal of EIP-4844 was to make one large, one-time change to establish long-term stability for rollups. Now that blobs are live, future upgrades to full danksharding with 16 MB blobs—or even transitioning cryptographic schemes to STARKs over 64-bit Goldilocks fields—can happen without requiring further actions from rollups or users. It also reinforces an important precedent: Ethereum’s development follows a well-known, long-standing roadmap, and applications built for the “new Ethereum” (including L2s) now enjoy a stable, long-term environment.
What This Means for Applications and Users
Ethereum’s first decade was largely a training phase: the goal was simply to get Ethereum L1 off the ground, with applications mostly confined to a small group of enthusiasts. Many argued that the lack of mass adoption over the past decade proves crypto is useless. I’ve always opposed this view: almost every non-financial speculative crypto application depends on low fees—so we shouldn’t be surprised that high fees mainly yield financial speculation.
Now that we have blobs, the key constraint that held us back is beginning to dissolve. Fees have finally dropped substantially; my seven-year-old statement that the internet of money should cost less than five cents per transaction is finally coming true. We’re not completely out of the woods—fees could still rise if usage grows too fast, and we must continue scaling blobs (and rollups separately) over the next few years. But we can see light at the end of the tunnel… uh… dark forest.
For developers, this means one simple thing: we no longer have any excuses. Until recently, we set low standards, building applications clearly incapable of scaling, as long as they worked as prototypes and were reasonably decentralized. Today, we have all the tools we need—and most of the tools we’ll ever have—to build applications that are both cypherpunk and user-friendly. So we should go out and do exactly that.
Many are rising to this challenge. The Daimo wallet explicitly describes itself as Venmo on Ethereum, aiming to combine Venmo’s convenience with Ethereum’s decentralization. In decentralized social media, Farcaster excels at combining real decentralization (e.g., see this guide on building your own alternative client) with excellent user experience. Unlike the earlier “social finance” craze, the average Farcaster user isn’t here to gamble—a key test for sustainable crypto applications.
This post was sent via Warpcast, a primary Farcaster client; this screenshot comes from Firefly, an alternative Farcaster + Lens client.
These successes are foundations we must build upon and extend into other application domains, including identity, reputation, and governance.
Applications Built or Maintained Today Should Follow a 2020s Ethereum Blueprint
The Ethereum ecosystem still hosts many applications operating around workflows fundamentally rooted in “2010s Ethereum.” Most ENS activity still occurs on L1. Most token launches also happen on L1, without serious consideration for ensuring bridged tokens are readily available on L2 (e.g., a fan of the ZELENSKYY memecoin appreciates its ongoing donations to Ukraine but complains that L1 fees make it too expensive). Beyond scalability, we lag in privacy: POAPs are entirely public on-chain, which may be appropriate for some use cases but highly suboptimal for others. Most DAOs and Gitcoin Grants still rely on fully transparent on-chain voting, making them highly vulnerable to bribery (including retroactive airdrops), which has been shown to severely distort contribution patterns. ZK-SNARKs have existed for years, yet many applications still fail to properly adopt them.
These are teams doing hard work managing large existing user bases, so I don’t fault them for not upgrading to the latest tech wave simultaneously. But such upgrades must happen soon. Here are some key differences between “a workflow fundamentally rooted in 2010s Ethereum” and “a workflow fundamentally rooted in 2020s Ethereum”:
Essentially, Ethereum is no longer just a financial ecosystem. It’s a full-stack alternative to much of centralized technology, even offering things centralized systems cannot (e.g., governance-related applications). We need to build with this broader ecosystem in mind.
Conclusion
Ethereum is undergoing a decisive transition—from an era of rapid L1 progress to one where L1 advances will still be significant, but somewhat milder and less disruptive to applications.
We still need to complete scaling. This work will happen more behind the scenes, but remains important.
Application developers are no longer just building prototypes; we’re building tools for millions. Across the ecosystem, we need to adjust our mindset accordingly.
Ethereum has evolved beyond being “just” a financial ecosystem into a more comprehensive, independent decentralized tech stack. Across the ecosystem, we also need to fully adjust our thinking in this regard.
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
@VitalikButerin
