On September 27, Vitalik Buterin published a design note that most readers will route into the "long-term roadmap" folder and forget. It is also incomplete.
The note proposes separating two activities Ethereum has bundled together since genesis: doing work, and checking work. Under the current model, every full node downloads every transaction, executes every computation, and stores the same state. Redundancy is the source of security. Redundancy is also the source of the bottleneck. Buterin's alternative distributes computation and data across specialized participants, while the rest of the network verifies succinct cryptographic proofs that the work was done correctly. If that lands, it is not a throughput patch. It is a rewrite of the verification model itself โ a shift from "everyone re-computes" to "everyone cheaply validates."
So let me establish what the proposal is, and what it is not.
Context: why redundancy became the cost
Ethereum's security guarantee has never been that any single node is trustworthy. The guarantee is that no single node needs to be trusted, because thousands of them independently reproduce the same result. Consensus emerges from repetition. The cost of that guarantee is architectural: the network's throughput is bounded by the slowest honest node, and its state growth is bounded by the least capable machine that still wants to verify.
For a decade, that trade-off was acceptable. But as state grew and applications became more composable, the burden of re-execution began to dominate. Block proposers, builders, and searchers already run specialized machines. The verifying majority is still asked to keep pace anyway โ re-running work they did not produce, on hardware that was never meant to carry it.
Buterin's note sketches a 2030-era architecture where that coupling loosens. Three components carry the load: an L1 zkEVM, which lets the network verify block execution through zero-knowledge proofs rather than re-running the computation; weak statelessness, which lets most validators avoid maintaining a full state database; and data sampling, which lets nodes confirm availability by sampling rather than downloading everything. Around these, computation and data are distributed to specialized participants. Ordering โ and the non-reorderable state-change information โ stays on-chain. The surrounding computation is processed and aggregated before it ever enters a block.
If that sounds like modularity with extra steps, it is, but with one substantive difference. The typical modular stack externalizes execution to other chains entirely. This proposal keeps verification anchored to L1 and changes what L1 verifies. The mempool and block-building pipeline would split across more actors, not fewer chains.
Core: three claims worth auditing
I have spent most of my career inside verification infrastructure. During a six-month audit of the early Slasher protocol draft, I found a consensus divergence in the finalized state-transition function that could have produced permanent chain splits under high latency โ a forty-page memo, initially rejected, later validated. That background shapes how I read this note. Three claims stand out, and only one of them is anywhere near production.
The first is the L1 zkEVM itself. It is the direction's center of gravity, and it is still research. It has not been integrated into a production-grade Ethereum client. Multiple dependent technologies across the wider architecture are explicitly unfinished. Anyone pricing this as a near-term upgrade is reading the note too optimistically. The honest classification is "active research with directional clarity and no delivery date."
L2 zkEVM and L1 zkEVM are not the same project wearing different labels. L2 zkEVMs already run in production, proving rollup state transitions and posting proofs to L1. They compress execution and inherit security from the base layer. L1 zkEVM inverts that: it moves proof verification into the base layer itself, so the base layer stops re-executing and starts verifying. That is a heavier lift, because it changes the client's core responsibility rather than adding a bridge on top. Conflating the two is the most common error in coverage of this note.
The second claim is sharper, and it is the one I would circulate to every protocol team I advise: state access is a more systemic problem than computation verification. Buterin says it directly. Making computation verifiable does not remove the need to fetch the data that computation depends on. Managing and parallelizing access to a growing state is the harder architectural problem. This is the line the coverage skipped. Even if proof generation became free tomorrow, data availability and state management would still cap what the architecture can achieve.
That reframing has a forensic consequence. The ledger remembers what the interface forgets: every proof is only as sound as the state its witness references. If witnesses are expensive to generate, if state clients lag, or if access paths become bottlenecked, the verification layer inherits a latency it cannot prove away. Verification cheapness does not equal state cheapness.
Data sampling is the least discussed and most load-bearing piece. It lets a node confirm that data is available without downloading all of it โ a statistical guarantee rather than an absolute one. This is where the architecture departs from classical sharding. Sharding divided the chain into parallel lanes; this design keeps one chain and divides the labor of producing and checking it. The security argument shifts from "everyone verifies everything" to "enough nodes sample enough to make withholding detectable." That is a probabilistic security model, and it needs to be stress-tested under adversarial conditions, not just described in a blog post.
The third claim is weak statelessness, the most plausible near-term pressure valve. Under it, most validators stop maintaining the full state database; block producers retain the state needed to construct blocks and generate witnesses. This lowers the storage and compute floor for validators. That is real. But it remains research, and it depends on other architectural changes landing first. It is a dependent variable, not a standalone fix. Treating it as a solution is the same error as treating the roadmap as a release.
None of these components is hypothetical in isolation. Proof aggregation, data availability sampling, and stateless clients all exist in research clients or adjacent systems. What is new is the combination โ and the willingness to let the base layer stop doing the computation it currently does. That is a social change dressed as a technical one, because it asks the validator set to give up a role it has held since genesis.
The application layer will feel this before the consensus layer does. Workloads that are parallelizable, aggregatable, or prunable should become cheaper. Workloads with heavy serial interdependencies โ the kind of atomic composability that DeFi protocols take for granted โ should become relatively more expensive. That is not a pricing footnote. It is an incentive to redesign contracts around independent dependency graphs instead of treating Ethereum as a single sequential machine. Protocols that assume cheap global synchronization will pay a premium for it. This is the quiet part of the proposal: the interest-rate curves and liquidation engines that assume instant cross-contract reads are the first candidates for redesign.
Contrarian: the decentralization inversion
Here is the angle the optimistic reading misses. The proposal's stated appeal is that decentralization becomes a performance advantage rather than a tax. But the mechanism that enables it โ separating production from verification โ concentrates power in exactly the roles that remain.
Proof generation has economies of scale. Proving large blocks is expensive, and the cost curve rewards size. That creates natural gravity toward a small number of specialized provers. The same forces that make verification cheap for everyone make production exclusive to a few. You can end up with a network where checking is permissionless and doing is oligopolistic.
I have watched this pattern in less exotic systems. Audit trails do not decentralize themselves. Someone has to run the expensive hardware, and whoever runs it sets the cadence everyone else lives with. If a handful of proving entities dominate block construction, the "decentralization as advantage" narrative collides with reality โ and it collides in a way regulators, not just researchers, will eventually notice. Centralized block production is a compliance surface, and a small prover set is a single point of both failure and oversight pressure.
For an auditor, the more uncomfortable observation is that concentrated block production is not only a security question. It is a jurisdictional one. A small number of provers with identifiable hardware footprints present a clear regulatory target, as mining pools once were. If the roadmap succeeds technically, it may hand compliance authorities a much smaller surface to pressure. The decentralization claim would then be tested not by an adversary on-chain, but by a subpoena.
Takeaway
The note is a genuine architectural signal, not a deliverable. Track three things: L1 zkEVM testnets or client integration, any weak-statelessness EIP entering formal proposal, and prover-market concentration. The first two validate the roadmap. The third decides whether the roadmap's promise survives contact with its own incentives. The real question is not whether Ethereum can make verification cheap. It is whether it can keep production honest while it does.