Vitalik's new article: Possible futures for Ethereum, the Merge
TechFlow Selected TechFlow Selected
Vitalik's new article: Possible futures for Ethereum, the Merge
Democratized staking, faster transaction confirmations, quantum resistance—what will Ethereum's future look like?
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Translation: Alex Liu, Foresight News
Special thanks to Justin Drake, Hsiao-wei Wang, @antonttc, Anders Elowsson, and Francesco for feedback and review.
Originally, "the Merge" referred to the most significant event in Ethereum's history since its launch: the long-awaited and hard-won transition from proof-of-work (PoW) to proof-of-stake (PoS). Today, Ethereum has been operating as a stable proof-of-stake system for nearly two full years, with PoS performing excellently in terms of stability, performance, and avoiding centralization risks. However, there are still important areas where proof-of-stake can be improved.
My 2023 roadmap divided these improvements into several parts: enhancing technical capabilities such as stability, performance, and accessibility for small validators, along with economic changes to address centralization risks. The former took over the title "the Merge," while the latter became part of "the Scourge."
This article will focus on the "Merge" portion: What aspects of proof-of-stake’s technical design can still be improved, and what are the paths toward achieving those improvements?
This is not an exhaustive list of everything that could be done with proof-of-stake; rather, it is a list of ideas currently under active consideration.
Single-Slot Finality and Staking Democratization
What problem are we trying to solve?
Currently, it takes 2–3 epochs (about 15 minutes) to finalize a block, and you need 32 ETH to become a staker. This was originally a compromise designed to balance three goals:
-
Maximize the number of validators able to participate in staking (which directly means minimizing the minimum ETH required to stake)
-
Minimize finality time
-
Minimize node operation overhead, specifically the cost of downloading, verifying, and rebroadcasting signatures from all other validators
These three goals conflict with each other: To make economic finality possible (meaning: attackers must burn large amounts of ETH to reverse finalized blocks), every validator needs to sign two messages per finalization event. Therefore, if you have many validators, either you need a long time to process all their signatures, or you need extremely powerful nodes to handle all signatures simultaneously.
Note that all of this assumes one key goal of Ethereum: ensuring that even successful attacks come at a high cost to the attacker. This is what “economic finality” means. Without this goal, we could resolve the issue by randomly selecting a committee to finalize each block. Chains that do not attempt economic finality, such as Algorand, typically do exactly this. But the problem with this approach is that if an attacker controls 51% of validators, they can carry out attacks (reversing finalized blocks, censorship, or delaying finality) at very low cost—by only compromising a subset of nodes within the committee. Those participating in the attack may later be detected and penalized, either through slashing or socially coordinated soft forks . This means attackers could repeatedly attack the chain, losing only a small fraction of their stake each time. Thus, if we want economic finality, simple committee-based approaches won’t work, and at first glance, we seem to need participation from all validators.
Ideally, we want to maintain economic finality while improving the current state in two areas:
-
Finalize blocks within a single slot (ideally maintaining or even reducing the current 12-second duration), instead of 15 minutes
-
Allow validators to stake with just 1 ETH (lower than 32 ETH)
The first goal serves two purposes, both interpretable as “aligning Ethereum’s properties with those of more centralized, performance-focused L1 chains.”
First, it ensures all Ethereum users actually benefit from the higher security guarantees provided by the finality mechanism. Today, most users don’t wait 15 minutes; with single-slot finality, users would see their transactions finalized almost immediately after confirmation. Second, if users and applications no longer have to worry about chain reorganizations (except in relatively rare inactivity leak scenarios), it simplifies protocols and surrounding infrastructure.
The second goal stems from a desire to support solo stakers. Repeated surveys consistently show that the main barrier preventing more people from solo staking is the 32 ETH minimum requirement. Reducing this threshold to 1 ETH would resolve this issue, making other factors the primary constraints on solo staking.
There is currently a challenge: The goals of faster finality and more democratized staking both conflict with minimizing overhead. In fact, this trade-off is precisely why we didn't start with single-slot finality. However, recent research has proposed some potential solutions.
What is it and how does it work?
Single-slot finality involves using a consensus algorithm to finalize blocks within a single slot. This in itself isn’t difficult: many algorithms, like Tendermint consensus, already do this. A unique requirement for Ethereum is inactivity leakage, which Tendermint doesn’t support—this feature allows the chain to continue progressing and eventually recover even if over 1/3 of validators go offline. Fortunately, this has been addressed: proposals exist to modify Tendermint-style consensus to accommodate inactivity leakage.
Leading single-slot finality proposal
The harder part is figuring out how to make single-slot finality work efficiently with a very large number of validators without causing extremely high node operator overhead. Several leading solutions are being explored:
-
Option 1: Brute force – Improve signature aggregation protocols, possibly using ZK-SNARKs, enabling us to practically handle millions of validator signatures per slot.
Horn, one proposed design for better aggregation protocols
Option 2: Orbit committees — a new mechanism allowing randomly selected medium-sized committees to finalize the chain, while preserving the desired high attack-cost properties.
One way to think about Orbit SSF is that it opens up a spectrum between two extremes: x=0 (Algorand-style committees, no economic finality) and x=1 (current Ethereum), with intermediate points where “Ethereum still has sufficient economic finality to be very secure, yet we only require a moderate-sized random sample of validators per slot to gain efficiency benefits.”
Orbit leverages pre-existing heterogeneity in validator deposit sizes to achieve as much economic finality as possible while still giving smaller validators meaningful roles. Additionally, Orbit uses slow committee rotation to ensure high overlap between adjacent quorums, preserving economic finality across committee transitions.
-
Option 3: Two-tier staking — a mechanism with two classes of stakers: one with high deposit requirements and one with low. Only the higher-tier stakers directly participate in providing economic finality. There are various proposals regarding rights and responsibilities for lower-tier stakers (e.g., see the Rainbow staking post). Common ideas include:
-
The right to delegate staking duties to higher-tier stakers
-
A requirement for some random low-tier stakers to attest and finalize each block
-
The right to generate inclusion lists
How does this relate to existing research?
-
Paths toward single slot finality (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
-
A concrete proposal for a single slot finality protocol for Ethereum (2023): https://eprint.iacr.org/2023/280
-
Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
-
Further analysis on Orbit-style mechanisms: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464
-
Horn, signature aggregation protocol (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
-
Signature merging for large-scale consensus (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
-
Signature aggregation protocol proposed by Khovratovich et al: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
-
STARK-based signature aggregation (2022): https://hackmd.io/@vbuterin/stark_aggregation
-
Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
What remains to be done, and what are the trade-offs?
There are four main possible paths forward (we could also pursue hybrid approaches):
-
Maintain the status quo
-
Brute-force SSF
-
Orbit SSF
-
SSF with two-tier staking
(1) means doing no work and staying as-is, but this leaves Ethereum’s security experience and staking centralization worse off.
(2) solves the problem through advanced technology. This requires aggregating massive numbers of signatures (over 1 million) within a short window (5–10 seconds). One way to view this approach is that it minimizes system complexity by embracing encapsulated complexity through technological brute force.
(3) avoids “advanced tech” and instead solves the problem through clever rethinking of protocol assumptions: we relax the “economic finality” requirement so that we aim for high attack costs, but accept that the cost might be up to 10x less than today (e.g., $2.5 billion instead of $25 billion). It is widely believed that today’s level of economic finality exceeds what is necessary, and the main security risks lie elsewhere—so this may be an acceptable sacrifice.
The main tasks are verifying that the Orbit mechanism is secure and has the desired properties, then formalizing it fully and implementing it. Additionally, EIP-7251 (Increase Maximum Effective Balance) enables voluntary validator balance consolidation, which immediately reduces chain validation overhead to some extent and effectively acts as an initial phase of Orbit rollout.
(4) avoids clever redesign and advanced tech but creates a two-tier staking system that still carries centralization risks. The severity depends heavily on the specific rights granted to lower-tier stakers. For example:
-
If low-tier stakers must delegate attestation rights to high-tier stakers, delegation could become centralized, resulting in two highly centralized staking layers.
-
If a random sample from the lower tier is required to approve each block, attackers could spend very little ETH to prevent finality.
-
If lower-tier stakers can only generate inclusion lists, the attestation layer may remain centralized, and a 51% attack on the attestation layer could censor inclusion lists independently.
Multiple strategies can be combined, such as:
(1 + 2): Add Orbit without single-slot finality
(1 + 3): Use brute-force techniques to reduce minimum deposit size without enabling single-slot finality. The required aggregation volume is 64x less than pure (3), making the problem easier.
(2 + 3): Implement Orbit SSF with conservative parameters (e.g., 128k validator committee instead of 8k or 32k), and use technology to make it ultra-efficient.
(1 + 4): Add Rainbow Staking without single-slot finality
How does this interact with other parts of the roadmap?
Besides other benefits, single-slot finality reduces the risk of certain types of multi-block MEV attacks. Additionally, in a single-slot finality world, proposer-builder separation designs and other in-protocol block production pipelines would need different architectures.
A weakness of brute-force strategies is that they make reducing slot time more difficult.
Single Secret Leader Election (SSLE)
What problem are we trying to solve?
Currently, it is known in advance which validator will propose the next block. This creates a security vulnerability: attackers can monitor the network, identify which validators correspond to which IP addresses, and launch DoS attacks against each validator just before it proposes a block.
What is it and how does it work?
The best way to solve the DoS issue is to hide information about which validator will generate the next block—at least until the block is actually produced. Note that if we drop the “single” requirement, this is easy: one solution is to allow anyone to create the next block, but require their randao reveal to be less than 2^256 / N. On average, only one validator meets this criterion—but sometimes two or more do, and sometimes none do. Combining the “secret” requirement with the “single” requirement has been the real challenge.
Single secret leader election protocols solve this by using cryptographic techniques to create a “blinded” validator ID for each validator, then giving multiple proposers opportunities to shuffle the pool of blinded IDs (similar to how a mixnet works). During each slot, a random blinded ID is selected. Only the owner of that blinded ID can generate a valid signature to propose the block, but no one else knows which validator corresponds to that blinded ID.
How does this relate to existing research?
-
Paper by Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
-
Whisk (concrete proposal for Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
-
Single secret leader election tag on ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
-
Simplified SSLE using ring signatures: https://ethresear.ch/t/simplified-ssle/12315
What remains to be done, and what are the trade-offs?
In practice, the remaining task is to find and implement a sufficiently simple protocol that we can easily deploy on mainnet. We value Ethereum as a relatively simple protocol and do not wish to increase complexity unnecessarily. Current SSLE implementations add hundreds of lines of specification code and introduce new cryptographic assumptions. Finding a sufficiently efficient post-quantum secure SSLE implementation is also an open question.
It’s possible that once we introduce general zero-knowledge proof mechanisms into Ethereum’s L1 protocol for other reasons (e.g., state trees, ZK-EVM), the additional complexity from SSLE will become negligible.
Alternatively, we could abandon SSLE entirely and rely on out-of-protocol mitigations (e.g., at the p2p layer) to address DoS issues.
How does this interact with other parts of the roadmap?
If we add a proposer-builder separation (PBS) mechanism, e.g., execution tickets, then execution blocks (i.e., blocks containing Ethereum transactions) will no longer need SSLE, as we can rely on specialized block builders. However, we would still benefit from SSLE for consensus blocks (i.e., blocks containing protocol messages such as attestations, and perhaps fragments of inclusion lists, etc.).
Faster Transaction Confirmation
What problem are we trying to solve?
Reducing Ethereum’s transaction confirmation time further—from 12 seconds down to, say, 4 seconds—would provide value. It would improve user experience for both L1 and rollups based on Ethereum, make DeFi protocols more efficient, and make it easier to decentralize L2s by enabling a broad class of L2 applications to operate on rollups, thereby reducing the need for L2s to build their own committee-based decentralized sequencers.
What is it and how does it work?
Reduce slot time, for example to 8 seconds or 4 seconds. This doesn’t necessarily imply 4-second finality: finality inherently requires three rounds of communication, so we could structure each round as a separate block, achieving preliminary confirmation in at least 4 seconds.
Allow proposers to publish preconfirmations during the slot. In the extreme case, proposers could add transactions they see in real time to their own block and immediately publish preconfirmation messages (“My first transaction is 0x1234…”, “My second transaction is 0x5678…”). Conflicting confirmations published by a proposer could be handled in two ways: (i) slash the proposer, or (ii) use a prover to vote for the earlier confirmation.
How does this relate to existing research?
-
Based preconfirmations: https://ethresear.ch/t/based-preconfirmations/17353
-
Protocol-enforced proposer commitments (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
-
Staggered periods across parallel chains (a 2018-era idea for achieving low latency): https://ethresear.ch/t/staggered-periods/1793
What remains to be done, and what are the trade-offs?
It is unclear whether reducing slot time is feasible. Even today, many stakers around the world struggle to receive attestations quickly enough. Attempting a 4-second slot time risks validator centralization and makes staking impractical outside a few developed regions due to latency. Specifically, moving to a 4-second slot would require limiting network latency (“delta”) to under two seconds.
A downside of proposer preconfirmations is that they can greatly improve average-case inclusion time but do not improve worst-case performance: if the current proposer performs well, transactions get preconfirmed in 0.5 seconds instead of included in 6 seconds (on average); but if the current proposer is offline or malfunctioning, you still have to wait a full 12 seconds for the next slot and a new proposer.
Additionally, how to incentivize preconfirmations remains an open question. Proposers have an incentive to maximize optionality for as long as possible. If provers sign timely preconfirmations, transaction senders could conditionally pay fees for immediate preconfirmation, but this adds extra burden to provers and may make it harder for them to remain neutral “dumb pipes.”
On the other hand, if we don’t pursue this and keep finality time at 12 seconds (or longer), the ecosystem will place greater emphasis on L2 preconfirmation mechanisms, and cross-L2 interactions will take longer.
How does this interact with other parts of the roadmap?
Proposer-based preconfirmations effectively depend on proposer-builder separation (PBS) mechanisms, such as execution tickets. Otherwise, the pressure on regular validators to provide real-time preconfirmations may become too concentrated.
How short slots can realistically become also depends on slot structure, which in turn largely depends on which version of PBS, inclusion lists, etc., we ultimately implement. Some slot structures involve fewer rounds and are thus more friendly to shorter slot times, though they make trade-offs elsewhere.
Other Research Areas
Recovery from 51% Attacks
It is often assumed that if a 51% attack occurs (including attacks that cannot be cryptographically proven, such as censorship), the community will unite to implement a minority soft fork ensuring honest participants prevail while attackers face inactivity leaks or slashing. However, such heavy reliance on social coordination could be considered unhealthy. We could try to reduce dependence on the social layer by making the recovery process as automated as possible.
Full automation is impossible—if it were, it would constitute a >50% fault-tolerant consensus algorithm, and we already know the (very strict) mathematically provable limitations of such algorithms. But partial automation is achievable: for instance, if clients observe a transaction being censored for long enough, they could automatically reject accepting the finalized chain—or even refuse to accept the fork choice head. A key goal is ensuring attackers cannot achieve quick, clean victories during an attack.
Raising the Quorum Threshold
Today, a block is finalized if supported by 67% of staked ETH. Some argue this is too aggressive. Throughout Ethereum’s entire history, finality failure has occurred only once—and briefly. If this percentage increased, say to 80%, the number of non-finality phases would increase only slightly, but Ethereum would gain stronger safety properties: in particular, many more contentious situations would lead to temporary halts in finality. This seems much healthier than letting the “wrong side” win immediately, whether due to attackers or buggy clients.
This also answers the question: “What’s the point of solo stakers?” Currently, most stakers already stake via pools, and solo stakers seem unlikely to ever control 51% of staked ETH. However, if we work toward enabling solo stakers to form a blocking minority—especially if the quorum threshold is 80% (thus requiring only 21% to block)—this seems achievable. As long as solo stakers disagree with a 51% attack (whether finality reversal or censorship), such an attack cannot achieve a “clean victory,” giving solo stakers strong incentives to help organize minority soft forks.
Note that there is interaction between quorum thresholds and Orbit mechanisms: if we adopt Orbit, the meaning of “21% of stakers” becomes more complex and partially depends on validator distribution.
Quantum Resistance
Metaculus currently estimates, despite wide error bars, that quantum computers may begin breaking cryptography sometime in the 2030s:
Quantum computing experts like Scott Aaronson have recently begun taking more seriously the possibility that quantum computers could function effectively in the medium term . This affects the entire Ethereum roadmap: it implies that every part of the current Ethereum protocol relying on elliptic curves will eventually need to be replaced with hash-based or otherwise quantum-resistant alternatives. In particular, we cannot assume we will always be able to rely on the excellent properties of BLS signature aggregation for handling signatures from large validator sets. This justifies conservative assumptions about performance in PoS design and provides motivation for more proactive development of quantum-resistant alternatives.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
