Ethereum’s 2030 vision shifts work to cryptographic proofs. Who verifies the result?
Vitalik Buterin’s Sept. 27 vision describes Ethereum moving from a system in which every verifier repeats much of the work toward one where data can be sampled and execution can be checked with compact proofs. One part, PeerDAS, has already shipped. The larger execution shift remains under development. A proof can establish that a calculation followed specified rules, but users still need data, a way to submit transactions and a protocol that decides whose result becomes final.
- Vitalik Buterin published “The cryptographic world computer” on Sept. 27, 2026.
- Ethereum’s December 2025 Fusaka upgrade brought PeerDAS to mainnet.
- PeerDAS splits extended blob data into 128 columns for network distribution and sampling.
- Regular nodes subscribe to at least 8 column subnets under Ethereum’s description.
- Ethereum’s proposed 2030 base-layer execution proofs remain future work, separate from existing rollup proofs.
The headline question has two answers. A prover produces a cryptographic proof; a verifier, potentially any validating node running the relevant software, checks that proof against the rules and public inputs. The Ethereum roadmap for a base-layer zkEVM says verification should be much cheaper than re-executing every transaction. But deciding whether a proof is sound does not alone settle whether transaction data are available or whether an operator can withhold a user’s transaction.
Buterin’s Sept. 27 essay, “The cryptographic world computer”, frames the destination as a combination of a blockchain, cryptographic privacy and verification, and decentralised off-chain components. He contrasts an older pattern of downloading and re-executing with a model in which nodes sample data and verify proofs. He describes other possible changes to consensus and block construction. This is a personal technical vision, not a final upgrade specification ratified by all Ethereum client teams.
The distinction between what exists and what is envisioned is important. PeerDAS arrived with Fusaka in December 2025, according to the Ethereum Foundation’s February 2026 protocol update. The Foundation says validators now sample blob data instead of downloading all of it. A network-wide shift to verifying succinct execution proofs for base-layer blocks is not described as already deployed. A reader who hears that Ethereum “will verify proofs in 2030” should ask which proof, whose computation it covers and which actors can independently test it.
PeerDAS checks access to data, not every calculation
The already deployed piece is PeerDAS, or peer-to-peer data availability sampling. Rollups put transaction data into Ethereum blob space so that other participants can retrieve enough information to reconstruct state and hold an operator to the rules. The old approach of making every node download every blob would make larger data volumes expensive for ordinary validators. Sampling asks nodes to check small pieces against cryptographic commitments while the network distributes enough coded pieces for reconstruction.
Ethereum’s explanation says extended blob data is divided into 128 columns. A regular node joins at least 8 randomly chosen column subnets. Eight divided by 128 is one sixteenth of the extended data. The coding adds redundancy, so that amount corresponds to about one eighth of the original data volume under the documentation’s description. The numbers refer to a default node’s data workload, not a claim that one node can personally hold the whole history of every rollup at one eighth the cost.
Reed-Solomon style coding produces redundant data pieces, and cryptographic commitments help a node check that a sampled piece belongs to what was announced. Sampling provides a probabilistic availability guarantee across participating nodes. It does not replace execution validation. A perfectly available batch of transactions can contain an invalid state transition. Likewise, a valid proof about a state transition is not enough to let a user reconstruct an account state if the data needed to do so are withheld outside the availability guarantees.
The Ethereum Foundation said Fusaka enabled an eightfold increase in theoretical blob capacity. The word theoretical matters: actual sustained throughput depends on scheduled parameter increases, network conditions and rollup use. Crypto.news has explained how rollups use Ethereum’s data layer. Buterin’s new essay treats PeerDAS as the first visible step toward a system that verifies more and repeats less; it should not be recast as the final proof-of-execution upgrade.
The prover does the heavy work; independent nodes check it
In a proof-based execution model, somebody still has to execute transactions and construct evidence about the result. That party may use expensive specialist hardware and software. A succinct proof lets a verifier check, at much lower cost, that the claimed state change follows the program and inputs committed to under the protocol’s rules. A mathematical check does not require the verifier to trust the proving company merely because it generated the proof.
There are conditions attached to that statement. The verifier must run a sound proof system with the right verification key, public inputs and agreed execution rules. A faulty circuit could prove the wrong statement perfectly. A bug in a client implementation could accept a proof it should reject. An upgrade key that can change verifier code without robust controls could weaken the guarantee. In a live protocol, independent implementations and review matter alongside fast proof generation.
Ethereum’s L1 zkEVM roadmap page describes a future in which a node checks a proof of block execution instead of repeating every transaction. Its stated aim is to lower the resource cost of verification. That would make it easier for more people to check blocks if proof verification remains practical on accessible hardware. It does not mean every household can produce a block proof, nor that proof production will be evenly distributed.
Crypto.news reported a hardware competition around proving. The useful distinction is between who can generate a proof in time for the chain and who can cheaply verify one. Proof generation could concentrate among firms with specialised hardware without automatically letting those firms fake a valid state transition. It could still introduce a liveness dependence: if too few parties can produce proofs quickly enough, blocks or finality may slow even when the proof system remains mathematically sound. That is a different risk from an invalid proof being accepted.
The verification question therefore has a human answer as well as a mathematical one. Developers set the circuit, researchers audit it, client teams implement it, node operators run verifiers, and participants decide whether to accept protocol upgrades. Buterin can propose a direction. He cannot by himself make a future verifier secure or mandatory for the network.
Three promises are often folded into the word proof
Take a user sending a payment through a rollup. The transaction has to be included in an ordered batch. The batch’s data must be made available under the rollup’s chosen model. Finally, the resulting state change must follow its rules. Ordering, availability and correctness are separate promises. A proof of correctness addresses the last one for a specified calculation. PeerDAS addresses availability of Ethereum blob data. A sequencer or block-building mechanism affects which transactions are included and in what order.
Crypto.news examined sequencers as a distinct point of control. A perfectly valid proof can attest that a batch was processed according to the rules even if its operator excluded a particular customer’s transaction. A user might have an escape or forced-inclusion route depending on that rollup’s design, but the proof itself does not compel fair access. A sequencer can also reorder transactions while still producing a valid state transition. The statement being proved must not be mistaken for every property users want from a market.
The data side is just as easy to blur. Ethereum’s validium documentation describes systems that use validity proofs but do not post transaction data to Ethereum mainnet. Their execution may be correct according to a verifier, yet a data availability failure can stop users from reconstructing state or withdrawing as expected. An Ethereum rollup posting sufficient data on Ethereum has a different availability model. Calling both simply “ZK” hides a critical difference in a user’s ability to recover an account state without the operator.
The simplest test is a three-column mental checklist. Ask who gets a transaction into the batch. Ask where the data needed to reconstruct balances can be retrieved. Ask which contract or node verifies the proof of state correctness. If a project answers only the third, it has not answered the first two. That is why Buterin’s essay talks about block construction and network data distribution alongside cryptography rather than replacing the entire system with one magic proof.
The base layer cannot borrow every property from existing rollups
ZK rollups already submit validity proofs to Ethereum under their own contracts and rules. The Ethereum documentation on ZK rollups describes an operator creating proof for a batch and a verifier contract accepting a new state root only after verification. That is useful precedent for proving computation. It does not mean Ethereum’s base layer has already shifted all execution validation to such proofs.
The scope differs. A rollup proves its own state transition under its own virtual machine and contract, while Ethereum’s base-layer verifier would have to check the protocol’s block execution in a way client teams accept. A mismatch between a rollup’s custom logic and Ethereum mainnet’s execution rules is not a detail a faster prover can wish away. Proof systems must also remain robust through protocol upgrades, new transaction types and adversarial inputs.
An application can outsource its arithmetic to a coprocessor and provide a result with a proof, but the base chain still decides whether to accept the public inputs, store commitments and settle the resulting state. An app may be able to choose its own prover design; a base-layer rule requires broad coordination across clients and validators. Buterin’s phrase “cryptographic world computer” is useful as an architectural direction, not a promise that a single proving service will run all of Ethereum.
There is an apparent contradiction worth resolving. If nodes stop re-executing, how does anyone find a bug in the computation being proved? One answer is that developers can run independent full execution and compare it with proof results during development and after deployment. Another is multiple proof implementations and formal checks of circuits. The exact Ethereum design has not been finalised. A protocol that reduces required re-execution does not forbid people from performing extra checks; it changes what every ordinary validating node must do for consensus.
The Foundation’s September protocol priorities update treats an L1 zkEVM and formal verification as major workstreams. That is evidence of active engineering, not a settled launch date. The security standard is high because an error in a base-layer proof system would affect the foundation on which other applications depend.
Proofs may improve verification while the state problem grows
Buterin names access to a very large shared state as a particularly difficult unresolved problem. Crypto.news examined his separate proposal for proof-based mempool scaling, which targets a different bottleneck from final state execution. A proof can attest to a computation, but the prover must obtain the information on which that computation depends: balances, contract storage and other account state. If many transactions touch the same state at once, splitting computation across machines becomes harder. A payment from one account and a swap touching a liquidity pool cannot both be finalised from inconsistent snapshots.
The essay suggests that applications may place ordering and non-commutative state changes onchain while aggregating other computation before inclusion. That is an architectural incentive, not a binding rule for developers today. “Non-commutative” means that changing the order changes the outcome. Two people buying from the same thin pool can get different prices depending on which order is processed first. No proof makes those two orders economically equivalent.
This is a useful counterweight to a simplistic promise of free scale. Parallel work is easier when tasks can be separated safely. Shared state creates dependencies. A prover may execute many independent computations quickly and still wait on access to contested state or a block builder’s ordering choice. Improving proof speed alone does not solve database contention, censorship or the cost of making enough information available to other participants.
In Buterin’s view, a stronger decentralised middle layer could process work in parallel and in some cases protect metadata about where requests originate. Such infrastructure might improve performance or privacy, but it would have to specify how data are distributed, who can join and which failures have an escape path. Privacy for a user’s payment is not an automatic consequence of using a validity proof. Public inputs, wallet activity and network metadata can still disclose information unless a system protects those parts too.
Independence can be measured before the final fork
“Anyone can verify” has practical conditions. An ordinary node needs the verifier code, the relevant public inputs, a connection to the chain’s accepted state and enough processing capacity to complete the check within protocol time limits. If a proof takes seconds to check on a modest machine but hours to produce on expensive hardware, the system may achieve broad verification with narrow production. That can be an acceptable engineering trade-off for correctness, provided a producer’s outage does not become a permanent block on settlement.
The experiment is straightforward in outline. Run verifier software from more than one client team against the same valid block proof and confirm that they accept it. Supply altered public inputs and confirm rejection. Ask whether separate proving teams can produce accepted proofs for the same rules, how quickly they can do it and what hardware each requires. Repeating this on a public test network under heavy load would say more about readiness than a laboratory demonstration of one fast proof. The exact Ethereum acceptance criteria remain subject to protocol work; these are observable questions, not official pass thresholds.
Proof generation has another failure mode that a validity check cannot catch by itself. A prover might decline to make a proof for a proposed block. A verifier cannot accept a proof that has not arrived. A design can address that by allowing multiple independent provers, a fallback execution path, adjusted timing or other mechanisms. The choice will affect complexity, cost and time to finality. Ethereum’s current base-layer rules should not be described as having selected one of those future solutions merely because a roadmap says proof verification is a goal.
Independence also means a user can obtain the information needed to verify their own claim to assets. A proof that a state root followed code is powerful, but a user who cannot reconstruct the path from their account data to that root still relies on an intermediary for a practical balance check. PeerDAS makes blob data availability less demanding for each node while relying on distribution and sampling across the network. Application data kept elsewhere need their own availability guarantees. The chain’s proof verifier cannot compel an external operator to publish withheld records.
Finally, the program being verified must be the program users think it is. A public hash of verifier code, a documented upgrade process and independent tests of circuit behavior let outsiders compare the advertised rule with what nodes actually enforce. Formal verification can narrow the chance of a logic error, but it too starts with a specification written by humans. The checkable result is not “cryptography solved trust.” It is that a specified claim can be independently rejected when its evidence is invalid, without every node paying the full cost of producing it.
Hegota is a marker, not a 2030 release guarantee
Buterin refers to Hegota, a fork planned for 2027, as possibly the last upgrade whose components would be familiar to a 2015 Ethereum observer. Later work in his account would involve recursive STARKs, formal verification, optimised consensus and quantum safety. Crypto.news reported the separate 2029 quantum target as a planning goal. Neither the essay nor a target date proves that each proposed component will be ready and adopted on schedule.
Ethereum upgrades require specifications, client implementations, test networks, security reviews and coordination among participants. A strawmap is a map of research and candidate milestones, not an onchain enactment. One can verify that PeerDAS is deployed by looking at the Fusaka release and current node rules. One cannot verify a future general base-layer zkEVM by looking at an essay’s blue 2030 column. Evidence will arrive in public specifications and tests first, then a concrete fork plan and production activation.
The argument for Buterin’s approach is strong. If verification becomes cheap and data can be sampled safely, more users can independently check a larger system without buying machines proportionate to all its computation and data. The challenge is just as real: the proving stack must be secure, competitively produced and fast enough to keep the system live, while data and ordering remain accessible. A network with cheap verification but a single indispensable prover or sequencer may still be fragile.
The essay does not settle who will build every proof or which proof system wins. It does identify a test that matters for users: can an ordinary independent participant reject a bad result, recover the data needed to know their own state and submit a transaction despite any one operator? Each answer requires a separate mechanism. The cryptographic check is powerful precisely because it can be repeated by people who did not do the heavy work.
What to watch
- L1 zkEVM specifications. Look for a concrete verifier, public input format and execution rules accepted across clients.
- Prover diversity. Multiple independent implementations and measured hardware needs will test whether proof production has a single chokepoint.
- PeerDAS measurements. Check blob throughput and node bandwidth as parameter increases follow the December 2025 launch.
- Hegota decisions. A final fork scope matters more than candidate features in a draft roadmap.
- Data and ordering safeguards. Inspect whether rollups and future base-layer designs preserve independent reconstruction and transaction inclusion.
FAQ
What did Vitalik Buterin propose for Ethereum in 2030?
His Sept. 27 essay describes a network using more data sampling, cryptographic verification and decentralised off-chain computation. It is a vision, not a finalised protocol specification.
Is PeerDAS already live on Ethereum?
Yes. The Ethereum Foundation says the December 2025 Fusaka upgrade brought PeerDAS to mainnet, changing how validators handle rollup blob data.
How much blob data does a regular node receive under PeerDAS?
Ethereum’s documentation says extended data is split into 128 columns and a regular node joins at least 8 column subnets. That is one sixteenth of extended data by column count, subject to the protocol’s coding and sampling design.
Who creates a validity proof?
A prover executes the relevant computation and constructs proof of the claimed result. The identity and number of provers depend on the particular rollup or future base-layer design.
Who checks the proof?
A verifier contract or validating node checks it against the agreed verification rules and public inputs. The goal is that independent parties can do this more cheaply than repeating the whole computation.
Does a valid proof guarantee my transaction gets included?
No. A proof can certify correct execution of included transactions, while a sequencer or block builder may still affect ordering and access. Inclusion requires its own safeguards.
Does a ZK proof guarantee that I can recover my funds?
Not alone. Users also need access to relevant state data and a workable exit mechanism. A validium can use validity proofs while keeping data outside Ethereum, creating a different availability risk.
Is Ethereum switching all validation to proofs by 2030?
There is no adopted deadline for that complete change in the sources reviewed. PeerDAS is live, while base-layer execution proofs remain a development objective. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of September 28, 2026.
