The Future of Ethereum

Vitalik Buterin has released a series of six blog posts outlining his vision for Ethereum's future improvements. Each article represents a part of Ethereum's roadmap that was published by Vitalik in 2023. The purpose of this analysis is to explain the main ideas described by Vitalik and examine them through the eyes of an ordinary Ethereum network user and ETH holder.

Each of Vitalik's articles focuses on a specific part of the roadmap. We'll go through them in order and analyze each one. It's important to understand that each part addresses similar problems that are planned to be solved. The roadmap doesn't suggest that some proposals will be implemented earlier and others later; rather, they are all interconnected and complement each other.

The Merge — Acceleration of L1 

In «The Merge» article, which describes ideas for further technical improvements to Proof-of-Stake, Vitalik begins with the problem of long block finalization. Before exploring these improvements let's examine how Ethereum's current block confirmation process works.

Single slot finality

Currently, the process of adding new blocks can be divided into three stages:

1. Block production. In each slot (a conventional time unit in Ethereum lasting 12 seconds), a validator is selected to form transactions from the mempool into a block.

2. Attestation and justification. A committee of validators is assembled to verify the block's correctness. To pass attestation, the block must collect ⅔ of validator signatures. The block goes through justification for a minimum of two epochs (an epoch is 32 slots, ~6.4 minutes).

3. Finalization. Only after receiving justification results is the block considered finalized and becomes immutable.

Currently, block finalization takes an average of 15 minutes, with a requirement of 32 ETH to participate as a network validator. Vitalik explains this architecture as an attempt to find a compromise between staking size, finalization time, and network node load. If we start addressing the first two issues, we'll find that they conflict with the goal of minimizing network load. This is where the Single-slot finality concept comes to help. 

Here are three ways Single-slot finality could solve the long finalization problem without creating a heavy network load:

1. Brute force. Using the ZK-SNARKs cryptographic protocol for rapid signature processing during an epoch.

2. Orbit committees. A system with an improved validator committee formation mechanism.

3. Two-tiered staking. Creating two classes of stakers with different deposit requirements and network responsibilities.

Each approach presents distinct tradeoffs: Brute force faces technical implementation challenges, Orbit committees could potentially compromise network security by reducing attack costs, while Two-tiered staking risks increasing centralization. It's not yet clear which approach to implementing Single-slot finality will be adopted in Ethereum.

Secret of block proposal

Do you know who will create the next block in the network? While this information might not be crucial for us, validators competing in the network need to know the rules of the game. Currently in Ethereum, the RANDAO algorithm randomly determines block validators two epochs in advance. This means if you were chosen, you would know about it 12 minutes before you needed to create the block.

This algorithm protects the network from manipulations related to validators «predicting» subsequent blocks and guards against network delays. However, there's a risk that someone could launch an attack on a validator at the moment they're forming a block. To avoid the possibility of such DoS attacks, Vitalik proposes adding the Single secret leader election (SSLE) cryptographic protocol. This would conceal information about the next validator until the moment of block creation.

The essence of the protocol is:

• Creating a «blinded» validator ID for each validator. 

• Validators can reshuffle and change these IDs. 

• No one else knows which validator corresponds to the selected ID. 

• In each slot, one ID is selected for block proposal. 

Existing protocols that could be implemented in Ethereum are complex and consist of hundreds of lines of code. In the article, Vitalik mentions several alternatives to SSLE, however, implementing this particular protocol could significantly improve the network.

Faster transaction confirmations

As we mentioned earlier, the time to create one block is one slot in the blockchain (12 seconds). Reducing transaction confirmation time would:

• Improve user experience in L1 and L2. 

• Make DeFi more efficient. 

• Increase L2 decentralization and security. 

There are two approaches to accelerating transaction confirmations:

1. Reduce slot time. However, the main problem we encounter here is that blocks would be finalized too quickly, which could lead to security risks.

2. Pre-confirmations within the slot. In this case, a validator can complete block creation in advance.

