Where is the future of Ethereum?

Organized by: KarenZ, Foresight News

A "world computer" does not necessarily need to cram more work into the same chain to become stronger. It can also delegate work outwards and mathematically prove: these tasks were indeed completed according to the rules.

This is the future depicted by Vitalik Buterin during his speech at the 2026 Shanghai Blockchain International Week Summit. As cryptographic tools mature, Ethereum has the opportunity to become a more finely segmented computing network: user devices can first process part of the work, completing verification and aggregation before transactions go on-chain, while the blockchain handles the parts that require confirmation from the entire network.

On September 23, 2026, the summit was held in Shanghai, with Vitalik participating online. Regarding the future development of Ethereum, he intertwined privacy, scalability, and AI into a single vision: the capabilities that cryptography can expand, and AI can help people build and verify these complex systems more quickly.

From "Who can spend money" to "Who can see information"

Vitalik first returned to the original value of blockchain: anyone can participate, users can use the system according to public rules, and do not have to hand over complete control to any single entity.

However, public ledgers also bring a problem: transactions can be verified by everyone, and transaction information is often exposed to all. The absence of real names directly labeled on addresses does not mean that the activities behind them cannot be linked. With the enhancement of data analysis and AI capabilities, merely relying on "addresses are not names" to protect privacy is increasingly insufficient.

In his view, new cryptographic tools are changing the questions that blockchain needs to answer.

Bitcoin primarily establishes rules around a digital asset; Ethereum further allows people to create assets and stipulate how those assets can be used through smart contracts. Their long-term focus has been on: who owns the assets and under what conditions can they be transferred.

Next, the information itself will also become a subject of protection. The code can not only specify asset usage permissions but can also participate in defining the visibility of information: which data needs to be public, which data should be kept confidential, and which participants can gain access.

This is what he refers to as the changes brought by "programmable cryptography." For application developers, privacy has the opportunity to become a part of system design, rather than having to accept the premise of all business data being public from the start.

Let others trust the results without having to lay everything bare

To understand this change, one can start with how blockchain verifies computation.

In traditional practice, validating nodes individually execute transactions and check whether the results are consistent. This method allows for independent verification, but the same work needs to be redone, also limiting the overall computation capacity of the network.

Another method emphasized by Vitalik is to allow computation executors to generate a cryptographic proof after completing work, where other participants confirm that the computation adheres to the rules by checking the proof. For succinct proof systems like SNARK and STARK, verifying a proof can be more efficient than re-executing the original complex computation; when the system has zero-knowledge attributes, it can also hide non-public input information while the proof's conclusion is upheld.

There are two related yet different goals here: one is to reduce redundant computation, and the other is to protect privacy. Using proofs to scale does not automatically keep transactions confidential; privacy still needs appropriate designs from applications and protocols.

He also mentioned fully homomorphic encryption, or FHE. This type of technology allows the computing party to directly work with encrypted data without needing to decrypt it into plaintext first. It provides a technical pathway for "letting others help with computation without handing over the original data."

These tools together expand the design space for applications. In Vitalik's vision, people can more flexibly decide where computation takes place, how results are verified, and what information needs to be seen by whom.

Collaboration has begun even before transactions go on-chain

This division of labor does not only happen between the blockchain and applications. Vitalik particularly emphasized that the process from when a transaction is initiated by the user to when it is written into a block can also undertake more work.

The first example he mentioned is FOCIL, corresponding to EIP-7805. This proposal allows multiple validators to participate in proposing a list of transactions that need to be included in blocks. According to the current proposal, each time slot selects a committee of 16 validators who create lists based on the transactions they see awaiting processing, and the subsequent construction and verification of blocks must comply with the corresponding inclusion rules.

Its role is to reduce the ability of a single block builder to exclude or delay transactions, enhancing resistance to censorship. The guarantees here are still constrained by transaction validity, block capacity, etc., and cannot be understood to mean that any transaction initiated by users will necessarily enter the next block.

Another example is EIP-8288, which addresses the issue of the costs of signatures and proofs.

Some quantum-resistant signatures and STARK proofs are relatively large, and placing them into blocks individually and verifying them separately incurs high costs. This proposal plans to move the aggregation work to the memory pool stage before transactions go on-chain. The memory pool can be understood as the place where nodes store transactions pending packaging; during the transaction propagation process, participants can process these signatures and proofs off-chain and then use a single aggregated proof to demonstrate that the relevant verification conditions have been met, reducing the data and verification burdens that need to go on-chain individually.

