以太坊的 2030 年愿景将工作转向加密证明。谁来验证结果？

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.

Summary 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.

JUST IN: Vitalik Buterin envisions Ethereum becoming a “cryptographic world computer” by 2030

His vision shifts more computation offchain, with cryptographic proofs allowing the network to verify results without every computer repeating the same work, while also improving… pic.twitter.com/aCMpSto8H5 — crypto.news (@cryptodotnews) September 28, 2026

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.

JUST IN: SharpLink CEO says Ethereum could become a key rail for AI agents

Joseph Chalom told Paul Barron that Ethereum could serve as an “uncensorable neutral rail” and play a very important role in the future of AI agents. pic.twitter.com/KWuOEmrY4W — crypto.news (@cryptodotnews) September 27, 2026

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.

You might also like: Ethereum price could rally to $5,000: Arthur Hayes

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.