The main challenge with increasing TPS (Transactions Per Second) is the growing network latency requirements for validators. If confirmation time is reduced to 4 seconds, the latency would need to be around 2 seconds. Such changes would lead to centralization because many validators wouldn't be able to provide this level of connectivity.

Quantum-resistance

At the end of the article, Vitalik briefly mentions that every protocol and algorithm appearing in Ethereum will first be tested for quantum resistance. The market predicts that quantum computers could begin compromising current cryptographic systems by 2030, so many existing systems need to look for quantum-resistant replacements. 

The Surge — Scalability

In his second article, Vitalik writes about Ethereum's scaling problem through L2 networks and increasing L1 throughput. Vitalik points out that scalability trilemma (blockchain trilemma) isn't a proven mathematical model. The development of zk-SNARKs and Plasma architecture (we'll discuss this later) allows us to think beyond its constraints.

Data compression and availability 

In the interaction between the Ethereum and L2 networks, the main process is data transmission and storage. There are two approaches to making it more efficient, and consequently increasing TPS in rollups. The first approach involves improving transaction processing in rollups by making changes to the mainnet, while the second approach focuses on reducing transaction weight in rollups.

To better understand these approaches, let's examine how L1 currently handles L2 transaction storage. In March 2024, the Dencun upgrade was implemented, which introduced Blobs to Ethereum. A Blob (Binary Large Object) is a new data storage structure that significantly reduced transaction costs in L2.  

Blobs were allocated a separate section in each block, and their main principle is that they store L2 information for only two weeks, after which the data is deleted from the network, leaving only the blob's cryptographic hash. The deletion of blob data poses no risks as L2 networks complete transaction verification before data removal, with cryptographic hashes ensuring ongoing data integrity verification.

Vitalik suggests improving blob functionality by adding the PeerDAS data availability sampling approach to the mainnet, which would increase L2 TPS to 58,000 (currently less than a thousand). Launching PeerDAS will accelerate how Ethereum nodes process L2 transactions.

The proposed implementation follows three key principles: 

• Each blob will be split into shares.  

• Only half of the shares will be needed to restore the entire blob. 

• Network nodes will process individual shares, «assembling» them into a blob.

PeerDAS is ready for deployment in Ethereum, and afterward, there are plans to gradually increase the number of blobs, thereby increasing rollup TPS. 

The second approach, which involves compressing transactions in rollups, simply aims to reduce data weight by decreasing its quantity. There are several straightforward options for doing this, such as compressing zeros, but each carries the risk of causing software compatibility issues.

Development of ERC-4337 (Account Abstraction) will also enable reducing transaction weight in rollups. Account abstraction allows creating a smart-contract wallet where users can pay gas in any tokens. ERC-4337 also enabled batch transaction processing: special bundler node combines many operations into one batch. In such a transaction, operations are grouped, repeated addresses are specified once, and signatures are combined. Recently, Shared Mempool was launched in Ethereum, Arbitrum, and Optimism – making batch processing more efficient and more decentralized.

What happens if L2 networks achieve scalability while L1 processes only a small volume of transactions? This would lead to ETH losing its value, and fewer projects would want to deploy their L2. There are several options to solve this problem – increasing the gas limit or creating several parallel copies of the mainnet. To prevent such a scenario, it's necessary to determine which tasks L1 should perform and which will transition to L2 networks. Balance between scalability and decentralization is crucial.

How does Plasma work?

The Plasma architecture helps solve the scalability trilemma. Let's examine in detail how this could theoretically be implemented in Ethereum.

First, it's important to clarify that Plasma is a different type of L2 network distinct from rollups. The main difference is that transaction data is stored outside the main chain. Without delving into technical details, let's consider a simple scenario of transaction processing in Plasma: the operator doesn't publish transaction data in the block but only sends cryptographic proof of executed operations. Each user whose transaction is included in the block also receives cryptographic proof that the block is valid. Additionally, the network has a special mechanism for verifying the received proof.

Although this solution is still theoretical and more complex to implement than PeerDAS, Vitalik sees it as a promising future architecture for Ethereum.

Security stages of L2

A key challenge limiting rollup development is their current inability to ensure complete system trustworthiness; in simpler terms, we can't say they're secure. In optimistic and zkSNARK rollups, there are «security councils» tasked with resolving disputes when they arise. However, as Vitalik notes, these councils often either don't work or simply serve an advisory function. To understand how rollups can increase their security level, Vitalik introduces three security stages for rollups:

• Stage 0 — block validation in the chain is performed centrally.

• Stage 1 — the network has a proof system guaranteeing that only valid transactions are accepted. The council can influence the system, but this requires ¾ of council members votes. Also, more than a quarter of council members must be from the project's core team, making the decision-making system fairer. Vitalik notes that Optimism and Arbitrum networks have achieved stage 1, but many rollups are far from it.

• Stage 2 — the proof system becomes fully autonomous, and the security council can intervene only in cases of obvious errors. The main idea of stage 2 is that the council doesn't dictate its decision; instead, in case of a dispute, one of the proofs proposed by the system is accepted. 

How to achieve stage 2? To make the proof system autonomous, we must ensure it's truly reliable. This can be done using mathematical proof methods or by creating multiple verification levels that complement each other. Both of these solutions are under development.

Creating an ecosystem

Currently, transferring ETH between L2 networks requires relying on centralized bridges and RPC connections from centralized providers. Vitalik, like all of us, would prefer Ethereum and L2s to become a unified ecosystem where cross-chain transactions become as simple as regular transfers. How can we improve EVM network interactions? Here are the main options:

• Chain-specific addressing: A streamlined user experience where sending assets across networks becomes as simple as specifying the destination network alongside the recipient's address — the wallet handles all bridging complexity automatically. Your wallet would automatically understand whether a bridge is needed for this operation and execute it.

• Open protocol for cross-chain operations. Currently, each bridge uses its own exchange system, but we need a unified messaging protocol between L2s. Vitalik even considers the idea of creating a separate rollup dedicated solely to this task.

• Light clients. To avoid relying on RPC from Infura, we can receive Ethereum network states without running a full node by installing Helios (a project from a16z crypto). However, such solutions for L2s haven't been created yet and are still to be implemented.

• Keystore wallets. If you want to change the keys managing your Gnosis Safe multisig wallet, you'll need to do this across all L2 networks. This is expensive and time-consuming, but the system could be simplified if L2s learn to read data from the mainnet and update accordingly.

Creating an ecosystem isn't just a technical challenge but also a social one, requiring combined efforts from Ethereum developers, L2 network teams, and wallet developers. «Our ability to handle this problem successfully is a test of our ability to stick together as a community.» — Vitalik concludes.

The Scourge — Solving the Centralization Crisis

The centralization challenge manifests in two critical areas that require immediate attention. First is the centralization at the block proposal level, as 88% of blocks in the network are created by two large companies. Second is staking centralization where large participants receive more benefits from the system.  

Reduce centralization of builders

When a validator receives the opportunity to propose a block, they typically delegate it to other network participants — builders, because this task requires significant resources. Such delegation leads to risks that builders might delay transactions and conduct sandwich attacks. This problem can be solved by limiting builders responsibilities and transferring some of their tasks to validators. Here's how it's planned to be implemented:

1. The validator compiles a list of transactions to be included in the block (currently done by the builder). 

2. The builder creates the block. They can change the transaction order but cannot remove any transactions.

There are several approaches to implementing this. One of them, for example, aims to reduce validator resource consumption and allows a group of validators to form lists for the builder. Vitalik also writes about using encrypted mempools, where the builder won't know the transaction's content, and an auction system where builders will compete with each other.

Updating the staking system

Currently, about 30% of all ETH is in staking, but what happens if this percentage increases? While increased staking participation might initially seem positive, suggesting growing investor confidence and reduced circulating supply, it introduces several security considerations: 

• Most ETH will be delegated to centralized operators. 

• A single liquid staking protocol could capture most of the LST market and become more popular than ETH (taking the «network effect» for itself). 

• Approximately 1M ETH will be issued annually as staking rewards.

• Penalties for malicious stakers will become ineffective.

To reduce centralization risks and penalties, two new systems could be implemented. The first would control penalty sizes — while currently a validator can lose their entire stake, future penalties could be smaller, reducing risks for ordinary users. The second system would introduce two-tier staking — «risk-bearing» and «risk-free». The main difference would be that the first option offers higher APY but with high penalties, while the second would have lower returns and lower risks. 

Vitalik also suggests a simpler approach that could solve the ETH emission problem — reducing staking rewards. The more ETH is locked, the lower the overall return, which would reduce incentives to stake even more.

Regarding LST token dominance, the proposal is to encourage the creation of a single decentralized token and reduce incentives for mass participation in LST protocols.

Application layer solutions

To avoid centralization risks, it's important not only to change the network's foundation but also to improve applied technologies to make it easier for us, the users, to make the network more decentralized. Here are examples of how this is already being implemented:

• Group staking. A solution from Obol allows multiple people to launch their node in the network.

• Airdrops. Starknet distributed rewards to individual stakers.

• Staking hardware solutions. Devices from Dappnode make launching your own node as simple as connecting home internet.

The Verge — Ethereum Verification on your smartwatch

One of blockchain's fundamental properties is the ability to verify data independently. Anyone can run their own network node and verify data about the entire system's state using their computational power. Currently, network nodes store hundreds of gigabytes of data, and the blockchain itself grows by approximately 30 GB annually. This part of the roadmap aims to solve the problem of centralized blockchain verification and enable us to trust the network by verifying it through our smartphone or smartwatch.

Which proof algorithm is better?

Currently, Ethereum uses the Merkle Patricia Trie for block verification. If you're not familiar with how Merkle trees work, it's important to know that this algorithm combines transaction data hashes into one root block hash.  

Imagine you have a cabinet with 10 shelves and 10 small drawers on each shelf. To prove that what you're looking for is in a drawer on the 10th shelf, you need to check all drawers starting from the bottom. This volume of tasks loads the network node. Therefore, Vitalik suggests choosing between two new approaches to block verification:

1. Verkle Trees. Imagine the same cabinet, but now you only need to check the first drawer on each shelf. This way, proof is faster and takes up less space.

2. STARKed Trees. You stand before the cabinet, remembering which shelf you put the item on. The thinking takes longer than checking the first drawer on each shelf, but the total work you do is less since you open the right drawer immediately.

Verkle trees generate efficient, level-by-level compressed proofs, whereas STARKed trees produce a single comprehensive proof for the entire system. Verkle trees are based on elliptic curve cryptography, making them vulnerable to quantum computers, although their working logic is more ready for launch. STARKed is more resistant to quantum computing but takes longer to form proofs, which might be inefficient when users send many simple requests to the blockchain. It's not yet clear which idea will be implemented. Refining and implementing these technologies will take several years. 

Validity proofs of consensus and EVM

The trees we discussed above aren't sufficient for verifying the blockchain via phone. To approach this goal, we need to create algorithms that will prove that the EVM is working correctly and that balance updates at the consensus level are occurring properly.

If we simplify the EVM working algorithm, we get three main stages:

1. Initial state.

2. Receiving block with data. 

3. State update. 

Light clients should only receive hashes verifying the new state. And such a system is already in use, for example in zkSync. But implementing it in L1 is much more complex. Many problems are also hidden in developing consensus proofs, one of them being the volume of validator state data, which requires a million hashes per epoch. The solution to this task will be the implementation of single slot finality, which we discussed at the beginning of the article.

The Purge — How to make Ethereum cleaner?

One of the blockchain's challenges is that over time, the amount of data and function complexity increase. In Ethereum's case, this could make running nodes more difficult, as the network already takes up more than one terabyte, while growing complexity increases the probability of network errors. How can we solve this problem while maintaining blockchain's consistency and verifiability? 

Creating a torrent network

The last created block is verification of all previous network states, as it contains the hash of the previous block, allowing us to prove the entire chain. Consensus (agreement on the new state) is achieved when at least half of the network participants confirm it. For historical data, it's sufficient if just one node stores it, because as long as the network has consensus on the latest block, any historical data can be provided by a network participant along with proof of chain accuracy, and this proof allows anyone else to verify its correctness.

Today in Ethereum, data isn't stored on consensus clients forever; after six months, it begins to be stored on archive nodes. However, for a better solution to node congestion, Vitalik suggests using a torrent network model, where each node would be responsible for storing a specific portion of information. This approach won't affect information storage reliability, because if creating torrent nodes is simplified, their number could exceed 100 thousand. If each node stores 10% of history and each data fragment is replicated 10,000 times — this would be comparable to a network of 10,000 nodes where each node stores everything.

To implement this idea, an existing torrent library could be integrated into Ethereum or the Portal solution could be launched. Along with this, EIP-4444 is planned for launch, which will reduce the data storage time on network nodes. Without implementing this idea, it won't be possible to move closer to simple blockchain verification. 

Solving the state problem

Even if the data storage problem is solved, node requirements will continue to grow due to increasing information about balances and smart contracts. If you create a new wallet and transfer some ETH to it, this creates a new state that is permanently stored in the network. While there are many potential solutions, such as users paying ETH fees to extend their account, any implemented solution must meet three goals:

1. It shouldn't require additional computations.

2. It must be user-friendly: data should always be accessible.

3. It shouldn't complicate development or disrupt existing solutions.

There are three solutions aligned with these goals: The simplest is creating a stateless system, where only special nodes store state while others operate without state data. However, this risks centralization and raises trust issues regarding state-storing nodes. The key drawback is that network state volume will continue growing.

The next solution is partial state reading. Think of it like running a small hotel: you know which rooms are free or occupied and remember recent check-ins/check-outs, but need to check the registry for specific guest information. In blockchain terms, nodes would store superficial state data and «remember recent events». Rarely accessed data would have a «placeholder» allowing for resurrection. Like keeping an annual guest count instead of detailed records, but honoring previous year's receipts (proofs) for discounts.

The drawback of this solution is that conflicts may arise regarding data revival in the network. This issue can be addressed through a state reading system based on address periods. Imagine that each check you have is numbered according to a special system, and you always know which week and year it was issued. In blockchain, this is proposed to be implemented as follows:

1. After a certain period (for example, one year), a new state system is created, and any state reading is recorded in it.

2. Nodes will store state data for two periods (two years), while older information will be frozen.

3. To «revive» frozen data, proof must be provided to rewrite it. 

This system becomes possible due to changes in address format. We can increase the address weight by adding a number indicating its creation period, or we can decrease the number of characters in the address. Both approaches will lead us to compatibility issues, while reducing address weight would also decrease the complexity of brute-force attacks. Which solution should we choose? The stateless approach is the easiest to implement, but it seems unreliable. Implementing other options will take several years. It appears we need to wait for new ideas to solve this problem.

Taking care of simplicity 

Network accessibility and security can only be maintained by keeping the blockchain simple. Simplicity helps reduce errors and simplifies processes for developers. In this section, Vitalik describes functions that could be removed from the blockchain and mechanisms that could be simplified. Without going into details, it's important to note that each such decision will be discussed with the community, and Vitalik notes that this won't be a quick process. 

The Splurge — Little and important things 

Unlike the previous sections that addressed specific challenges, this final part of the roadmap tackles various critical improvements that don't fit neatly into other categories.

The first such task is improving the EVM through a hard fork that will add a new code version to the EVM. This proposal, called EOF (EVM Object Format), aims to simplify development and reduce gas costs.

The next task relates to Account Abstraction. ERC-4337 was initially developed as an out-of-protocol standard, which requires significant gas for processing transaction bundles. The plan is to move some transaction validation and execution tasks to the EVM level, which will enable abstraction capabilities for EOA accounts as well.

Another task concerns the calculation system that has been operating since 2021 but shows inefficiencies (blocks aren't filled optimally, and the system doesn't respond well to sudden changes). With the implementation of EIP-7706 and EIP-7623, separate gas adjustment mechanisms are proposed for different types of operations. This will make the system more flexible and gas prices fairer.

Far future of cryptography

We must pay special attention to one particular section because developments in cryptography will determine Ethereum's evolution. While everything described above is a 2-3 year perspective, in this section, Vitalik prepares us for what's coming in 10-15 years. Let's look into this future.

But first, concerning the past. In 1997, Nick Szabo wrote an essay «The God Protocols», contemplating how to create an ideal protocol where a third party could resolve any disputes without accessing confidential information about the disputants. This third party would be a virtual computer combining transparency, confidentiality, and trust.

The emergence of Programmable Cryptography has finally enabled the development of protocols that can simultaneously achieve transparency, confidentiality, and trust — properties that were previously mutually exclusive. With the emergence of Programmable Cryptography, which enabled in-protocol computations, we entered a new era comparable to the transition from specialized hardware to programmable computers. In this new era, we have three technologies that will help us approach the creation of an ideal third party:

1. ZK-SNARKs — allow users to prove any arbitrary statement about data they own in a way that makes the proof easily verifiable while revealing no information beyond the statement itself.

2. FHE (Fully Homomorphic Encryption) — enables performing any computations on encrypted data without viewing the data itself. While ZK-SNARKs have developed significantly over the past five years, FHE-based solutions are just emerging, such as Cursive.

3. Indistinguishability obfuscation — this protocol currently exists only in theoretical foundations. It allows creating an encrypted program that will use a private key only for specific actions. We can distribute the program, and no one will be able to extract the private key from it.

Each protocol naturally has its drawbacks. For instance, using obfuscation to create an ideal third party would require everyone to have their own quantum computer. The development of these three encryption protocols could not only make Ethereum more attractive to corporations seeking confidentiality but also elevate blockchain voting, DAOs, make the network resistant to 51% attacks, and potentially enable quantum money.

Ethereum in 2030

Ethereum's development plan is not just Vitalik's vision but represents the aspirations of all researchers and developers from the Ethereum Foundation. The Beam Chain upgrade, presented by Justin Drake at Devcon, is a comprehensive concept for updating the Beacon Chain, incorporating ideas previously voiced by Vitalik.

«It is about identifying a specific subset of that road map and accelerating it and putting a mimetic wrapper around it» (Justin Drake about Beam Chain proposal). 

Let's summarize. Here are the main technical improvements awaiting Ethereum in the future:

• Acceleration of finalization and transaction confirmation.

• Quantum resistance.

• Creating an ecosystem where cross-chain transactions will not differ from regular transfers.

• Update staking system and gas calculation.

• Decentralization through the creation of a torrent network, simplified blockchain verification on light clients, and solving the network data growth problem.

These technical advancements will catalyze new trends in blockchain development and dApp innovation. Here are several that are being discussed today:

• There will be an increasing number of L2 solutions created by businesses and communities. For example, ENS announced the creation of their own L2 for launching multichain domains.

• The Vyper programming language will become more widespread for creating contracts in EVM. Vitalik spoke about this during his presentation at Devcon.

• The development of encryption methods (ZK, FHE, MPC) will lead to the creation of new projects solving privacy and security issues at different levels. Here are some that are already in the market: Aztec, Brevis, Ingonyama, Fairblock and Semaphore.

• Improvement of user experience: Account abstraction, Light clients, new cross-chain solutions.

Most of the solutions described by Vitalik currently remain theoretical, and much requires practical implementation. In the future, many projects supported by the Ethereum Foundation will emerge, building applications that strive to realize these dreams. Ethereum has ambitious plans and a long journey ahead.