As of the verification time of this article, EIP-8288 is still marked as a draft. Vitalik expressed expectations for future upgrades in his speech, which should not be regarded as features already online or confirmed delivery timelines.

FOCIL changes who can influence transaction inclusion, while EIP-8288 attempts to complete the expensive cryptographic processing ahead of time. Both point to the same change: after users issue transactions, the network can complete some work in advance through the division of labor among more participants.

Let the on-chain calculations be a bit lighter so that the entire system can do more

In the architecture envisioned by Vitalik, a transaction may complete a large amount of local computation before leaving the user device; subsequently, it spreads through paths of different privacy attributes, completes proof aggregation, and involves different roles in block construction before finally going on-chain.

Understanding such a system requires seeing the main chain, layer two networks, memory pools, and user devices together. The blockchain remains important, but the business logic that must be sequentially processed by all verifying nodes can be reduced with technological advancements.

This also changes the way we ask about scalability.

If an application requires that a large amount of computation be dependent on each other and completed in strict order, it remains difficult to scale. However, if the work can be broken down into independent, executable, and verifiable parts and can be processed off-chain in advance, the entire system has the opportunity to bear a larger computational load.

Therefore, the premise emphasized by Vitalik is how computation is organized. Tasks that can be partitioned and verified are more likely to achieve large-scale scalability; allowing any type of computation unrestricted scalability is still not a reality.

The waiting time for users is also expected to shorten. In his speech, he gave a future expectation of reducing the block interval to 4-8 seconds and the time needed for finality to 8-32 seconds. Here, the block generation means transactions have the opportunity to be included in blocks, and finality means blocks receive stronger consensus confirmation; these two cannot be confused. These numbers are the target range he discussed; the Ethereum Foundation's recent public materials also listed "moving from minute-level finality to second-level" as a research and development direction, rather than a completed upgrade.

He invited developers to pay attention to Strawmap, which is also a continuously updated draft of the Ethereum L1 roadmap. It can help people understand how various research connects, and the specific plans and order will still be adjusted.

The significance of the "cryptographic world computer" thus becomes concrete: computation can be decentralized to more places, while people can still verify computation results based on cryptographic proofs.

AI is changing the way complex systems are developed

When discussing how these changes can materialize, Vitalik credited a significant role to AI. He even made a joke: the improved aesthetics of the slides for this speech were also thanks to AI.

What he values most is AI's acceleration of the entire research and development process.

The difficulties in applying cryptography do not only lie in finding an algorithm but also in implementing that algorithm into reliable software. As code and systems become increasingly complex, the work of testing, auditing, and proving their correctness also becomes heavier. In his view, AI can assist developers in writing specifications, generating tests, analyzing code, and advancing formal verification, giving more complex cryptographic systems a better chance of being reliably implemented.

Formal verification refers to first describing what the program should do using clear mathematical rules, then proving that the program adheres to those rules. It can provide stronger correctness guarantees than ordinary testing, but the guarantee's scope depends on whether the rules and models themselves are accurate and complete.

Vitalik also proposed an idea: allowing different people, teams, or AI agents to describe how the same system should work, and then checking through mathematical proofs whether these descriptions are consistent and whether the code meets the requirements. If there are discrepancies, the issues can be narrowed down to a more easily verifiable scope.

In his view, this is directly related to the security construction of layer two networks. In the past, to compensate for a lack of confidence in the correctness of complex systems, projects often required multiple proof systems, security councils, and other additional arrangements. With advancements in verification tools, there is an opportunity to more rigorously inspect the underlying implementations, creating the conditions to reduce dependence on additional trust arrangements.

At the end of the speech, he returned the topic to developers and applications themselves.

Many early applications were designed under a set of technical constraints: privacy was hard to achieve, complex computations were costly, and the more complex the code, the harder it was to fully verify. If these conditions are changing, developers deserve to reassess their original designs and should attempt applications that were previously difficult to build.

AI can also help more people understand these cutting-edge technologies and identify how they can participate. Whether it is researching cryptography, improving algorithms, or connecting Ethereum with other decentralized networks and real-world needs, there is new work to be done.

This speech leaves a concrete takeaway for developers: when information can be protected more thoroughly, computation can occur in more places, and complex code has stronger verification tools, applications can be redesigned from a new starting point.