Vitalik Buterin says Ethereum is moving far enough from the original blockchain model that the label itself may soon describe the network only in a historical sense.
In a written expansion of his keynote at Shanghai Blockchain International Week, Buterin argues that Ethereum still retains core blockchain traits, but the system has changed dramatically over the past 15 years and will keep changing over the next three. By that point, he writes, it would be reasonable to describe the form Ethereum is evolving into as a fundamentally different kind of system.
The article was translated by Saoirse and published by Foresight News. An editor’s note says the written version adds technical comparisons and tables to explain how Ethereum is shifting from a traditional ledger toward what Buterin calls a “cryptographic world computer,” with proof-of-stake, zero-knowledge proofs and PeerDAS at the center of that transition.
From the Bitcoin white paper to Ethereum’s next form
Buterin starts with the common habit of placing Ethereum in the same category as Bitcoin, the system introduced by Satoshi Nakamoto in 2009. He does not reject that comparison outright. The two systems do share important features, and even a “lean Ethereum” built under the Strawmap plan would still preserve the core characteristics of a blockchain.
Still, he says the gap is widening. Ethereum today already includes general-purpose computation, proof-of-stake, onchain applications that use zero-knowledge proofs, and layer-2 networks built for scaling and privacy. The Ethereum he describes for the years ahead goes further: computation that can be tuned between extreme scalability and full generality, several forms of multi-party block construction, a deeply optimized proof-of-stake design, and zero-knowledge proofs built directly into the protocol as a core component.
The article is organized as a comparison between blockchains of the 2010s and blockchains of 2030, viewed both from the technical side and from the system properties users will actually experience. To make that case, Buterin walks section by section through the original Bitcoin white paper and contrasts it with Ethereum in 2015, 2025 and 2030.
Transaction design, consensus and network operation are all changing
On transaction mechanics, the article adapts the chained-signature transfer model from the Bitcoin white paper. Buterin says newer designs can aggregate signatures offchain and submit only a single record onchain. In many cases, zero-knowledge proofs can also replace traditional signatures.
On consensus, he compares Bitcoin’s proof-of-work model with Ethereum’s post-2022 proof-of-stake system. The old design relied on repeated nonce iteration to find a qualifying hash, with one participant producing the block. In the PoS model, validators sign blocks instead. Looking ahead, he says Ethereum will also use FOCIL to support block construction shared across multiple roles, while signatures, proofs and other transaction-related components are split and aggregated in the mempool.
He makes a similar point about network operation. Drawing from the six-step process in the Bitcoin white paper, Buterin says the native design lacks mempool aggregation, distributed block construction and sender anonymization. Ethereum’s PoS model and PeerDAS, in his description, improve on those limits by separating block construction from fork choice, letting nodes download only a small part of a block, and using parallel proofs to reduce consensus delay.
Storage and privacy are being rebuilt as well
Storage is another area where he sees a break from early blockchain assumptions. The article compares Bitcoin’s Merkle-tree pruning approach with Ethereum’s newer storage strategy. Bitcoin can free disk space by deleting spent transactions. Future Ethereum, he writes, reduces storage needs through state-history separation and SNARK proofs, while also introducing distributed state storage and optimization across different storage media.
Privacy changes even more sharply. Buterin says the privacy model in the Bitcoin white paper depends mainly on pseudonymity through public keys. That can hide identity, but transaction amounts remain public, and he argues that this is no longer enough in an era of modern data analysis. In the framework he outlines, ZK-SNARKs, FOCIL and EIP-8288 can provide stronger programmable privacy, though read-query privacy and network-broadcast privacy still need to be solved.
His broader conclusion is that nearly every chapter of the Bitcoin white paper would look very different under present and future conditions. To condense that point, the article lists several core shifts:
- Verification moves from downloading and re-executing everything to PeerDAS sampling and SNARK verification.
- Consensus moves from proof-of-work to proof-of-stake, and then to a more deeply optimized proof-of-stake model.
- Block construction moves from a single miner producing a block to multiple parties building it together.
Why “blockchain” may no longer be the full description
Buterin puts the point bluntly: for modern crypto networks such as a streamlined Ethereum, calling them “blockchains” is to a large extent a historical carryover. In his framing, they are really hybrid systems that combine two traditions: Satoshi Nakamoto’s core ideas, and a much newer set of cryptographic tools produced by roughly 50 years of academic research, many of which either did not exist in 2009 or were not mature at the time.
He adds that cryptography is not the only field that matters. Formal verification, database theory, improvements in peer-to-peer networking, information theory and economics all remain important. But those disciplines can still fit within the old logic of block production and re-execution, while the cryptographic shift changes the structure of the system itself.
What this means for users and developers
Buterin then turns to the practical consequences. One of the biggest changes, he says, is that the tradeoffs users and developers need to think about are changing dramatically, especially around computation structure.
In a simple blockchain, a byte is a byte and a unit of gas is a unit of gas. In the architecture he describes for the future, that stops being true in practice. If all computation is packed into a single transaction that is hard to decompose and must run serially, the cost for the same amount of work becomes much higher. If the work is split into well-encapsulated tasks that can be parallelized or pruned in advance, and ideally preprocessed before final inclusion in a block, the cost falls sharply.
That, in his view, will reshape developer incentives and gradually change the architecture of Ethereum applications. He sketches a possible programming model in which only the core information describing non-commutative state changes and execution order goes onchain, while the rest of the data is aggregated before block inclusion. The result would be a blockchain that spends more of its resources on the tasks only it needs to perform.
Decentralization may also become a performance advantage
Another major shift in the article is the role of decentralization. Buterin says decentralization should no longer be seen only as a performance cost paid in exchange for security and robustness. In some limited settings, it can become a performance advantage in its own right.
He points to several reasons. A decentralized network can store large amounts of data in parallel. Large volumes of computation can also run in parallel, and much of that work can happen directly in the transaction mempool. In some cases, decentralization can improve privacy too, because only a decentralized network can effectively hide metadata such as the source of data and requests.
He notes that this was already part of Ethereum’s early vision in the mid-2010s: decentralization was not meant only to improve robustness, but also to improve scalability. Centralized systems can gain performance by splitting tasks across multiple participants, and blockchains should be able to do the same. The reason that idea did not work at the time, he says, was verification.
Once tasks are split, every subtask has to be verified as correctly executed. Earlier approaches tried to solve that with randomly sampled committees, but ran into two bottlenecks: committees were complex and expensive to deploy and added substantial delay, and if a committee failed there was no fallback. Buterin says modern cryptography has now solved that problem, and the extra overhead continues to fall month by month.
He also points to latency as another area where decentralization could help. Ethereum itself will never match the latency of a centralized server, he writes, but infrastructure built on top of Ethereum can. In his description, a powerful decentralized middleware layer between users and the main chain — one that is not itself a blockchain — could greatly expand Ethereum’s capabilities without breaking the core properties of the base chain.
iO, Hegota and the road after the “regular hard fork” era
Looking further out, Buterin says indistinguishability obfuscation, or iO, could trigger another round of change. The ultimate goal in that field, as he describes it, is mature obfuscation technology that removes the tradeoff between privacy and generality, allowing fully general computation in a securely encrypted form with an unlimited number of asynchronous participants. Even weaker versions of obfuscation, he says, could still have practical uses, including encrypted transaction mempools.
He is careful to add that the article’s main conclusions do not depend on iO arriving first.
He sums up the broader design as a “cryptographic world computer.” In that model, Ethereum is no longer just a ledger where developers write data and computation and then execute it. It becomes a system that combines blockchain infrastructure, cryptographic privacy, cryptographic verification and powerful decentralized offchain components.
Buterin also says the design still faces major implementation challenges. Making zero-knowledge proofs efficient enough and secure enough is not easy, though he describes that as an “encapsulated complexity” problem that has already seen large-scale optimization with AI tools. The harder issue, in his view, is likely to be the management and parallel access of massive state. A number of solution paths have already emerged, he writes, but they still need refinement, especially as the industry learns more about the kinds of applications that will run in the future.
Referring to the Strawmap roadmap, the article says the Hegota hard fork planned for next year will most likely be Ethereum’s last “regular hard fork,” with features and technologies that would still look familiar to developers from 2015. Upgrades after Hegota, he says, will include recursive STARKs, automated formal verification, highly optimized consensus algorithms and system-wide quantum resistance.
In Buterin’s telling, the rollout of PeerDAS marks the start of Ethereum’s transition from a simple blockchain into a much more capable system. After Hegota, that transition becomes the main line of Ethereum’s development. The end goal, he writes, is a high-security computing system that is cheaper, more scalable and better for privacy than the previous generation of technology — what he calls the cryptographic world computer.