Ethereum's 2030 vision delegates work to cryptographic proofs—who verifies the results?
Vitalik Buterin’s vision, proposed on September 27, describes how Ethereum will transition from a system where each validator repeats massive amounts of work to one that can sample data and use compact proofs to verify execution results. Some components of PeerDAS are already live, while broader execution layer changes are still under development. Proofs can demonstrate that a computation followed established rules, but users still need data, a way to submit transactions, and a protocol to determine which results ultimately prevail.
- Vitalik Buterin published "The Cryptographic World Computer" on September 27, 2026.
- Ethereum brought PeerDAS to mainnet with the Fusaka upgrade in December 2025.
- PeerDAS splits the expanded blob data into 128 columns for network distribution and sampling.
- According to Ethereum's specifications, a regular node must subscribe to at least eight subnets.
- The proposed Ethereum proof-of-execution for 2030 remains future work and differs from existing rollup proofs.
There are two answers to the question in the title. The prover generates a cryptographic proof; the verifier—any verification node running the relevant software—checks that proof against rules and public inputs. Ethereum’s underlying zkEVM roadmap indicates that verification should be significantly cheaper than re-executing each transaction. However, determining whether a proof is valid does not alone resolve whether the transaction data is available or whether an operator might withhold user transactions.
Buterin’s September 27 article, “The Cryptographic World Computer,” portrays the goal as a combination of blockchain, cryptographic privacy and verification, and decentralized off-chain components. He contrasts the traditional “download and re-execute” model with a mode in which nodes sample data and verify proofs. He also outlines other potential changes to consensus and block construction. This is a personal technical vision, not a finalized upgrade specification approved by all Ethereum client teams.
It is crucial to distinguish between “what already exists” and “what is envisioned.” According to the Ethereum Foundation’s protocol update from February 2026, PeerDAS was deployed alongside the Fusaka upgrade in December 2025. The Foundation states that validators now sample blob data rather than downloading all of it. However, a network-wide switch to verifying succinct execution proofs within the underlying blocks has not been described as already deployed. When readers hear “Ethereum will verify proofs by 2030,” they should ask: Which type of proof? Which computations does it cover? And which parties can independently verify it?
PeerDAS checks data availability, not every computation.
The deployed component is PeerDAS, or Peer-to-Peer Data Availability Sampling. Rollups place transaction data into Ethereum’s blob space, allowing other participants to extract sufficient information to reconstruct the state and enforce operators’ compliance with rules. Previously, requiring every node to download every blob made larger data volumes prohibitively expensive for ordinary validators. Sampling instead requires nodes to compare small data chunks with cryptographic commitments, while the network distributes enough encoded fragments to enable reconstruction.
Ethereum's documentation states that the expanded blob data is divided into 128 columns. Ordinary nodes join at least 8 randomly selected column subnets. Eight divided by 128 equals one-sixteenth of the expanded data. Due to the redundancy introduced by encoding, this amount corresponds approximately to one-eighth of the original data volume, as described in the documentation. These figures refer to the default data workload for nodes, not to the idea that a single node can independently store all rollup history at one-eighth the cost.
Like Reed-Solomon coding, encoding generates redundant data fragments, and cryptographic commitments help nodes verify whether the sampled fragments belong to the published data. Sampling provides participating nodes with a probabilistic guarantee of availability, but it cannot replace execution verification. Even if a batch of transactions is fully available, it may contain invalid state transitions. Similarly, a valid proof of state transitions is insufficient for users to reconstruct account states if the data is withheld beyond the availability guarantee.
The Ethereum Foundation stated that Fusaka increases the theoretical blob capacity by eight times. The term "theoretical" is crucial: actual sustained throughput depends on planned parameter upgrades, network conditions, and rollup usage. Crypto.news previously explained how rollups utilize Ethereum’s data layer. Buterin’s new article views PeerDAS as the first visible step toward a system of "more verification, less duplication"; it should not be rewritten as the final execution proof upgrade.
The prover does the heavy lifting; independent nodes are responsible for verification.
In a proof-based execution model, someone still needs to execute transactions and construct evidence about the results. This role may require expensive specialized hardware and software. Succinct proofs enable verifiers to check whether the claimed state changes followed the program and protocol rules under the promised inputs at a much lower cost. The mathematical verification does not require verifiers to trust the company that generated the proof.
However, this statement comes with prerequisites. Validators must run the correct proof system, using the proper verification key, public inputs, and agreed-upon execution rules. An incorrect circuit could still perfectly prove an incorrect statement. Vulnerabilities in client implementations might accept proofs that should be rejected. An upgrade key that allows modification of verification code without robust controls could also undermine this guarantee. In active protocols, independent implementations and review are just as important as fast proof generation.
The Ethereum L1 zkEVM roadmap page describes a future in which nodes verify block execution proofs instead of re-executing every transaction. The goal is to reduce the resource cost of verification. If proof verification remains feasible on ordinary hardware, it will make it easier for more people to check blocks. However, this does not mean that every household can generate block proofs, nor does it imply that proof production will be evenly distributed.
Crypto.news has reported on hardware competition surrounding proof generation. The truly meaningful distinction is: who can generate proofs within the time requirements of the chain, and who can verify proofs at low cost. Proof generation may become concentrated in the hands of companies with specialized hardware, but this does not automatically enable those companies to forge valid state transitions. It may still introduce liveness dependencies: if too few participants can generate proofs in time, block production or finality may slow down—even though the proof system remains mathematically sound. This is a different risk than accepting invalid proofs.
Therefore, verification problems have both mathematical and human answers. Developers design the circuits, researchers audit the circuits, the client team implements the circuits, node operators run the validators, and participants decide whether to accept protocol upgrades. Buterin can suggest directions, but he cannot unilaterally ensure that future validators are both secure and mandatory for the network.
The word "proof" often blends three types of commitments.
Imagine a user sending a payment via a rollup. The transaction must be included in an ordered batch, and the data for that batch must remain available according to the model chosen by the rollup. Finally, the resulting state changes must adhere to the rules. Ordering, availability, and correctness are three distinct commitments. Correctness proofs apply only to the final state in a specific computation. PeerDAS addresses the availability of Ethereum blob data, while sequencers or block building mechanisms determine which transactions are included and in what order.
Crypto.news previously analyzed the sequencer as an independent control point. Even if the proof is fully valid, it only demonstrates that a batch was processed according to the rules, not that the operator did not exclude any user’s transaction. Users may have escape or forced-inclusion pathways, depending on the rollup’s design, but the proof itself does not enforce fair access. The sequencer can also reorder transactions while still generating valid state transitions. The proven proposition should not be mistaken for all the market properties users may desire.
The data layer is similarly prone to confusion. Ethereum’s documentation on validium describes a system that uses validity proofs but does not publish transaction data to the Ethereum mainnet. While the execution may be correct for validators, a data availability failure prevents users from reconstructing the state or withdrawing funds as expected. Rollups that publish sufficient transaction data to Ethereum have a different availability model. Referring to both simply as “ZK” obscures the critical difference in users’ ability to recover their account state without operator assistance.
The simplest way to test this is with a three-column mental checklist: Ask who puts transactions into batches. Ask where the data needed to reconstruct balances can be retrieved. Ask which contract or node verifies the proof of correct state. If a project only answers the third question, it has not addressed the first two. This is why Buterin’s article discusses block building and network data distribution alongside cryptography, rather than replacing the entire system with a magical proof.
The base layer cannot borrow all properties from existing rollups.
ZK rollups have submitted validity proofs to Ethereum according to their respective contracts and rules. Ethereum’s documentation on ZK rollups describes how operators generate proofs for a batch, and how the verification contract accepts a new state root only after successful validation. This provides a useful precedent for proof computation, but it does not mean that Ethereum’s underlying system has transferred all execution verification to such proofs.
The scope differs. Rollups prove state transitions within their own virtual machine and contracts, while Ethereum's underlying validators must verify block execution in a manner accepted by client teams. The difference between a rollup's custom logic and Ethereum mainnet execution rules is not a minor detail that can be resolved by a faster prover. The proof system must also remain robust during protocol upgrades, with new transaction types, and under adversarial inputs.
Applications can outsource computation to coprocessors and provide results with proofs, but the underlying chain still decides whether to accept public inputs, store commitments, and settle the final state. Applications may choose their own prover designs; however, the underlying rules require broader coordination between clients and verifiers. Buterin’s concept of a “cryptography world computer” is better suited as an architectural direction rather than a single proof service running the entire Ethereum.
Here is a seemingly contradictory but important question to clarify: if nodes no longer re-execute computations, who detects vulnerabilities in the proven calculations? One answer is that developers can independently run full executions during development and after deployment, then compare the results with the proofs. Another answer is to employ multiple proof implementations and perform formal verification of the circuits. Ethereum’s specific design has not yet been finalized. A protocol that reduces the need for re-execution does not prohibit additional checks—it only changes what each ordinary verification node must do to reach consensus.
The foundation's September protocol priority update lists L1 zkEVM and formal verification as key workflows. This indicates that engineering efforts are still underway, rather than having a confirmed launch date. The high security standards are in place because any error in the underlying proof system could affect the foundational infrastructure upon which other applications rely.
Proof may improve verification, but state issues are also growing.
Buterin noted that accessing a very large shared state is a particularly challenging and unresolved issue. Crypto.news previously analyzed his other proposal on proof-based mempool scaling, which targets a different bottleneck than final state execution. Proofs can verify a computation, but the prover must first obtain the information on which that computation depends: balances, contract storage, and other account states. If many transactions simultaneously access the same state, distributing the computation across multiple machines becomes more difficult. Payments from one account and swaps that interact with liquidity pools cannot be finalized simultaneously based on inconsistent snapshots.
This article suggests that applications might place sorting and non-commutative state changes on-chain, while aggregating other computations before inclusion. This is an architectural incentive, not a rule that currently constrains developers. “Non-commutative” means that changing the order changes the outcome. Two users buying from the same shallow pool may face different prices depending on the sequence of their transactions. No proof exists that these two sequences are economically equivalent.
This serves as a check against the simple promise of “free scaling.” Tasks are easier to process in parallel if they can be safely separated; shared state introduces dependencies. Provers may be able to execute many independent computations quickly, but they may still need to wait for access to contested state or for block builders’ ordering decisions. Simply increasing proof speed does not resolve database contention, censorship, or the cost of providing sufficient information to other participants.
In Buterin’s view, a stronger decentralized middleware layer can process work in parallel and, in some cases, protect metadata about the source of requests. Such infrastructure may enhance performance or privacy, but it must clearly define how data is distributed, who can join, and what escape routes exist for failures. Privacy paid for by users is not an automatic result of using validity proofs. Unless the system also protects public inputs, wallet activity, and network metadata, these components may still leak information.
Independence can be tested before the final fork.
“Anyone can verify” is conditionally practical. Ordinary nodes require the verifier code, relevant public inputs, connectivity to the on-chain accepted state, and sufficient processing power to complete the check within the protocol’s time limits. If a proof can be verified in seconds on a standard machine but takes hours to generate on expensive hardware, the system may enable widespread verification while allowing only a few to generate proofs. As long as a producer’s downtime does not permanently block settlement, this represents an acceptable engineering trade-off for correctness.
The experimental approach is straightforward: run the validator software from multiple client teams on the same valid block proof to confirm they all accept it; provide tampered public inputs to verify they are rejected; ask different proof teams whether they can generate acceptable proofs under the same rules, how quickly they can do so, and what hardware each requires. Repeat these tests under high-load conditions on a public testnet—this better demonstrates readiness than simply demonstrating a fast proof in a lab setting. Ethereum’s specific acceptance criteria still depend on protocol work; these are observable questions, not official pass/fail thresholds.
There is another failure mode in proof generation that cannot be captured by validity checks alone: the prover may refuse to generate a proof for the proposed block. A validator cannot accept a proof that has not yet arrived. Design solutions can address this by allowing multiple independent provers, setting up fallback execution paths, adjusting timing, or other mechanisms. The choice among these options affects complexity, cost, and finality time. Simply because the roadmap lists proof verification as a goal does not mean that Ethereum’s current underlying rules have already selected one of these future solutions.
Independence also means that users can access the information needed to verify their claims to assets. A proof that the state root adheres to the code is strong, but if users cannot reconstruct the path from their account data to that state root, they still rely on intermediaries for actual balance verification. PeerDAS reduces the burden on each node for blob data availability through network distribution and sampling, but application data stored elsewhere still requires its own availability guarantees. On-chain proof verifiers cannot compel external operators to disclose withheld records.
Finally, the verified program must be the one the user believes it to be. Publicly available hashes of the verifier code, documented upgrade procedures, and independent testing of circuit behavior enable outsiders to compare the advertised rules with the actual rules executed by the node. Formal verification reduces the likelihood of logical errors, but it itself begins with specifications written by humans. The verifiable outcome is not “cryptography solves the trust problem,” but rather: when evidence is invalid, a clear claim can be independently rejected without requiring every node to bear the full cost of generating it.
Hegota is a marker, not a guarantee of release in 2030.
Buterin noted that the Hegema fork planned for 2027 may be the last upgrade familiar to Ethereum observers from 2015. According to him, subsequent work will involve recursive STARKs, formal verification, optimized consensus, and quantum resistance. Crypto.news previously reported that the 2029 quantum goal is a separate planning objective. Neither this article nor any specific target date guarantees that each proposed component will be ready and adopted on schedule.
Ethereum upgrades require specifications, client implementations, testnets, security audits, and coordination among participants. The roadmap is a map of research and candidate milestones, not an on-chain execution plan. PeerDAS deployment can be verified by reviewing Fusaka releases and current node rules; however, the future general-purpose zkEVM base layer cannot be verified solely by a blue 2030 column in an article. Evidence will first appear in the form of public specifications and tests, followed by specific fork plans and mainnet activation.
Buterin’s argument along this path is strong: if verification becomes cheap and data can be securely sampled, more users can independently verify a larger system without needing to purchase machines equivalent in computing power and data capacity. The challenges are equally real: the proof stack must be secure, competitively generate proofs, and be fast enough to keep the system live, while ensuring data and ordering remain accessible. A network with very low verification costs but only a single indispensable prover or sequencer could still be vulnerable.
This article does not conclude who will construct each proof or which proof system will prevail. It does, however, highlight a critical test for users: Can ordinary independent participants reject incorrect results, retrieve the data necessary to know their own state, and submit transactions even outside the control of any single operator? Each of these requires a separate mechanism. The power of cryptographic checks lies precisely in their ability to be repeatedly verified by those not burdened with heavy computational tasks.
Worth paying attention to
- L1 zkEVM specification. Focus on whether specific verifiers, public input formats, and execution rules will be adopted by various clients.
- Proof diversity. Multiple independent implementations and measurable hardware requirements help identify whether proof production has a single point of bottleneck.
- PeerDAS metrics. After the parameter increase following the December 2025 launch, monitor blob throughput and node bandwidth.
- Hegota decision. The final fork scope is more important than the candidate features in the draft roadmap.
- Data and ordering guarantees. Verify that the rollup and future underlying design preserve the ability to independently reconstruct and include transactions.
Frequently Asked Questions
What did Vitalik Buterin propose for Ethereum in 2030?
His article on September 27 depicted a network that relies more on data sampling, cryptographic verification, and decentralized off-chain computation. This is a vision, not a finalized protocol specification.
Has PeerDAS been launched on Ethereum?
Yes. The Ethereum Foundation stated that the Fusaka upgrade in December 2025 brought PeerDAS to mainnet, changing how validators process rollup blob data.
Under PeerDAS, how much blob data will ordinary nodes receive?
The Ethereum documentation states that the extended data is divided into 128 columns, and regular nodes join at least 8 column subnets. In terms of column count, this amounts to one-sixteenth of the extended data, though it is subject to the protocol's encoding and sampling design.
Who generates the validity proof?
Provers perform the relevant computations and construct proofs for the claimed results. The specific individuals and number of provers depend on the design of a particular rollup or its underlying architecture.
Who checks the proof?
Validator contracts or validator nodes check the input against agreed-upon validation rules and public inputs. The goal is to allow independent parties to perform this verification at a cost far lower than repeating the entire computation.
Can a priority proof guarantee that my transaction will definitely be included?
No. Proof can verify the correct execution of included transactions, but the sequencer or block builder may still influence ordering and access. Inclusion itself requires separate safeguards.
Can a ZK proof guarantee that I will definitely get my funds back?
Proof alone is not sufficient. Users also need access to relevant state data and a viable exit mechanism. Validiums can use validity proofs while keeping data off Ethereum, introducing different data availability risks.
Will Ethereum switch all validation to proof-of-stake by 2030?
Among the sources reviewed, no adopted deadline has been established to complete this comprehensive change. PeerDAS is already live, while the underlying execution proof remains a development goal. This article is provided solely for educational and informational purposes and does not constitute investment advice.
Disclaimer: This article is provided solely for informational and educational purposes and does not constitute financial or investment advice. The data presented reflects regulatory filings and reports available at the time of writing and may change with subsequent disclosures. The content herein does not constitute an offer, solicitation, or recommendation to buy, sell, or hold any security or asset. Always conduct your own research. Information current as of September 28, 2026.