This article will focus on the Ethereum "Merge" issue: what areas of the technical design of proof of stake can be improved, and what avenues can be taken to achieve these improvements?

Written by: Vitalik Buterin

Translated by: Deng Tong, Jinse Finance

Special thanks to Justin Drake, Hsiao-wei Wang, @antonttc, and Francesco for their feedback and review.

Initially, the "Merge" referred to the most significant event in the history of the Ethereum protocol since its launch: the long-awaited and hard-won transition from proof of work to proof of stake. Today, Ethereum has been a stable proof of stake system for nearly two years, demonstrating excellent performance in stability, performance, and avoiding centralization risks. However, there are still some important areas for improvement in proof of stake.

My roadmap for 2023 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. The former takes over the title of "Merge," while the latter becomes part of the "plague."

This article will focus on the "Merge" part: what areas of the technical design of proof of stake can be improved, and what avenues can be taken to achieve these improvements?

This is not an exhaustive list of improvements for proof of stake; rather, it is a list of ideas that are actively being considered.

Single Slot Finality and Staking Democratization

What problem are we solving?

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 made to balance three goals:

• Maximize the number of validators that can participate in staking (which directly means minimizing the minimum ETH required for staking)
• Minimize completion time
• Minimize the overhead of running nodes

These three goals are in conflict: to achieve economic finality (i.e., attackers need to destroy a large amount of ETH to revert a finalized block), each validator needs to sign two messages every time a finality occurs. Therefore, if you have many validators, either it takes a long time to process all signatures, or you need very powerful nodes to handle all signatures simultaneously.

Note that all of this hinges on a key goal of Ethereum: ensuring that even successful attacks come at a high cost to the attacker. This is what the term "economic finality" means. If we did not have this goal, we could solve the problem by randomly selecting a committee (as Algorand does) to finalize each time slot. However, the problem with this approach is that if an attacker does control 51% of the validators, they can attack at a very low cost (reverting finalized blocks, censoring, or delaying finality): only a portion of the nodes in the committee can be detected as participating in the attack and punished, either through slashing or minor soft forks. This means that attackers can repeatedly attack the chain. Therefore, if we want economic finality, a simple committee-based approach is not feasible, and at first glance, we do indeed need the full set of validators to participate.

Ideally, we want to retain economic finality while improving the current situation in two ways:

• Finalizing blocks within a single time slot (ideally maintaining or even reducing the current length of 12 seconds), rather than 15 minutes
• Allowing validators to stake with 1 ETH (reducing from 32 ETH to 1 ETH)

The first goal is supported by two objectives, both of which can be seen as "aligning Ethereum's properties with those of (more centralized) performance-focused L1 chains."

First, it ensures that all Ethereum users can benefit from a higher level of security provided by the finality mechanism. Currently, most users cannot enjoy this assurance because they are unwilling to wait 15 minutes; with a single slot finality mechanism, users can almost see their transactions finalized immediately after confirmation. Second, if users and applications do not have to worry about the possibility of chain rollbacks (unless a relatively rare inactivity leak occurs), it simplifies the protocol and the surrounding infrastructure.

The second goal stems from the desire to support individual stakers. Repeated surveys have shown that the main factor preventing more people from staking individually is the 32 ETH minimum requirement. Reducing the minimum requirement to 1 ETH would address this issue, making other factors the primary constraints on individual staking.

There is a challenge: the goals of faster finality and more democratized staking conflict with the goal of minimizing overhead. In fact, this is the very reason we did not adopt single-slot finality from the start. However, recent research has proposed several possible ways to address this issue.

What is it and how does it work?

Single slot finality involves using a consensus algorithm that finalizes blocks within a single time slot. This is not an unattainable goal: many algorithms (such as Tendermint consensus) have already achieved this with optimal properties. One ideal property unique to Ethereum, which Tendermint does not support, is inactivity leakage, which allows the chain to continue running and eventually recover even if more than 1/3 of the validators are offline. Fortunately, this desire has been met: there are already proposals to modify Tendermint-style consensus to accommodate inactivity leakage.

Leading single slot finality proposals

