Vitalik Buterin, the creator of Ethereum, described how the blockchain could be improved over time in a series of October blog posts.
The Merge
Buterin's first post describes Ethereum’s "Merge," which includes technical improvements to proof-of-stake. In staking, participants deposit ETH tokens and earn rewards as they help to validate transactions.
First, Buterin described a need for improvements to finality — the guarantee that transactions cannot be reversed. Finalization currently takes 15 minutes on Ethereum, but single slot finality could allow Ethereum to finalize blocks in 12 seconds or less.
Next, Buterin said validators should be able to stake with 1 ETH rather than the 32 ETH currently required. This reduction could encourage solo staking.
Buterin also detailed how single secret leader elections could obscure information about pending block validators. This change would protect against Denial-of-Service (DoS) attacks concerning block proposals.
Reducing transaction confirmation times is another goal for the project. Ethereum could shorten transaction confirmation times from 12 seconds to 4 seconds by reducing slot times. Alternately, allowing block proposers to publish pre-confirmations over the course of a slot could speed up confirmations. Faster confirmations would benefit users and speed up some technical operations.
The Surge
Next, Buterin addressed "The Surge", which aims to have Ethereum support 100,000 transactions per second (TPS) across Layer 1 and 2.
Buterin described a "rollup-centric roadmap" to achieve that higher throughput. Unlike some other scaling methods that are entirely off-chain, rollups handle computation off-chain but keep some transaction data on Ethereum's main chain. Buterin noted that rollups are more powerful than some earlier scaling efforts, such as state channels or Plasma, but more demanding in terms of on-chain data bandwidth.
Areas of research include data availability sampling (DAS) and improved rollup data compression, which together could allow Ethereum to handle 58,000 TPS. Other solutions, such as Plasma, could improve throughput further. One hybrid plasma/rollup, Intmax, could theoretically reach 266,667 TPS.
Improving transaction throughput is not the only goal in "The Surge." This development stage also aims to preserve decentralization and robustness on Ethereum's Layer 1. Plus, it aims to add Ethereum's core properties, such as trustlessness, openness, and censorship resistance, to some second layers.
Buterin also stressed a need for Layer 2 interoperability, stating that Ethereum "should feel like one ecosystem, not 34 different blockchains."
The Scourge
In a third post, Buterin addressed "The Scourge," or unwanted centralization from economic pressures related to proof-of-stake.
One issue is centralization among builders. Builders are specialized actors that choose block contents — a task that is auctioned off by validators and one where maximizing profits is possible because of economies of scale. This has led to centralization, with two entities choosing the contents of 88% of Ethereum blocks at present.
Fixing the block production pipeline is a solution. One option is inclusion lists, which would allow builders to order transactions and insert their own transactions. Meanwhile, proposers and stakers would regain the task of choosing transactions.
Buterin also identified another issue: high staking participation rates that could lead to almost all ETH being staked across the entire community. Buterin said that about 30% of all ETH is currently actively staked, which is more than enough to prevent 51% attacks. Too much staking could lead to a variety of other risks.
Ethereum could address high staking rates by capping stake, which would involve changing the ETH issuance curve and reducing returns as staked ETH approaches the cap. Another solution is two-tiered staking, with different curves for participants depending on whether they stake in premium or risk-free tiers. Alternatively, the project could do nothing and accept the tradeoffs that come with high staking rates.
The Verge
In his fourth post, Buterin outlined "The Verge." This stage involves making verification easier and more computationally affordable so that regular users can participate alongside stakers. Greater involvement in verification could help protect protocol rules.
Buterin described two key goals. First is the creation of stateless clients that can work with only a few gigabytes of storage. The client software would not need to download Ethereum's entire state, which is currently hundreds of gigabytes large and growing.
A second goal involves allowing simple devices such as smart watches to fully verify the blockchain. Mobile devices, mobile wallets, and browser wallets could also engage in verification. Buterin said that verification should be "so computationally affordable" that most applications and devices can perform it by default.
The Purge
Finally, Buterin described "The Purge." One part of this goal involves reducing the need for nodes to store all history (including data about historical blocks, transactions and receipts). Though Ethereum has partially achieved this, the project must build a concrete distributed history storage system and decide how accessible old data should be.
Buterin also discussed possible solutions to the problem of state expiry, which he called a more challenging issue. Certain actions create a new state object to be kept in Ethereum's state permanently. Ideally, Ethereum can introduce state expiry, partial state expiry, or statelessness to get rid of some old data while also minimizing tradeoffs around efficiency and usability.
Finally, Buterin described the need for feature cleanup. Though there are multiple approaches, the project aims to trim old, unnecessary features from Ethereum while maintaining backward compatibility.
Ethereum will not necessarily implement the courses of action described above, most of which are long-term possibilities. And Buterin has not proposed each possible action personally: instead, various developers and contributors are doing research on each change and the related areas of the roadmap.