Vitalik: The Future of the Ethereum Agreement (Part 1)

Author: Vitalik; Compiled by Deng Tong, Bitchain Vision

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

Initially, the “merger” refers to the most important event in history since the launch of the Ethereum protocol: the long-awaited and hard-won transition from proof of work to proof of stake.Today, Ethereum has become a stable proof of stake system for nearly two years, and this proof of stake has performed very well in stability, performance and avoiding centralized risks.However, there are still some important areas for proof of stake to be improved.

My 2023 roadmap divides it into several parts: improving technical features such as stability, performance and accessibility to smaller validators, and economic changes to address centralized risks.The former took over the title of “merger”, while the latter became part of “scourge.”

This article will focus on the “merge” section: What other improvements can be made in the technical design of proof of stake and what ways can these improvements be made?

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

Single-trough finality and pledge democratization

What problems are we solving?

Nowadays, it takes 2-3 epochs (about 15 minutes) to complete a block and 32 ETH to become a staker.This was originally a compromise to balance three goals:

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

These three goals are conflicting: in order to achieve economic finality (i.e., the attacker needs to destroy a large amount of ETH to restore the finalized block), each time the finalization is finalized, each validator needs to sign two messages.So if you have many validators it either takes a long time to process all signatures or a very powerful node to process all signatures at the same time.

Note that it all depends on one key goal of Ethereum: ensuring that even successful attacks can bring high costs to attackers.This is what the term “economic finality” means.If we don’t have this goal, we can solve this problem by randomly selecting a committee (such as what Algorand does) to finalize each slot.But the problem with this approach is that if the attacker does control 51% of the validators, they can attack at a very low cost (recovering finalized blocks, reviewing or delaying finalization): only part of the committeeNodes can be detected as participating in an attack and being punished, whether through cuts or a few soft forks.This means that the attacker can attack the chain repeatedly.So if we want economic finality, a simple approach based on the committee won’t work, and at first glance, we do need a full set of validators to participate.

Ideally, we want to retain economic endurance while improving the status quo in two ways:

End blocks in one slot (ideally keep or even reduce the current 12 seconds length) instead of 15 minutes
Allow verifiers to stake with 1 ETH (down from 32 ETH to 1 ETH)

The first goal is proven by two goals, both of which can be seen as “consistent with the properties of Ethereum with the properties of the (more centralized) performance-oriented L1 chain.”

First, it ensures that all Ethereum users benefit from higher levels of security assurance achieved through finalization mechanisms.Today, most users cannot enjoy this kind of guarantee because they are unwilling to wait 15 minutes; and through the single-slot finalization mechanism, users can see the finalization of the transaction almost immediately after the transaction is confirmed.其次，如果用户和应用程序不必担心链回滚的可能性（除非出现相对罕见的不活动泄漏情况），那么它就简化了协议和周围的基础设施。

第二个目标是出于支持单独质押者的愿望。一次又一次的民意调查反复表明，阻止更多人单独质押的主要因素是 32 ETH 的最低限额。将最低限额降低到 1 ETH 将解决这个问题，以至于其他问题成为限制单独质押的主要因素。

存在一个挑战：更快的确定性和更民主化的质押目标都与最小化开销的目标相冲突。事实上，这个事实就是我们一开始不采用单槽确定性的全部原因。然而，最近的研究提出了一些解决这个问题的可能方法。

What is it and how does it work?

单时隙最终性涉及使用在一个时隙内最终确定区块的共识算法。This is not a difficult goal in itself: many algorithms (such as the Tendermint consensus) have implemented this with optimal properties.An ideal property unique to Ethereum is an inactive leak that Tendermint does not support, which allows the chain to continue running and eventually recover even if more than 1/3 of the validators are offline.Fortunately, this wish has been fulfilled: there have been proposals to modify the Tendermint-style consensus to accommodate inactive leaks.

Leading single-trough final proposal

The hardest part of the problem is figuring out how to make single-slot finality work when the number of validators is very high without causing extremely high node operator overhead.To do this, there are several leading solutions:

Option 1:Brute force – Efforts to implement better signature aggregation protocols, possibly using ZK-SNARKs, which actually allows us to process the signatures of millions of validators in each slot.

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

Option 2:Orbit Commission – A new mechanism that allows randomly selected medium commissions to be responsible for finalizing the chain, but in a way that retains the attack cost attributes we are looking for.

One way to think about Orbit SSF is that it opens up a space for compromise options ranging from x=0 (Algorand-style committee, no economic finality) to x=1 (Ethereum status), opening up points in the middle, EthereumThere is still sufficient economic finality to achieve extreme safety, but at the same time we gain the efficiency advantage of only a medium-sized random validator sample involved in each period.

Orbit takes advantage of the pre-existing heterogeneity of the size of the verifier’s deposit to achieve as much economic finality as possible, while still giving small verifiers the corresponding role.Furthermore, Orbit uses slow committee rotations to ensure high overlap between adjacent quorums, thus ensuring that its economic finality still applies to committee rotation boundaries.

Option 3:Two-layer pledge – a mechanism in which pledges are divided into two categories: one has higher deposit requirements and the other has lower deposit requirements.Only levels with higher deposit requirements will directly participate in providing economic finality.There are various proposals regarding what rights and responsibilities are exactly at the lower deposit requirements (see Rainbow pledge post for example).Common ideas include:

