Since October this year, Ethereum co-founder Vitalik Buterin has published a series of articles on the potential future of the Ethereum protocol, covering six parts of the Ethereum roadmap: The Merge, The Surge, The Scourge, The Verge, The Purge, and The Splurge. This article will interpret the first part (The Merge), explore what technical designs can be improved in the PoS proof-of-stake system, and the ways to achieve these improvements.
Vitalik believes that "the Merge" refers to the most important event in the history of the Ethereum protocol since its launch: the transition from PoW proof-of-work to PoS proof-of-stake. Today, Ethereum has become a stable PoS system for nearly two years, and this proof-of-stake has performed very well in terms of stability, performance, and avoiding centralization risks. However, there are still some important areas in proof-of-stake that need to be improved.
Ethereum's 2023 roadmap divides it into several parts: improving technical features (such as stability, performance, and accessibility for smaller validators), as well as economic changes to address centralization risks. According to Vitalik, this article is not an exhaustive list of improvements to proof-of-stake, but rather ideas that are actively being considered.
The main goals of the Merge are as follows:
1. Single Slot Finality (SSF): Typically, Ethereum blocks take about 15 minutes to finalize. However, by improving the efficiency of Ethereum's consensus mechanism for verifying blocks, the time required for finality can be greatly reduced. Blocks can be proposed and finalized within the same slot, without waiting 15 minutes.
2. Confirm and complete transactions as quickly as possible, while maintaining decentralization
3. Improve the feasibility of solo staking
4. Improve robustness
5. Improve Ethereum's resistance and recovery to 51% attacks (including finality reversals, finality freezes, and censorship)
Single Slot Finality and Staking Democratization
Currently, it takes 2-3 epochs (about 15 minutes) to finalize a block, and 32 ETH is required to become a validator. This was initially a compromise to balance three goals:
- Maximize the number of validators participating in staking (minimize the ETH required for staking);
- Minimize the time to finality;
- Minimize the operating cost of nodes.
These three goals are in conflict: To achieve economic finality (i.e., an attacker needs to destroy a large amount of ETH to revert finalized blocks), each validator needs to sign two messages for each finality. Therefore, if there are many validators, either it will take a long time to process all the signatures, or very powerful nodes are needed to handle all the signatures simultaneously.
All of this comes down to a key goal of Ethereum: ensuring that even a successful attack will incur a high cost for the attacker. This is what the term "economic finality" means.
There are counterexamples, such as blockchains without "economic finality" (e.g., Algorand), which solve this problem by randomly selecting a committee to finalize each slot. But the problem with this approach is that if an attacker does control 51% of the validators, the attack cost is extremely low: only a portion of the committee nodes will be detected as participating in the attack and penalized. This means the attacker can attack the chain repeatedly.
Therefore, if Ethereum wants to achieve economic finality, the simple committee-based approach won't work, and full participation of all validators is needed.
Ideally, Ethereum wants to improve the status quo in two ways while retaining economic finality:
1. Finalize blocks within a single slot (ideally, maintaining or even reducing the current 12-second length), rather than 15 minutes
2. Allow validators to stake with 1 ETH (down from 32 ETH)
The first point can ensure that all Ethereum users can benefit from the higher level of security provided by the finality mechanism. Today, most users cannot enjoy this protection because they are unwilling to wait 15 minutes; with the single-slot finality mechanism, users can almost immediately see their transactions finalized after confirmation. Additionally, if users and applications don't have to worry about the possibility of chain rollbacks, it simplifies the protocol and surrounding infrastructure.
The second point is to support solo stakers. According to multiple surveys, the main factor preventing solo staking is the 32 ETH minimum requirement. Lowering the minimum to 1 ETH will solve this problem.
Currently, there is a challenge: the goals of faster finality and more democratic staking conflict with the goal of minimizing overhead. In fact, this is the reason Ethereum did not initially adopt single-slot finality. However, recent research has proposed some possible solutions to this problem.
How it works:
Single-slot finality involves using a consensus algorithm that finalizes blocks within a single slot. This is not an inherently difficult goal to achieve, as many algorithms (such as Tendermint consensus) have already implemented this.
A desirable property unique to Ethereum is (i.e., inactivity leaks): the blockchain can continue to run and eventually recover even if more than 1/3 of the validators are offline.
Single Slot Finality Proposals
There are several leading solutions to the problem of how to make single-slot finality work in the case of a very large number of validators, without causing extremely high node operator costs:
Option one is brute force, implementing better signature aggregation protocols, possibly using ZK-SNARKs, which will make it possible to process millions of validator signatures within a single slot. For example, Horn is one of the proposals put forward to design better aggregation protocols.
Option two is the Orbit committee, a new mechanism that allows a randomly selected medium-sized committee to be responsible for the chain's finality, but retains the attack cost properties. Orbit leverages the pre-existing heterogeneity in validator deposit sizes to achieve as much economic finality as possible, while still giving small validators a matching role.
As shown in the figure, between the range x=0 (Algorand committee, no economic finality) and x=1 (Ethereum's current state), Orbit SSF opens up the middle ground:
1. Where the cost of misbehavior is still very high, to ensure extreme security;
2. But at the same time, only a medium-sized random sample of validators needs to participate in each slot, reducing the node burden.
Option three is dual-staking, a mechanism with two classes of stakers, one with a higher deposit requirement and the other with a lower deposit requirement. Only the higher-deposit tier will directly participate in the process of providing economic finality. As for the rights and responsibilities of the lower-tier deposits, various proposals have been made, including:
- The right to delegate their stake to higher-tier stakers;
- Randomly selecting lower-tier stakers to attest and finalize each block;
- The right to be included in the list, etc.
Each solution has its pros and cons and trade-offs to consider for Ethereum's security experience and staking centralization properties: brute force can solve the problem, but requires aggregating a large number of signatures in a very short time, which is extremely technically challenging; the Orbit committee needs to verify its security and properties and undergo formalization and implementation; the dual-staking mechanism faces centralization risks, which largely depend on the specific rights granted to the lower-staking tier.
In addition to single-slot finality, the single secret leader election is also an important issue in Ethereum's proof-of-stake system. Currently, it is possible to know in advance which validator will propose the next block, creating a security vulnerability where an attacker can monitor the network, identify the IP addresses of the validators, and launch a DoS attack on them just before they are about to propose a block.
The best way to solve this problem is to hide the information about which validator will generate the next block, at least until the block is actually generated.
Election of a Single Secret Leader
Currently, it is possible to know in advance which validator will propose the next block, which creates a security vulnerability: an attacker can monitor the network, determine which validators correspond to which IP addresses, and launch a DoS attack against them just before they are about to propose a block.
The Single Secret Leader Election protocol solves this problem by using some cryptographic techniques to create a "blinded" validator ID for each validator, and then allowing many proposers to rearrange and re-blind the pool of blinded IDs.
However, implementing a sufficiently simple Single Secret Leader Election protocol is not an easy task.
The simplicity of the Ethereum protocol is crucial, and we do not want to further increase its complexity. A simplified SSLE (Simplified SSLE using ring signatures) only uses a few hundred lines of specification code and introduces new assumptions in complex cryptography.
How to implement a sufficiently quantum-resistant SSLE is also a challenge. It may be the case that the "marginal additional complexity" of SSLE will only decrease to a sufficiently low level when we boldly experiment with it and introduce the ability to execute general zero-knowledge proofs in the Ethereum L1 protocol for other reasons.
Additionally, faster transaction confirmation is one of the problems that the Ethereum proof-of-stake system needs to solve.
Further reducing Ethereum's transaction confirmation time (from 12 seconds to 4 seconds) would be valuable. This would significantly improve the user experience of L1 and rollup-based applications, and make DeFi protocols more efficient. It would also make L2 more decentralized, as it would allow a large number of L2 applications to operate on rollups, reducing the need for L2 to build their own committee-based decentralized ordering.
There are roughly two techniques: reducing the slot time to 8 seconds or 4 seconds; allowing proposers to publish pre-confirmations within a single slot period. However, the feasibility of shortening the slot time is currently unclear.
Even today, stakers in many parts of the world have difficulty obtaining proofs quickly enough. Attempts at a 4-second slot time risk validator centralization, and it is impractical to become a validator outside of a few geographically advantaged regions due to latency.
The weakness of the proposer pre-confirmation method is that while it can greatly improve the average inclusion time, it cannot improve the worst-case scenario. Additionally, there is an unresolved issue of how to incentivize pre-confirmations.
Facing the potential threat of quantum computing, Ethereum needs to actively develop quantum-resistant alternatives. Every part of the Ethereum protocol that currently relies on elliptic curves needs to have some hash-based or other quantum-resistant alternatives. This demonstrates the conservatism in the performance assumptions around proof-of-stake design, and the reason for more actively developing quantum-resistant alternatives.
Summary
The Ethereum proof-of-stake system faces many challenges in its technological evolution. Due to the relatively high individual staking threshold on Ethereum, staking service providers like Lido have become the preferred choice for Ethereum node staking, and two-tier staking solutions also carry a certain degree of centralization risk. To address these challenges, single-slot finality and staking democratization, Single Secret Leader Election, faster transaction confirmation, and the development of quantum-resistant alternatives are all important issues that Ethereum needs to address.
Vitalik has comprehensively considered the "The Merge" upgrade and proposed as many technical solution combinations as possible, discussing the design potential of Ethereum's proof-of-stake technology and the currently feasible technical upgrade paths.
In the process of technical upgrades, Ethereum is still constantly exploring and innovating, weighing and choosing between different technical solutions to find the most suitable development path, and achieve higher security, performance and decentralization.
