Author: Vitalik Buterin
Compiled by: Deng Tong, Golden Finance
Special thanks to Justin Drake, Hsiao-wei Wang, @antonttc and Francesco for their feedback and reviews.
Initially, “merger” referred to the most important event in the history of the Ethereum protocol since its launch: the long-awaited and hard-won transition from Proof-of-Work (PoW) to Proof-of-Stake (PoS). Today, Ethereum has been a stably operating proof-of-stake system for nearly two years, which excels in stability, performance, and avoidance of centralization risks. However, there are still some important areas where proof of stake needs improvement.
My roadmap for 2023 breaks it down into several parts: improvements to technical features such as stability, performance, and accessibility to smaller validators, and economic changes to address centralization risks. The former took over the title of "Merge", while the latter became part of "The Scourge".
This article will focus on the “merging” part: is there any room for improvement in the technical design of Proof of Stake? What are some ways to achieve these improvements?
This is not an exhaustive list of improvements that could be made to Proof of Stake; rather, it is a list of ideas that are being actively considered.
Single-slot finality and staking democratization
What problem are we solving?
Today, it takes 2-3 epochs (~15 minutes) to complete a block and requires 32 ETH to become a staker. This was originally a compromise to strike a balance between three goals:
Maximize the number of validators that can participate in staking (this directly means minimizing the minimum ETH required to stake)
Minimize completion time
Minimize the overhead of running nodes
These three goals are in conflict with each other: in order to achieve economic finality (i.e. an attacker would need to destroy a large amount of ETH to recover a finalized block), each validator needs to sign two messages every time it is finalized. So if you have many validators, it will either take a long time to process all the signatures, or you will need very powerful nodes to process all the signatures at the same time.
Note that this all hinges on a key goal of Ethereum: ensuring that even a successful attack imposes a high cost on the attacker. This is what the term "economic finality" means. If we don't have this goal, then we can solve this problem by randomly selecting a committee (such as Algorand does) to finalize each slot. But the problem with this approach is that if an attacker does control 51% of the validators, they can attack at a very low cost (recovering finalized blocks, censorship, or delaying finalization): only part of the committee Nodes can be detected as participating in attacks and punished, either through slashing or a handful of soft forks. This means that an attacker can repeatedly attack the chain multiple times. So if we want economic finality, a simple committee-based approach won't work, and at first glance we do need a full set of validators to participate.
Ideally, we want to preserve economic finality while improving the status quo in two ways:
Finalize blocks within a time slot (ideally, keep or even reduce the current length of 12 seconds) instead of 15 minutes
Allow validators to stake with 1 ETH (reduced from 32 ETH to 1 ETH)
The first goal is evidenced by two goals, both of which can be seen as “aligning the properties of Ethereum with those of (more centralized) performance-focused L1 chains.”
First, it ensures that all Ethereum users benefit from a higher level of security achieved through the finalization mechanism. Today, most users do not enjoy this guarantee because they are unwilling to wait 15 minutes; with a single-slot finalization mechanism, users can see the transaction finalized almost immediately after the transaction is confirmed. Second, it simplifies the protocol and surrounding infrastructure if users and applications don't have to worry about the possibility of chain rollback (barring the relatively rare case of inactivity leaks).
The second goal is driven by the desire to support individual stakers. Poll after poll has repeatedly shown that the main thing stopping more people from staking alone is the 32 ETH minimum. Lowering the minimum to 1 ETH would solve this problem to the point that other issues become the main factor limiting individual staking.
There’s a challenge: the goals of faster finality and more democratized staking both conflict with the goal of minimizing overhead. In fact, this fact is the entire reason why we don't adopt single-slot determinism in the first place. However, recent research suggests some possible solutions to this problem.
What is it and how does it work?
Single-slot finality involves the use of a consensus algorithm that finalizes blocks within one slot. This is not an unattainable goal in itself: many algorithms (such as Tendermint consensus) already achieve this with optimal properties. A desirable property unique to Ethereum that Tendermint does not support is inactivity leakage, which allows the chain to continue functioning and eventually recover even if more than 1/3 of the validators are offline. Fortunately, this wish has been granted: there are already proposals to modify Tendermint-style consensus to accommodate inactivity leaks.
Leading Single Slot Finality Proposal
The hardest part of the problem is figuring out how to make single-slot finality work with very high validator counts without incurring extremely high node operator overhead. There are several leading solutions for this:
Option 1: Brute force. Working towards a better signature aggregation protocol, possibly using ZK-SNARKs, which would essentially allow us to handle signatures from millions of validators per slot.
Horn, one of the proposed designs for better aggregation protocols.
Option 2: Orbit Council. A new mechanism that allows a randomly selected medium-sized committee to be responsible for finalizing the chain, but in a way that preserves the attack cost properties we are looking for.
One way to think about Orbit SSF is that it opens up a space of compromise options, ranging from x=0 (Algorand-style committee, no economic finality) to x=1 (Ethereum's status quo), opening up a point in the middle where Ethereum remains There is enough economic finality to achieve extreme security, but at the same time we gain the efficiency advantage of only requiring a moderately sized random sample of validators to participate in each epoch.
Orbit leverages the pre-existing heterogeneity in validator deposit sizes to gain as much economic finality as possible, while still giving small validators a relevant 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 to 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 tiers with higher deposit requirements are directly involved in providing economic finality. There are various proposals as to what exactly the rights and responsibilities would be for tiers with lower deposit requirements (see the Rainbow staking post for example). Common ideas include:
The right to delegate interests to higher-level equity holders
A randomly selected lower level stakeholder is attested and required to complete each block
Right to be included in the list
What are the connections to existing research?
Pathways to single-slot finality (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
Specific proposal for Ethereum’s 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 mechanics: 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's left to do? What are the trade-offs?
There are four main possible paths (we can also take hybrid paths):
maintain status quo
Orbit SSF
Strong SSF
SSF with two levels of staking
(1) means doing no work and keeping staking as is, but this would make the security experience and staking centralization properties of Ethereum worse than it otherwise would be.
(2) Avoid the "high tech" and solve the problem by cleverly rethinking the protocol assumptions: we relaxed the "economic finality" requirement so that we require that the attack cost is high, but accept that the attack cost may be 10 lower than now times (for example, the attack cost $2.5 billion instead of $25 billion). It is widely believed that Ethereum today has far more economic finality than it needs to, and its main security risks lie elsewhere, so this is arguably an acceptable sacrifice.
The main effort is to verify that the Orbit mechanism is safe and has the properties we want, and then to fully formalize and implement it. Additionally, EIP-7251 (Increase Maximum Valid Balance) allows for voluntary validator balance consolidation, which immediately reduces chain validation overhead and serves as an effective initial phase for Orbit’s rollout.
(3) Avoiding clever rethinking and instead brute-forcing problems with high technology. Doing this requires collecting a large number of signatures (1 million+) in a very short time (5-10 seconds).
(4) Avoids clever rethinking and high technology, but it does create a two-tier staking system that still has centralization risks. The risk depends heavily on the specific rights acquired by the lower staking tiers. For example:
If lower-level stakers need to delegate their attestation rights to higher-level stakers, then delegation may become centralized and we end up with two highly centralized staking tiers.
If random sampling of lower levels is required to approve each block, an attacker can spend a tiny amount of ETH to prevent finality.
If low-level stakers can only make inclusion lists, then the proof layer may still be centralized, at which point a 51% attack on the proof layer can censor the inclusion list itself.
Multiple strategies can be combined, such as:
(1 + 2): Increase Orbit without performing single-slot finality.
(1 + 3): Use brute force techniques to reduce the minimum deposit size without enforcing single-slot finality. The amount of polymerization required is 64 times less than in the pure (3) case, so the problem becomes easier.
(2 + 3): Execute Orbit SSF with conservative parameters (e.g. 128k validator committee instead of 8k or 32k) and use brute force techniques to make it super efficient.
(1 + 4): Adds rainbow staking without enforcing single-slot finality.
How does it interact with other parts of the roadmap?
Among other benefits, single-slot finality reduces the risk of certain types of multi-block MEV attacks. Furthermore, in a single-slot finality world, the prover-proposer separation design and other intra-protocol block production pipelines need to be designed differently.
The weakness of brute force strategies is that they make it more difficult to shorten the slot time.
Single Secret Leader Election
What problem are we trying to solve?
Today, which validator will propose the next block is known in advance. This creates a security hole: an attacker could monitor the network, identify which validators correspond to which IP addresses, and launch a DoS attack on the validators 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 of which validator will produce the next block, at least until the block is actually produced. Note that this is easy if we remove the "single" requirement: one solution would be to let anyone create the next block, but require randao to reveal less than 2256/N. On average, only one validator meets this requirement - but sometimes there are two or more, and sometimes there are zero. Combining the requirement of "confidentiality" with the requirement of "singleness" has always been a difficult problem.
The single-secret leader election protocol solves this problem by using some cryptographic techniques to create a "blind" validator ID for each validator, and then giving many proposers the opportunity to shuffle and re-blind the pool of blind IDs (something like in the way hybrid networks work). At each period, a random blind ID is selected. Only the owner of the blind ID can generate a valid proof to propose a block, but no one knows which validator the blind ID corresponds to.
What are the links to existing research on the Whisk SSLE protocol?
Dan Boneh's paper (2020): https://eprint.iacr.org/2020/025.pdf
Whisk (a practical 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's left to do? What are the trade-offs?
Really, all that's left is to find and implement a protocol that's simple enough so that we can easily implement it on mainnet. We take Ethereum very seriously as a fairly simple protocol and we don't want complexity to increase further. The SSLE implementations we've seen add hundreds of lines of canonical code and introduce new assumptions in complex encryption. Finding a sufficiently efficient implementation of quantum-resistant SSLE is also an open problem.
It may eventually happen that the "marginal additional complexity" of SSLE will only decrease when we introduce a general zero-knowledge proof mechanism on L1 of the Ethereum protocol for other reasons (e.g. state trees, ZK-EVM) to a sufficiently low level.
Another option is to ignore SSLE at all and instead use out-of-protocol mitigations (such as at the p2p layer) to address DoS issues.
How does it interact with other parts of the roadmap?
If we incorporate a prover-proposer separation (APS) mechanism, such as execution tickets, then SSLE will not be required to execute blocks (i.e., blocks containing Ethereum transactions) since we can rely on specialized block builders. However, for consensus blocks (i.e. blocks that contain agreement information (e.g. proofs, parts that may include manifests, etc.)) we will still benefit from SSLE.
Faster transaction confirmation
What problem are we solving?
There is value in further reductions in Ethereum’s transaction confirmation times, from 12 seconds to 4 seconds. Doing so will significantly improve L1 and aggregation-based user experience while making defi contracts more efficient. It will also make it easier for L2 to decentralize, as it will allow a large number of L2 applications to work on aggregation-based ordering, thereby reducing the need for L2 to build its own committee-based decentralized ordering.
what is it? How does it work?
There are roughly two techniques here:
Reduce the slot time, for example to 8 seconds or 4 seconds. This doesn't necessarily mean 4 seconds of finality: finality essentially requires three rounds of communication, so we could make each round of communication a separate block, with at least preliminary confirmation after 4 seconds.
Proposers are allowed to issue pre-confirmations during the slot. In extreme cases, proposers could include transactions they see into their blocks on the fly and immediately publish pre-confirmation messages for each transaction ("My first transaction was 0x1234...", "My The second transaction is 0×5678…”). The situation where a proposer issues two conflicting confirmations can be handled in two ways: (i) by cutting back on proposers, or (ii) by using provers to vote on which one is earlier.
What are the links to existing research?
Based on 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 on parachains (ideas for low latency in 2018): https://ethresear.ch/t/staggered-periods/1793
What’s left to do, and what are the trade-offs?
It's unclear how practical the reduced slot time will be. Even today, stakers in many parts of the world struggle to obtain proofs quickly enough. Attempting a 4 second slot time risks concentrating the validator set, and making it impractical to become a validator outside of a few privileged regions due to latency.
The weakness of the proposer preconfirmation method is that it greatly improves the average case inclusion time, but not the worst case inclusion time: if the current proposer is working well, your transaction will be preconfirmed in 0.5 seconds, whereas It's not (on average) 6 seconds to be included, but if the current proposer is offline or not performing well, you still have to wait a full 12 seconds before the next slot can start and provide a new proposer.
Additionally, there is the open question of how to incentivize pre-confirmation. Proposers have an incentive to maximize their optionality for as long as possible. If the prover signed a pre-confirmation of timeliness, then the transaction sender could condition part of the fee on immediate pre-confirmation, but this would place additional burden on the prover and potentially make it more difficult for the prover to continue to act as a neutral " Dumb pipe".
On the other hand, if we don't try to do this and keep the finalization time at 12 seconds (or longer), the ecosystem will place more emphasis on the pre-confirmation mechanism enacted by Layer 2 and interactions across Layer 2 will take longer. time.
How does it interact with other parts of the roadmap?
Proposer-based pre-confirmation actually relies on prover-proposer separation (APS) mechanisms such as execution tickets. Otherwise, the pressure to provide instant pre-confirmation may create too concentrated pressure on regular validators.
Other research areas
51% attack recovery
It is generally believed that in the event of a 51% attack (including attacks that cannot be cryptographically proven, such as censorship), the community will come together to implement a minority soft fork, ensuring that the good guys win and the bad guys are leaked or curtailed due to inactivity. However, this level of over-reliance on the social layer is arguably unhealthy. We can try to reduce dependence on the social layer and make the recovery process as automated as possible.
Full automation is not possible, because if it were, this would count as a >50% fault-tolerant consensus algorithm, and we already know the (very strict) mathematically provable limits of such algorithms. But we can achieve partial automation: for example, a client can automatically refuse to accept a chain as final, or even refuse to accept it as the head of a fork selection, if the client has reviewed a transaction that the client has seen for long enough. A key goal is to ensure that the bad guys in the attack don't at least get a quick victory.
Increase quorum threshold
Today, a block will be finalized if 67% of stakers support it. Some think this is too radical. In the entire history of Ethereum, there has only been one (very brief) final failure. If this percentage were increased to 80%, the number of increased non-finality epochs would be relatively low, but Ethereum would gain security: in particular, many of the more controversial situations would result in a temporary suspension of finality. This seems much healthier than "wrong side" winning immediately, whether the wrong side is the attacker, or there's a bug on the client side.
This also answers the question "What is the point of a separate staker?" Today, the majority of stakers are already staking through pools, and it seems unlikely that a single staker will receive as much as 51% of staked ETH. However, getting a solo staker to reach a minority that blocks the majority seems possible if we try hard, especially if the majority reaches 80% (so only 21% is needed to block the majority). As long as lone stakers do not participate in a 51% attack (whether finality reversal or review), this attack will not achieve a "clean victory", and lone stakers will actively help organize minority soft forks.
Quantum resistance
Metaculus currently believes that, albeit with large margins of error, quantum computers will likely begin breaking cryptography sometime in the 2030s:
Quantum computing experts, such as Scott Aaronson, have also recently begun to consider more seriously the possibility that quantum computers will actually work in the medium term. This has implications for the entire Ethereum roadmap: it means that every part of the Ethereum protocol that currently relies on elliptic curves will need some kind of hash-based or other quantum-resistant alternative. This means in particular that we cannot assume that we will ever be able to rely on the superior properties of BLS aggregation to handle signatures from large sets of validators. This justifies conservatism in proof-of-stake design performance assumptions and is a reason to more aggressively develop quantum-resistant alternatives.
(The above content is excerpted and reprinted with the authorization of our partner PANews, original text link | Source: Golden Finance)
Statement: The article only represents the author's personal views and opinions, and does not represent the objective views and positions of the blockchain. All contents and opinions are for reference only and do not constitute investment advice. Investors should make their own decisions and transactions, and the author and Blockchain Client will not be held responsible for any direct or indirect losses caused by investors' transactions.
"Vitalik Buterin writes an article discussing: How can Ethereum PoS be improved?" This article was first published on (Block Guest).