The most challenging part of the problem is figuring out how to make single slot finality work effectively with a very high number of validators without leading to extremely high node operator overhead. To this end, there are several leading solutions:

Option 1: Brute force—striving to achieve better signature aggregation protocols, possibly using ZK-SNARKs, which would allow us to handle signatures from millions of validators in each slot.

Horn, one of the proposed designs for better aggregation protocols.

Option 2: Orbit Committee - A new mechanism that allows a randomly selected medium-sized committee to be responsible for finalizing the chain, but in a way that retains the attack cost properties we are looking for.

One way to think about Orbit SSF is that it opens up a compromise option space ranging from x=0 (Algorand-style committee, with no economic finality) to x=1 (the current state of Ethereum), creating points in between where Ethereum still has enough economic finality for extreme security, but at the same time, we gain the efficiency advantage of only needing a medium-sized random sample of validators to participate in each time slot.

Orbit leverages the pre-existing heterogeneity of validator deposit sizes to achieve as much economic finality as possible while still giving smaller validators a corresponding role. Additionally, Orbit uses slow committee rotation to ensure a high degree of overlap between adjacent quorums, thereby ensuring that its economic finality still applies at the committee rotation boundaries.

Option 3: Two-tier staking - A mechanism in which stakers are divided into two categories, one with higher deposit requirements and the other with lower deposit requirements. Only the higher deposit tier would directly participate in providing economic finality. There are various proposals regarding the rights and responsibilities of the lower deposit tier (e.g., see the Rainbow staking post). Common ideas include:

• The right to delegate stakes to higher-tier stakeholders
• Randomly selected lower-tier stakeholders proving and needing to complete each block
• The right to be included in a list

What connections exist with existing research?

