Vitalik: Short- and Medium-term Roadmap for Improving Ethereum's Permissionlessness and Decentralization
TechFlow Selected TechFlow Selected
Vitalik: Short- and Medium-term Roadmap for Improving Ethereum's Permissionlessness and Decentralization
Ethereum L1 can and certainly should become a robust foundational layer for Layer 2 projects adopting a hyper-scale approach.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Translation: Dengtong, Jinse Finance
I’m writing this article on the final day of the Ethereum developer interop in Kenya. We’ve made significant progress implementing and resolving technical details for upcoming major Ethereum upgrades—most notably PeerDAS, the Verkle tree transition, and decentralized approaches to storing history under EIP-4444. From my perspective, Ethereum’s development pace and our ability to deliver large, important features continues to strengthen, significantly improving the experience for node operators and (L1 and L2) users alike.
Ethereum client teams collaborating to deliver the Pectra devnet
Given these growing technical capabilities, an important question arises: are we moving toward the right goals? A recent series of frustrated tweets from long-time Geth core developer Peter Szilagyi prompted reflection on this very issue:
These concerns are valid. They echo worries expressed by many in the Ethereum community. Personally, I've often worried about these issues too. However, I don’t believe the situation is as dire as Peter’s tweets suggest. On the contrary, many of these problems are already being addressed through ongoing protocol features, and many others can be resolved with realistic adjustments to the current roadmap.
To understand what this means in practice, let’s walk through the three examples Peter provided. These are common concerns shared by many community members, and addressing them is crucial.
MEV and Builder Dependence
In the past, Ethereum blocks were created by miners using relatively simple algorithms. Users sent transactions to a public peer-to-peer network, commonly known as the "mempool" (or "txpool"). Miners listened to the mempool, accepted valid transactions that paid fees, included those they could fit, and prioritized higher-fee transactions when space was limited.
This was a very simple and decentralization-friendly system: as a miner, running default software allowed you to earn fee revenue comparable to highly specialized mining farms. However, around 2020, people began exploiting what’s called Miner Extractable Value (MEV): earning revenue through complex strategies that leverage knowledge of activity within various DeFi protocols.
For example, consider a decentralized exchange like Uniswap. Suppose at time T, the USD/ETH rate on centralized exchanges and Uniswap is $3,000. At time T+11, the USD/ETH rate on centralized exchanges rises to $3,005. But Ethereum hasn’t produced the next block yet. By time T+12, it does. Whoever creates that block can make their first transaction a series of Uniswap buys, purchasing all available ETH on Uniswap at prices ranging from $3,000 to $3,004. This extra revenue is MEV. Similar issues exist beyond DEXs. The 2019 paper Flash Boys 2.0 details this extensively.
A chart from the Flash Boys 2.0 paper showing the amounts of extractable revenue using various methods.
The problem is that this breaks why mining (or post-2022 block proposing) could be "fair": now, larger players with better optimization capabilities for such extraction algorithms earn superior returns per block.
Since then, a debate has persisted between two strategies, which I call MEV minimization and MEV isolation. MEV minimization takes two forms: (i) actively developing MEV-free alternatives to Uniswap (e.g., Cowswap), and (ii) building in-protocol technologies like encrypted mempools that reduce the information available to block producers, thereby limiting their potential earnings. In particular, encrypted mempools can prevent strategies like sandwich attacks, where transactions are placed before and after a user’s transaction to economically exploit them ("front-running").
MEV isolation works by accepting MEV but attempting to limit its centralizing impact on staking by splitting the market into two participants: validators who attest and propose blocks, while the task of selecting block contents is outsourced via an auction mechanism. Individual stakers no longer need to worry about optimizing DeFi arbitrage themselves; they simply join the auction and accept the highest bid. This is known as Proposer-Builder Separation (PBS). This approach has precedents in other industries: one reason restaurants remain so decentralized is that they often rely on relatively centralized suppliers for certain operations that benefit from economies of scale. So far, PBS has been quite successful in ensuring a level playing field between small and large validators—at least regarding MEV. However, it introduces another problem: the task of choosing which transactions to include becomes more centralized.
My view has always been that MEV minimization is good, and we should pursue it (I personally often use Cowswap!) — though encrypted mempools face many challenges, MEV minimization alone may not suffice; MEV won’t drop to zero, or even close to zero. Therefore, we also need some form of MEV isolation. This leads to an interesting challenge: how do we make the "MEV isolation box" as small as possible? How do we give builders as little power as possible while still allowing them to absorb the role of optimizing arbitrage and other forms of MEV capture?
If builders have the power to completely exclude transactions from blocks, attacks become easy. Suppose you hold a collateralized debt position (CDP) in a DeFi protocol backed by an asset whose price is rapidly falling. You want to increase your collateral or exit your CDP. A malicious builder might collude to refuse including your transaction, delaying it until the price drops enough to force liquidation of your CDP. If this happens, you pay a hefty penalty, and the builder captures a large portion of it. So how do we prevent builders from excluding transactions and carrying out such attacks?
This is where inclusion lists come in.
Source: ethresear.ch
Inclusion lists allow block proposers (i.e., stakeholders) to specify transactions that must be included in a block. Builders can still re-order transactions or insert their own, but they must include the proposer’s transactions. Ultimately, modified inclusion lists were designed to constrain the next block rather than the current one. Either way, they strip builders of the ability to completely remove transactions from blocks.
MEV is a complex issue; even the above description omits many important nuances. As the saying goes, “you might not be looking for MEV, but MEV is looking for you.” Ethereum researchers have consistently focused on minimizing the “isolation box,” reducing the potential harm builders could cause (e.g., by excluding or delaying transactions to attack specific applications).
That said, I do believe we can go further. Historically, inclusion lists have often been seen as a "special-case feature": typically, you don’t think about them, but if a malicious builder starts acting badly, they give you a "second path." This attitude is reflected in current design decisions: in the current EIP, the gas limit for inclusion lists is about 2.1 million. But we could make a philosophical shift in how we view inclusion lists: treat inclusion lists as the block, and the builder’s role as an auxiliary function adding some transactions to collect MEV. What if the builder had a 2.1 million gas limit?
I find ideas in this direction—really pushing the isolation box as small as possible—very interesting, and I support moving in this direction. This represents a shift from the "2021-era philosophy," where we were more enthusiastic about the idea that since we now have builders, we could "overload" their functions to serve users in more complex ways, e.g., supporting the ERC-4337 fee market. Under this new philosophy, the transaction validation part of ERC-4337 must be integrated into the protocol. Fortunately, the ERC-4337 team has increasingly warmed up to this direction.
In summary: MEV thinking has shifted back toward empowering block producers, including giving them direct control over ensuring user transaction inclusion. Account abstraction proposals have shifted toward eliminating reliance on centralized relayers or even bundlers. However, there's a strong argument that we haven't gone far enough, and I welcome continued pressure to push development further in this direction.
Liquid Staking
Today, solo stakers represent a relatively small portion of total Ethereum staking, with most staking performed by various providers—some centralized operators and others DAOs like Lido and RocketPool.
I’ve done my own research—various polls, surveys, and face-to-face conversations—asking people, “Why aren’t you, specifically you, solo staking today?” To me, a robust solo staking ecosystem remains my preferred outcome for Ethereum staking, and one of Ethereum’s best qualities is that we’re actually trying to support a strong solo staking ecosystem instead of simply surrendering to delegation. Yet, we’re far from achieving this. In my polls and surveys, consistent trends emerge:
The overwhelming majority of non-solo stakers cite the minimum 32 ETH requirement as their primary reason.
Among those citing other reasons, the biggest is the technical difficulty of running and maintaining validator nodes.
Loss of immediate ETH liquidity, security risks of "hot" private keys, and inability to simultaneously participate in DeFi protocols are significant but smaller concerns.
Farcaster poll showing main reasons people don’t solo stake.
Staking research needs to address two key questions:
How do we solve these concerns?
Even with valid solutions for most issues, how do we maintain protocol stability and robustness against attacks if most people still don’t want to solo stake?
Many ongoing research and development projects aim precisely to address these issues:
Verkle trees combined with EIP-4444 allow staking nodes to run with very low disk requirements. Additionally, they enable near-instant synchronization, greatly simplifying setup and switching between implementations. They also make Ethereum light clients more feasible by reducing the data bandwidth needed to provide proofs for each state access.
Research (e.g., these proposals) explores methods to allow larger validator sets (enabling smaller staking minimums) while reducing consensus node overhead. These ideas could be implemented as part of single-slot finality. Doing so would also make light clients more secure, as they could verify full sets of signatures instead of relying on sync committees.
Ongoing Ethereum client optimizations continue to lower the cost and difficulty of running validator nodes despite growing historical data.
Research into slashing caps might alleviate concerns about private key risks and allow stakers to keep their ETH staked in DeFi protocols simultaneously (if they choose).
The 0x01 withdrawal credential allows stakers to set an ETH address as their withdrawal address. This makes decentralized staking pools more viable, giving them an edge over centralized ones.
Still, we can do more. Theoretically, validators could withdraw faster: Casper FFG remains secure even if the validator set changes by several percentage points each time finality occurs (i.e., once per epoch). Thus, with effort, we could drastically shorten withdrawal periods. If we wanted to greatly reduce the minimum deposit size, we could make tough trade-offs in other directions. For instance, increasing finality time fourfold would reduce the minimum deposit size fourfold. Single-slot finality will later resolve this entirely by moving beyond the “every staker participates every epoch” model.
Another critical aspect of the entire issue is staking economics. A key question is: do we want staking to be a relatively niche activity, or do we want everyone—or nearly everyone—to stake all their ETH? If everyone stakes, what responsibilities should each person bear? If people end up lazily delegating, it could lead to centralization. There are profound philosophical questions here. The wrong answer could push Ethereum toward centralization and “recreating the traditional financial system through extra steps”; the right answer could create a shining example of a successful ecosystem with a broad, diverse base of independent stakers and highly decentralized staking pools. These questions touch on Ethereum’s core economics and values, so we need more diverse participation.
Node Hardware Requirements
Many key issues around Ethereum decentralization ultimately boil down to a defining blockchain question of the past decade: how accessible should running a node be, and how do we achieve that?
Today, running a node is difficult. Most people don’t do it. On the laptop I’m using to write this article, I have a reth node occupying 2.1 TB—an already heroic result of software engineering and optimization. I needed to buy an additional 4 TB hard drive just to store this node on my laptop. We all want running nodes to become easier. In my ideal world, people could run nodes on their phones.
As I wrote above, EIP-4444 and Verkle trees are two key technologies bringing us closer to this ideal. If both are implemented, node hardware requirements could eventually shrink to less than a hundred gigabytes, or even approach zero if we fully eliminate historical storage responsibilities (possibly only for non-staking nodes). Type 1 ZK-EVMs would eliminate the need to run EVM computations yourself, as you could simply verify proofs showing correct execution. In my ideal world, we’d stack all these technologies together, and even Ethereum browser extension wallets (like Metamask, Rabby) would have built-in nodes to verify these proofs, perform data availability sampling, and ensure the chain is correct.
This vision is commonly known as "The Verge."
All of this is well-known and understood, even by those concerned about Ethereum node bloat. However, an important concern remains: if we offload responsibility for maintaining state and providing proofs, isn’t that a centralization vector? Even if they can’t cheat by providing invalid data, doesn’t excessive reliance on them contradict Ethereum’s principles?
A near-term version of this concern is many people’s discomfort with EIP-4444: if regular Ethereum nodes no longer need to store old history, who will? A common answer is that plenty of large actors (e.g., block explorers, exchanges, Layer 2s) have incentives to hold this data, and compared to the Wayback Machine’s 100 PB archive, the Ethereum chain is tiny. Thus, the idea that any history would actually be lost seems absurd.
However, this argument relies on a small number of large participants. In my trust model taxonomy, this is a 1-of-N assumption, but N is very small. This carries tail risks. One thing we could do is store old history in a peer-to-peer network where each node stores only a small portion of the data. Such a network would still replicate sufficiently to ensure robustness: every piece of data would have thousands of copies, and in the future, we could use erasure coding (in fact, by placing history into EIP-4844-style blobs, which already have built-in erasure coding) to further enhance resilience.
Blobs have erasure coding within and across blobs. The easiest way to provide ultra-resilient storage for all of Ethereum’s history is likely to place beacon and execution blocks into blobs. Image source: codex.storage
This work has long been secondary. The Portal Network does exist, but in practice, it hasn’t received attention commensurate with its importance to Ethereum’s future. Fortunately, there’s now growing momentum to dedicate more resources to a minimal, distributed-storage-and-history-access-focused version of the Portal Network. We should build on this, working together to implement EIP-4444 quickly alongside a robust, decentralized peer-to-peer network for storing and retrieving old history.
For state and ZK-EVMs, this distributed approach is more challenging. To build an efficient block, you need full state access. In this case, I personally lean toward a pragmatic approach: define and uphold a certain hardware requirement for a “do-everything” node—higher than the (ideally ever-decreasing) cost of a simple chain-verifying node, but still low enough for enthusiasts to afford. We rely on a 1-of-N assumption, ensuring N is reasonably large.
ZK-EVM proofs may be the trickiest part; real-time ZK-EVM provers may require more powerful hardware than archival nodes, even with advances like Binius and worst-case bounds on multidimensional gas. We could work on distributed proving networks where each node handles, say, 1% of block execution proof responsibility, and block producers merely aggregate a hundred proofs at the end. Proof aggregation trees could help further. But if that doesn’t work well, another compromise is to allow higher hardware requirements for proving, while ensuring “do-everything” nodes can directly verify Ethereum blocks (without proofs) quickly enough to effectively participate in the network.
Conclusion
I believe that 2021-era Ethereum thinking did grow accustomed to shifting responsibilities to a few large players, relying on either market mechanisms or zero-knowledge proof systems to keep centralized actors honest. Such systems usually work well in general but suffer catastrophic failures in worst-case scenarios.
At the same time, I want to emphasize that current Ethereum protocol proposals have significantly moved away from this model and take the needs of truly decentralized networks much more seriously. Ideas around statelessness, MEV mitigation, single-slot finality, and similar concepts have pushed further in this direction. A year ago, people seriously considered using relays as semi-centralized nodes for data availability sampling. This year, we no longer need to do that—PeerDAS has made surprisingly strong progress.
Yet, on all three central issues I discussed above—and many other important ones—we can do much more to advance further in this direction. Helios has made huge strides in providing Ethereum with a "true light client." Now, we need to include it by default in Ethereum wallets, have RPC providers deliver proofs along with results for verification, and extend light client technology to Layer 2 protocols. If Ethereum scales via a rollup-centric roadmap, Layer 2s need the same security and decentralization guarantees as Layer 1. In a rollup-centric world, there are many other things we should take more seriously; decentralized and efficient cross-L2 bridges are just one example. Many dapps currently rely on centralized protocols to fetch logs because native Ethereum log scanning has become too slow. We could improve this via dedicated decentralized sub-protocols; here’s one proposal of mine on how to do so.
There are nearly infinite blockchain projects targeting the “we can be super fast, we’ll consider decentralization later” market. I believe Ethereum should not join that crowd. Ethereum L1 can and certainly should serve as a strong foundational layer for Layer 2 projects adopting massively scalable approaches, using Ethereum as a pillar of decentralization and security. Even rollup-centric approaches require L1 itself to be sufficiently scalable to handle substantial throughput. But we should deeply respect the qualities that make Ethereum unique, and continue striving to preserve and enhance them as Ethereum scales.
Special thanks to Dankrad Feist, Caspar Schwarz-Schilling, and Francesco for rapid feedback and review.
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
