Vitalik Buterin outlines the technical evolution of Ethereum, revealing the key transformations of blockchain from 2015 to 2030. Cryptography evolves from proof of work to proof of stake, and then to deeply optimized proof of stake; verification mechanisms develop from download-and-re-execute to PeerDAS sampling and SNARK verification; and block construction shifts from a single miner to multi-party co-building. The article points out that Ethereum will transition from a traditional blockchain to a “cryptographic world computer,” where zero-knowledge proofs will play a core role, and decentralization itself can become a performance advantage. In the future, the programming paradigm will change: only core information is placed on-chain, while the rest is aggregated off-chain. After the Hegota hard fork, Ethereum will introduce recursive STARKs, automated formal verification, and quantum-resistant upgrades, enabling a more secure, cheaper, and more scalable computing system.
Article author: Vitalik Buterin
Written/compiled by: Saoirse, Foresight News
We call Ethereum “a blockchain,” as if it were fundamentally similar to the Bitcoin created by Satoshi Nakamoto in 2009. The two are indeed similar in many ways; even the “simplified Ethereum” planned according to Strawmap in the future retains the core characteristics of a blockchain. But at the same time, this technology has undergone enormous evolution over the past fifteen years, and it will continue to iterate over the next three years. By then, it will be very reasonable to describe Ethereum’s evolving form as a system with properties that are completely different.
Today’s Ethereum has general-purpose computation, an incentive-compatible proof-of-stake mechanism, on-chain applications with zero-knowledge proofs, and a two-layer network that enables scalability and privacy. In the future, Ethereum’s computing capacity can flexibly adjust between extreme scalability and full generality. It will support multi-party block construction modes, deeply optimized proof-of-stake, and zero-knowledge proofs built directly into the underlying protocol to play a core role.
This article will, from a technical perspective and from the perspective of system features available to users, outline some of the most important fundamental differences between 2010s blockchains and 2030s blockchains.
Differences between Bitcoin and Ethereum
This figure is adapted from the transaction diagram in Satoshi Nakamoto’s Bitcoin paper. It shows the classic chained-signature transfer model and labels a new scheme in which signatures can be aggregated off-chain, with only a single record submitted on-chain—often with zero-knowledge proofs replacing traditional signatures.
This figure compares Bitcoin’s PoW mechanism with Ethereum’s post-2022 PoS. Previously, it relied on iterating a nonce to find a hash that meets the conditions and a single participant produced the block. Now it uses validator signatures, and in the future it will also rely on FOCIL to enable multi-role decentralized block co-building; components such as transaction-related signatures and proofs will be split and aggregated in the mempool.
This figure excerpted from the Bitcoin white paper shows the six-step process of network operation and points out that its native design lacks capabilities such as mempool aggregation, distributed block construction, sender anonymization, etc. It also explains the improvements of Ethereum PoS and PeerDAS: block building and fork choice are separated, nodes only need to download a small part of a block, and parallel proofs reduce consensus latency.
This figure compares the Bitcoin white paper’s Merkle tree pruning scheme with Ethereum’s new storage strategy: in Bitcoin, spent transactions can be deleted to free up disk space; in the future Ethereum will further reduce storage by separating state and history and using SNARK proofs, while also introducing distributed state storage and optimizing storage media through diversification.
This figure interprets Bitcoin’s privacy approach: relying only on public-key anonymity can hide identities but leaves transaction amounts public. Under modern data analytics, this is not sufficient. ZK-SNARKs, FOCIL, and EIP-8288 can build stronger programmable privacy, but we also need to address the privacy of query/read operations and the privacy of network broadcast.
Almost every chapter of the white paper will undergo major changes. To keep things concise, we’ve summarized them in the table below:
Almost all of the core attributes contained in the concept of blockchain have either already undergone fundamental changes or are about to see underlying transformations:
Verification mechanism: download and re-execute → PeerDAS sampling and SNARK verification
Consensus mechanism: Proof of Work → Proof of Stake → deeply optimized Proof of Stake
Block construction permissions: a single miner generates blocks → multiple parties jointly construct blocks
Borrowing AI’s tone, the only objectively trustworthy conclusion (well, the core point) is this: calling modern cryptographic networks like Ethereum, after a streamlined upgrade, “blockchains” for the most part is largely due to historical reasons. In reality, it’s a hybrid architecture that combines two major systems:
Satoshi Nakamoto’s core idea
New powerful cryptographic tools born from fifty years of academic research—none of these existed yet in 2009, or else they weren’t mature.
How much cryptography is hidden in the cryptographic stack? A comparison across 2009, 2020, and 2030
Cryptography is not the only key discipline. Formal verification, database theory, improved P2P networking theory, information theory, economics, and more are equally important. But all these technologies can be compatible with this foundational logic: everyone tries to generate the next block containing a valid proof of work; once someone successfully generates it, they broadcast it; everyone else downloads the block and re-executes it—looping again and again. Transformations at the cryptography layer are completely different.
So what does all of this mean for users? The most important takeaway is that the dimensions along which users must make trade-offs are changing dramatically:
When developing applications, the structure of computation becomes crucial. In a simple blockchain, one byte is one byte, and one unit of Gas is one unit of Gas. But in a future architecture: if you cram all computation into a single transaction that is hard to decompose and executes serially, then the cost for the same amount of computation will be much higher; however, if you split computation into well-packaged, independent tasks that support parallel execution or can be pre-pruned, and ideally complete the preprocessing before the transaction is submitted into the final block, the cost will drop significantly. This will change the incentives for developers, and over time, the architectures of all Ethereum applications will shift accordingly: in the long run, we may form a new programming paradigm—only the core information that describes non-commutative state changes and the execution order is written on-chain, while all other data is aggregated before being included in blocks.
Organizing computations appropriately can help the blockchain focus on completing its core tasks.
Perhaps the most significant change lies in the network’s decentralization: it’s no longer just a performance burden borne for the sake of security and robustness; in some limited scenarios, decentralization itself can even become a performance advantage. A decentralized network can store massive data in parallel; large-scale computations can be executed in parallel, and many computations can be completed directly in a transaction’s mempool. In some scenarios, decentralization can also enhance privacy, because only a decentralized network can effectively hide metadata (for example, the source of data and requests).
As early as the mid-2010s, this was Ethereum’s early vision: decentralization should be used not just to improve robustness, but also to enhance scalability. Centralized systems can improve performance by splitting tasks among multiple participants, and blockchains can do the same. Back then, the plan could not be realized; the core shortcoming was the verification mechanism. After splitting tasks, you must verify that each subtask was executed correctly. Early proposals tried to solve the problem with randomly sampled committees, but they all ran into the same bottleneck: first, committee deployment is complex, costly, and would significantly increase latency; second, once a committee fails, there’s no recovery mechanism. Today, with modern cryptography, this problem is solved—and the additional overhead introduced by the scheme is decreasing month by month.
Another direction worth关注 for decentralization to improve performance is latency. Ethereum itself can never match centralized servers in latency, but the infrastructure built on top of Ethereum can.
Overall, building a powerful decentralized intermediary layer between users and the main chain (a layer that is itself not a blockchain) can greatly enhance Ethereum’s capabilities, while not breaking the core characteristics of the underlying blockchain.
Looking further into the distant future, Ethereum may also undergo another round of transformation—program obfuscation (iO) might emerge. The ultimate goal in this area is that mature, usable obfuscation techniques can eliminate the trade-off between privacy and generality. You could achieve fully general computation involving any number (asynchronous) of participants in a fully secure cryptographic form. Even weakened versions of obfuscation techniques would have many deployment scenarios, such as an encrypted transaction mempool. Yet all the conclusions proposed in this article will already hold true before this technology becomes practical.
This is the cryptographic world computer: Ethereum is no longer just a ledger where developers can arbitrarily write computation tasks and data and then execute them. The new architecture will fuse together the blockchain, cryptographic privacy, cryptographic verification, and powerful decentralized off-chain components into a single system.
Even with the design fully realized, there are still many challenges. Making zero-knowledge proofs efficient and secure enough is not easy, but it’s a packaged complex problem, and the industry has already been optimizing it at scale with AI tools. More difficult and systematically complex problems—most likely the management of massive state and parallel access—are still emerging. Many solution ideas have already surfaced, but they still need continual refinement, especially as we learn more about which applications will be running in the future.
Looking at the Strawmap roadmap, you can see that the Hegota hard fork planned to go live next year is very likely Ethereum’s last “regular hard fork.” Its functions and technologies will still feel familiar to developers in 2015. After Hegota, all upgrades will include recursive STARKs, automated formal verification, highly optimized consensus algorithms, and system-wide post-quantum upgrades. The deployment of PeerDAS marks Ethereum’s transformation: evolving from a simple blockchain into a system with vastly more capabilities. After the Hegota upgrade, this transformation will become the main thread of Ethereum’s development. The end goal: to achieve a highly secure computing system that is cheaper, more scalable, and offers better privacy than the previous generation of technology. This is the cryptographic world computer.