• Avenues to achieve single slot finality (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
• Specific proposals for Ethereum single slot finality protocol (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 of Orbit-style mechanisms: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
• 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? What trade-offs need to be considered?

There are four main viable paths (we can also adopt a mixed path):

• Maintain the status quo
• Orbit SSF
• Strong SSF
• SSF with two-tier staking

(1) This means doing nothing and keeping staking as it is, but this will make Ethereum's security experience and staking centralization properties worse than they already are.

(2) Avoid "high-tech" solutions and address the problem by cleverly rethinking protocol assumptions: we relax the requirement for "economic finality," allowing for high attack costs but accepting that the attack cost could be 10 times lower than it is now (for example, an attack cost of $2.5 billion instead of $25 billion). It is generally believed that Ethereum's current economic finality far exceeds what is necessary, and its main security risks lie elsewhere, so this can be considered an acceptable trade-off.

The main work is to verify that the Orbit mechanism is secure and possesses the desired properties, then fully formalize and implement it. Additionally, EIP-7251 (increasing the maximum effective balance) allows for voluntary merging of validator balances, which will immediately reduce chain validation overhead and serve as an effective initial phase for the launch of Orbit.

(3) This avoids clever rethinking and instead forcefully addresses the problem with high-tech solutions. Achieving this requires collecting a large number of signatures (over 1 million) in a very short time (5-10 seconds).

(4) This avoids clever rethinking and high-tech solutions, but it does create a two-tier staking system that still carries centralization risks. The risks largely depend on the specific rights granted to the lower staking tier. For example:

• If lower-tier stakers are required to delegate their proof rights to higher-tier stakers, then the delegation may become centralized, ultimately resulting in two highly centralized staking tiers.
• If random sampling of the lower tier is required to approve each block, then attackers can spend a minimal amount of ETH to prevent finality.
• If lower-tier stakers can only create inclusion lists, then the proof layer may still be centralized, at which point a 51% attack on the proof layer could censor the inclusion list itself.

Multiple strategies can be combined, such as:

• (1 + 2): Add Orbit without implementing single slot finality.
• (1 + 3): Use brute force techniques to reduce the minimum deposit size without implementing single slot finality. The required aggregation amount is 64 times less than in the pure (3) case, making the problem easier.
• (2 + 3): Execute Orbit SSF with conservative parameters (e.g., a 128k validator committee instead of 8k or 32k) and use brute force techniques to make it super efficient.
• (1 + 4): Add Rainbow staking without implementing single slot finality.

How does it interact with other parts of the roadmap?

In addition to other benefits, single slot finality also reduces the risk of certain types of multi-block MEV attacks. Furthermore, in a single slot finality world, the proposer-validator separation design and other protocol-level block production pipelines need to be designed differently.

The weakness of brute force strategies is that they make it more difficult to shorten slot times.

Single Secret Leader Election

What problem are we solving?

Today, which validator will propose the next block is known in advance. This creates a security vulnerability: attackers can monitor the network, identify which validators correspond to which IP addresses, and launch DoS attacks against them when they are about to propose a block.

What is it? How does it work?

The best way to solve the DoS problem is to hide the information about which validator will generate the next block, at least until the block is actually generated. Note that if we remove the "single" requirement, this becomes easy: one solution is to allow anyone to create the next block but require randao to reveal less than 2256 / N. On average, only one validator will be able to meet this requirement—but sometimes there will be two or more, and sometimes none. Combining the "confidentiality" requirement with the "single" requirement has always been a challenge.

The single secret leader election protocol solves this problem by using some cryptographic techniques to create a "blind" validator ID for each validator, then allowing many proposers the opportunity to reshuffle and re-blind the blind ID pool (similar to how mixing networks work). In each time slot, a random blind ID is selected. Only the owner of that blind ID can generate a valid proof to propose a block, but no one knows which validator corresponds to that blind ID.

Whisk SSLE Protocol

What existing research links are there?

• Dan Boneh's paper (2020): https://eprint.iacr.org/2020/025.pdf
• Whisk (a specific 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? What trade-offs need to be considered?

In practice, what remains is to find and implement a sufficiently simple protocol so that we can easily deploy it on the mainnet. We place a high value on Ethereum being a relatively simple protocol, and we do not want to increase complexity further. The SSLE implementations we have seen add hundreds of lines of specification code and introduce new assumptions in complex cryptography. Finding a sufficiently efficient quantum-resistant SSLE implementation is also an outstanding issue.

Ultimately, it may be the case that the "marginal additional complexity" of SSLE will only decrease to a sufficiently low level when we introduce a general zero-knowledge proof mechanism on Ethereum's L1 for other reasons (e.g., state trees, ZK-EVM).

Another option is to completely ignore SSLE and instead use off-protocol mitigations (e.g., at the p2p layer) to address the DoS problem.

How does it interact with other parts of the roadmap?

If we add a proposer-validator separation (APS) mechanism, such as executing tickets, then executing blocks (i.e., blocks containing Ethereum transactions) will not require SSLE, as we can rely on specialized block builders. However, for consensus blocks (i.e., blocks containing protocol messages such as proofs, possibly including lists, etc.), we will still benefit from SSLE.

Faster Transaction Confirmation

What problem are we solving?

Reducing Ethereum's transaction confirmation time further from 12 seconds to 4 seconds is valuable. Doing so will significantly improve the user experience for L1 and aggregation-based applications while making DeFi protocols more efficient. It will also make it easier for L2 to decentralize, as it will allow a large number of L2 applications to operate on aggregation, thereby reducing the need for L2 to build their own decentralized ordering based on committees.

What is it? How does it work?

There are roughly two types of techniques here:

• Reducing slot time, for example, to 8 seconds or 4 seconds. This does not necessarily mean 4 seconds of finality: finality essentially requires three rounds of communication, so we can treat each round of communication as a separate block, resulting in at least preliminary confirmation after 4 seconds.
• Allowing proposers to publish pre-confirmations during the slot process. In extreme cases, proposers can include the transactions they see in real-time in their blocks and immediately publish pre-confirmation messages for each transaction ("My first transaction is 0×1234…", "My second transaction is 0×5678…"). The situation where a proposer publishes two conflicting confirmations can be handled in two ways: (i) by slashing the proposer, or (ii) by using proof-of-stake voting to decide which one came first.

What existing research links are there?

• Based on pre-confirmations: 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 on parallel chains (2018 idea for achieving low latency): https://ethresear.ch/t/staggered-periods/1793

What remains to be done? What trade-offs need to be considered?

The practicality of reducing slot time is currently unclear. Even today, it is difficult for stakers in many parts of the world to obtain proofs quickly enough. Attempting a 4-second slot time carries the risk of a concentrated validator set, and due to latency, it is impractical to become a validator outside of a few privileged regions.

The weakness of the proposer pre-confirmation method is that it can greatly improve the average inclusion time but cannot improve the worst-case inclusion time: if the current proposer is running well, your transaction will receive pre-confirmation in 0.5 seconds instead of being included in (on average) 6 seconds, but if the current proposer is offline or running poorly, you will still have to wait a full 12 seconds to start the next slot and provide a new proposer.

Additionally, there is an outstanding question of how to incentivize pre-confirmations. Proposers have the incentive to maximize their optionality for as long as possible. If validators sign the timeliness of pre-confirmations, then transaction senders can condition part of the fees on immediate pre-confirmation, but this places an additional burden on validators and may make it harder for them to continue acting as neutral "dumb pipes."

On the other hand, if we do not attempt to do this and keep the finality time at 12 seconds (or longer), the ecosystem will place more emphasis on pre-confirmation mechanisms established by Layer 2, and interactions across Layer 2 will take longer.

How does it interact with other parts of the roadmap?

Proposer-based pre-confirmations actually rely on the proposer-validator separation (APS) mechanism, such as executing tickets. Otherwise, the pressure to provide real-time pre-confirmations may place too much concentrated pressure on regular validators.

Other Research Areas

51% Attack Recovery

It is generally believed that if a 51% attack occurs (including attacks that cannot be proven through cryptography, such as censorship), the community will work together to implement a minority soft fork to ensure that the good actors win and that bad actors are slashed or penalized for inactivity. However, this level of over-reliance on the social layer can be considered unhealthy. We can try to reduce reliance on the social layer and automate the recovery process as much as possible.

Complete automation is impossible because if it were, it would count as a >50% fault-tolerant consensus algorithm, and we already know the (very strict) mathematically provable limitations of such algorithms. However, we can achieve partial automation: for example, if a client has seen a transaction for a sufficiently long time, it can automatically refuse to accept a chain as finalized, or even refuse to accept it as the head of a fork choice. A key goal is to ensure that the bad actors in an attack cannot quickly achieve victory.

Increasing the Quorum Threshold

Today, if 67% of stakers support it, a block will be finalized. Some believe this is too aggressive. Throughout Ethereum's history, there has only been one (very brief) finality failure. If this percentage is increased to 80%, the number of additional non-finality periods will be relatively low, but Ethereum will gain security: specifically, many more controversial situations will lead to a temporary halt in finality. This seems much healthier than allowing the "wrong side" to win immediately, whether the wrong side is the attacker or the client has a bug.

This also answers the question of "what is the point of individual stakers." Today, most stakers are staking through pools, and it seems unlikely that individual stakers will achieve up to 51% of staked ETH. However, if we put in the effort, it seems possible to enable individual stakers to reach a minority that can block the majority, especially if the majority reaches 80% (thus requiring only 21% to block the majority). As long as individual stakers do not participate in a 51% attack (whether it be a finality reversal or censorship), such an attack will not achieve a "clean victory," and individual stakers will actively help organize a minority soft fork.

Quantum Resistance

Metaculus currently believes that, despite the large margin of error, quantum computers are likely to start breaking cryptography at some point in the 2030s:

Quantum computing experts, such as Scott Aaronson, have recently begun to take the possibility of quantum computers working effectively in the medium term more seriously. This has implications for the entire Ethereum roadmap: it means that every part of the Ethereum protocol currently relying on elliptic curves will need some hash-based or other quantum-resistant alternative. This particularly means we cannot assume that we will be able to rely on the excellent properties of BLS aggregation forever to handle signatures from a large set of validators. This proves that conservatism in performance assumptions for proof-of-stake design is reasonable and is also the reason for more proactive development of quantum-resistant alternatives.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。