The right to delegate equity to higher-level equity holders
Randomly drawn lower-level stakeholders prove and need to complete each block
Right to generate inclusion list

What are the connections to existing research?

Ways to achieve single-slot finality (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality

Specific proposals for the Ethereum single-trough final agreement (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 mechanism: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF

Horn, Signature Aggregation Agreement (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219

Signature merger of large-scale consensus (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn

The signature aggregation protocol proposed by Khovratovich et al.: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/

Signature aggregation based on STARK (2022): https://hackmd.io/@vbuterin/stark_aggregation

Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

What else is left to do?What to weigh?

There are four main viable paths (we can also use a hybrid path):

Maintain the status quo
Orbit SSF
Powerful SSF
SSF with two-layer staking

(1) means not doing anything and keeping the staking as it is, but this will make Ethereum’s security experience and staking centralized properties worse than it would have been.

(2) Avoid “high-tech” and solve the problem by cleverly rethinking the protocol assumptions: We relaxed the “economic endurance” requirement so that we asked that attacks were expensive, but acceptable attacks could be 10 times less expensive than they are now(For example, the attack costs $2.5 billion, not $25 billion).It is widely believed that Ethereum’s economic endurance today is far beyond the level it needs to be, and its main security risks are elsewhere, so this is arguably an acceptable sacrifice.

The main job is to verify that the Orbit mechanism is safe and has the properties we want, then fully formalize and implement it.Additionally, EIP-7251 (increase the maximum valid balance) allows voluntary validator balance consolidation, which immediately reduces chain verification overhead and serves as an effective initial stage for Orbit launch.

(3) Avoid clever rethinking, but use high technology to force the problem.To do this, it takes a large number of signatures (over 1 million) in a very short time (5-10 seconds).

(4) Avoid clever rethinking and high-tech, but it does create a two-tier staking system that still has centralized risks.The risk depends largely on the specific rights obtained by the lower pledge tiers.For example:

If the low-level stakeholder needs to delegate his proof rights to the high-level stakeholder, the delegation may be centralized, and we will eventually get two highly centralized stakeholders.
If a random sampling of the lower tiers is required to approve each block, then an attacker can spend a very small amount of ETH to prevent finality.
If a low-level stakeholder can only make an inclusion list, the proof layer may still be centralized, and at this point the 51% attack on the proof layer can review the inclusion list itself.

Various strategies can be combined, such as:

(1 + 2): Add Orbit without performing single slot finality.
(1 + 3): Use brute force technology to reduce the minimum deposit size without performing single-slot finality.The amount of polymerization required is 64 times less than the pure (3) case, so the problem becomes easier.
(2 + 3): Perform 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): Add rainbow staking without executing single slot finality.

How does it interact with the rest of the roadmap?

Among other benefits, single slot endurance reduces the risk of certain types of multi-block MEV attacks.Furthermore, in a single-slot finality world, prover-proposer separation design and other protocol block production pipelines need to be designed in different ways.

The weakness of violent strategies is that they make it more difficult to shorten slot time.

Single Secret Leader Election

What problems do we want to solve?

Today, it is known to which validator will propose the next block.This creates a security vulnerability: an attacker can monitor the network, identify which validators correspond to which IP addresses, and launch a DoS attack on the validator when it is 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 generate the next block, at least before the block is actually generated.Note that if we remove the “single” requirement, this is easy: One solution is to let anyone create the next block, but requires randao to reveal less than 2256/N.On average, only one validator can meet this requirement – but sometimes there will be two or more, and sometimes there will be zero.Combining the “confidentiality” requirement with the “single” requirement has always been a difficult problem.

The single secret leader election protocol solves this problem by creating a “blind” verifier ID for each verifier using some encryption techniques, and then gives many proposers the opportunity to shuffle and reblinify the blind ID pool (which is similar toHow 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 verifier the blind ID corresponds to.

Whisk SSLE protocol

What are the links to existing research?

Dan Boneh’s paper (2020): https://eprint.iacr.org/2020/025.pdf

Whisk (Ethereum’s specific proposal, 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 signature: https://ethresear.ch/t/simplified-ssle/12315

What else is left to do?What to weigh?

Actually, all that’s left is to find and implement a protocol that is simple enough so that we can easily implement it on the mainnet.We take Ethereum as a fairly simple protocol and we don’t want further complexity to increase.The SSLE implementation we are seeing adds hundreds of lines of specification code and introduces new assumptions in complex encryption.It is also an open question to find a sufficiently efficient quantum SSLE implementation.

Eventually, this may occur: The “marginal additional complexity” of SSLE will only decrease when we introduce a common zero-knowledge proof mechanism on L1 of the Ethereum protocol for other reasons (e.g., state trees, ZK-EVMs).to a low enough level.

Another option is to ignore SSLE at all, and use out-of-protocol mitigations (such as at the p2p layer) to solve DoS problems.

How does it interact with the rest of the roadmap?

If we add a prover-proposer separation (APS) mechanism, such as executing tickets, then executing blocks (i.e. blocks containing Ethereum transactions) will not require SSLE because we can rely on a dedicated block builder.However, for consensus blocks (i.e. blocks containing protocol messages (such as proof, sections that may contain lists, etc.), we will still benefit from SSLE.