Vitalik's new work: Potential technical routes of Ethereum's post-Merge roadmap

avatar
ChainCatcher
10-15
This article is machine translated
Show original

Original title: Possible futures of the Ethereum protocol, part 1: The Merge

By: Vitalik Buterin

Compiled by: Tia, Techub News

Originally, “the Merge” referred to the transition from proof of work to proof of stake. Ethereum has been running stably as a proof of stake system for nearly two years now, and proof of stake has performed very well in terms of stability , performance, and avoiding centralization risks . However, there are still some areas where proof of stake needs improvement.

The roadmap I drew up for 2023 includes the following parts: improved technical features, such as increased stability, performance, and accessibility to small validators, and economic changes to address centralization risks. The former is part of "the Merge", while the latter is part of "the Scourge".

This post will focus on “the Merge”: how can the technical design of Proof of Stake be improved, and what are the ways to achieve these improvements?

Please note that this is a list of ideas and not an exhaustive list of things that need to be done for Proof of Stake.

Single slot finality and democratizing staking

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 staker. This is a compromise made to balance three goals :

  • Maximize the number of validators participating in staking (which directly means minimizing the minimum amount of ETH required to stake )

  • Minimize finalization time

  • Minimize the overhead of running a node

These three goals are in conflict with each other: in order to achieve economic finality (i.e. an attacker would need to destroy a lot of ETH to revert a finalized block), every time finality is achieved, each validator needs to sign two messages. Therefore, if you have many validators, it will either take a long time to process all the signatures, which requires very powerful node performance to process all signatures at the same time.

Ultimately this is all in service of this goal: it would take a huge cost for an attacker to succeed . This is what the term “economic finality” means. If this goal is not taken into account, then we can just randomly select a committee (such as Algorand does ) to finalize each slot. But the problem with this approach is that if an attacker is able to control 51% of the validators, then they can attack (undo finalized blocks, censor or delay finalization) at a very low cost: only the part of the nodes they are on the committee can be detected as participating in the attack and punished, either through slashing or a few soft forks . This means that an attacker can attack the chain over and over again many times. Therefore, if we want to achieve economic finality, a simple committee-based system will not work.

At first glance, we do need all validators to participate.

But ideally, we can still achieve economic finality while improving the following two parts:

  1. Complete blocks in one slot (ideally, keeping or even reducing the current length of 12 seconds) instead of 15 minutes

  2. Allow validators to stake 1 ETH (previously 32 ETH)

These goals can all be thought of as “bringing Ethereum’s performance closer to the (more centralized) performance-focused L1.”

But it will still use a higher security finalization mechanism to ensure the security of all Ethereum users . Today, most users cannot get this level of security because they are unwilling to wait 15 minutes; using the Single slot finalization mechanism, users can achieve transaction finality almost immediately after confirming the transaction. Secondly, if users and applications don’t have to worry about chain rollbacks, the protocol and the surrounding infrastructure can be simplified, and there are fewer factors that the protocol and infrastructure need to consider.

The second goal is to support solo stakers (users stake independently instead of relying on institutions). The main factor for staking is the 32 ETH minimum. Lowering the minimum to 1 ETH would solve this problem to the point where other issues become the main factor limiting staking alone.

But there is a challenge: faster finality and more democratized staking conflict with minimizing overhead . This is why we did not adopt Single Slot Finality in the first place. However, recent research has suggested some possible solutions to this problem.

What is it and how does it work?

Single-slot finality refers to a consensus algorithm that finalizes blocks within a single slot. This is not a difficult goal in itself: many algorithms (such as Tendermint consensus) already achieve this with optimal properties. However, Tendermint does not have the " inactivity leaks " property that is unique to Ethereum. This property allows Ethereum to continue to operate and eventually recover even if more than 1/3 of the validators are offline. Fortunately, there is now a solution to achieve this property: there is a proposal to modify Tendermint-style consensus to accommodate inactivity leaks.

Single slot finality proposal

The hardest part is figuring out how to make Single slot finality work with very high validator counts without incurring extremely high node operator overhead. Currently, there are several solutions:

  • Option 1: Brute Force — Work towards a better signature aggregation protocol, perhaps using ZK-SNARKs, which would essentially allow us to process signatures from millions of validators per slot.

Horn, one of the protocols designed to optimize aggregation

  • Option 2: Orbit Committee , a new mechanism that randomly selects medium-sized committees to determine chain finality, but at the same time has a high economic attack cost.

One way to think about Orbit SSF is that it opens up a compromise option that does not have to have economic finality like Algorand-style committees, but can also achieve some degree of high economic attack costs, so that Ethereum still has enough economic finality to ensure extreme security, but at the same time it can also improve the efficiency of a single solt.

Orbit exploits pre-existing heterogeneity in validator deposit sizes to obtain as much economic finality as possible, while still giving small validators a role to participate. Additionally, Orbit uses a slow committee rotation mechanism to ensure a high overlap between adjacent quorums, ensuring that its economic finality still applies across committee rotations.

  • Option 3: Two-tier staking, which divides stakers into two categories, one with a higher deposit requirement and one with a lower deposit requirement. Only stakers in the higher deposit requirement tier will have direct economic finality. There have been some proposals (see, for example, the Rainbow staking post ) to specify what rights and responsibilities stakers in the lower deposit tier would need. Common ideas include:

    • Delegating equity to higher-level stakeholders

    • Randomly select lower-tier stakers to attest and finalize each block

    • The right to generate inclusion lists

What are the connections with existing research?

What else needs to be done? What are the trade-offs?

There are four paths to choose from (we can also take a hybrid path):

  1. Maintaining the status quo

  2. Orbit SSF

  3. Brute force SSF

  4. SSF with a two-tier staking mechanism

(1) means doing nothing and leaving things as they are, but this would make Ethereum’s security experience and staking centralization properties worse than they otherwise would be.

(2) Avoid “high tech” and solve the problem by cleverly rethinking the protocol assumptions: we relax the “economic finality” requirement so that we require attacks to be expensive, but the cost of an attack can be 10 times lower than it is today (e.g., $2.5 billion instead of $25 billion). It is widely believed that Ethereum’s economic finality today is far beyond what it needs to be, and its main security risks are elsewhere, so this is arguably an acceptable sacrifice.

The main work is to verify that the Orbit mechanism is secure and has the properties we want, and then fully formalize and implement it. In addition, EIP-7251 (increase the maximum valid balance) allows voluntary validators to balance the Merge, which immediately reduces the verification overhead of the chain and serves as an effective initial stage for the Orbit rollout.

(3) Use high technology to force the problem. To do this, a large number of signatures (more than 1 million) must be collected in a very short period of time (5-10 seconds).

(4) It creates a two-tier staking system that does not require overthinking the mechanism or using high technology, but it does still have centralization risks. The risk depends largely on the specific rights obtained by the lower staking layer. For example:

  • If low-level stakers need to delegate their attestation power to high-level stakers, delegation may become centralized and we will end up with two highly concentrated staking tiers.

  • If random sampling of lower layers is required to approve each block, then an attacker can prevent finality by spending only a tiny amount of ETH.

  • If lower-level stakers can only produce inclusion lists, then the proof layer may remain centralized, at which point a 51% attack on the proof layer can censor the inclusion list itself.

It is possible to combine multiple strategies, for example:

(1 + 2): Add Orbit, but do not enforce Single slot finality

(1+3): Use brute force techniques to reduce the minimum deposit amount without single slot finalization. The amount of aggregation required is 64 times less than 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): Add rainbow pledge, but do not finalize Single slot

How does it interact with the rest of the roadmap?

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

The weakness of achieving your goal by brute force is that reducing the slot time becomes much more difficult.

Single secret leader election

What problem are we solving?

Today, it is known in advance which validator will propose the next block. This creates a security vulnerability: an attacker can monitor the network, determine 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 and 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). If the "single" requirement is not taken into account (only one party generates the next block), one solution is to allow anyone to create the next block, but this requires the randao reveal to be less than 2 (256) / N. Usually, only one validator can meet this requirement (but sometimes there are two or more, and sometimes there are none). Therefore, combining the "confidentiality" requirement with the "single" requirement has always been a difficult problem.

The single secret leader election protocol solves this problem by using some cryptography 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 (similar to how mixnets work). Within each slot, a random blind ID is chosen. Only the owner of that blind ID can generate a valid proof to propose a block, but no one knows which validator that blind ID corresponds to.

Whisk SSLE protocol

What are the connections with existing research?

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 that we can easily implement it on mainnet. We value simplicity in Ethereum very much, and we don’t want complexity to grow further. The SSLE implementations we’ve seen add hundreds of lines of code to the specification and introduce new assumptions in complex cryptography. Finding a sufficiently efficient quantum-resistant SSLE implementation is also an open problem.

It may eventually be the case that the “marginal additional complexity” of SSLE will only drop to a low enough level if we take the plunge and introduce a mechanism for performing general zero-knowledge proofs in the Ethereum protocol at L1 for other reasons (e.g. state tries, ZK-EVM).

Another option is to not bother with SSLE at all, and instead use extra-protocol mitigations (eg at the p2p layer) to address the DoS problem.

How does it interact with the rest of the roadmap?

If we add an attester-proposer separation (APS) mechanism, such as execution tickets , then execution 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 attestations, parts that may contain lists, etc.), we will still benefit from SSLE.

Faster transaction confirmation

What problem are we solving?

It would be valuable to further reduce Ethereum's transaction confirmation time , from 12 seconds to 4 seconds. Doing so would significantly improve the user experience of L1 and rollups-based protocols while making defi protocols more efficient. It would also make L2 more decentralized, as it would allow a large number of L2 applications to run based on rollups , reducing the need for L2 to build its own committee-based decentralized ordering.

What is it and how does it work?

There are roughly two techniques here:

  1. Reduce the slot time , say to 8 seconds or 4 seconds. This does not necessarily mean 4-second finality: finality itself requires three rounds of communication, so we can make each round a separate block, which will get at least tentative confirmation after 4 seconds.

  2. Allow proposers to publish preconfirmations during a slot . In extreme cases, proposers can include transactions they see in their blocks in real time, and immediately publish preconfirmation messages for each transaction ("My first transaction is 0x1234...", "My second transaction is 0x5678..."). The situation where a proposer publishes two conflicting confirmations can be handled in two ways: (i) slash the proposer , or (ii) use witnesses to vote on which one is earlier.

What are the connections with existing research?

What's left to do? What are the trade-offs?

It is unclear how feasible it is to reduce slot times. Even today, it is difficult for stakers in many parts of the world to get proofs fast enough. Attempting 4 second slot times risks centralizing validators and making it impractical to become a validator outside of a few privileged regions due to latency.

The weakness of the proposer preconfirmation approach is that it greatly improves average-case inclusion time, but not the worst-case : if the current proposer is performing well, your transaction will be preconfirmed in 0.5 seconds instead of being included in (on average) 6 seconds, but if the current proposer is offline or performing poorly, you will still have to wait a full 12 seconds before the next slot can start and a new proposer can be provided.

Additionally, there is an open question of how to incentivize preconfirmations . Proposers have an incentive to maximize their optionality for as long as possible. If witnesses sign off on the timeliness of preconfirmations, then transaction senders can make part of their fees conditional on immediate preconfirmations, but this places an additional burden on witnesses and may make it more difficult for witnesses to continue to act as neutral "dumb pipes."

On the other hand, if we don’t try to do this and keep finality times at 12 seconds (or longer), the ecosystem will place more emphasis on L2 pre-confirmation mechanisms and interactions across L2s will take longer.

How does it interact with the rest of the roadmap?

Proposer-based pre-confirmation actually relies on attestor-proposer separation (APS) mechanisms such as execution tickets . Otherwise, the pressure to provide real-time pre-confirmation may be too concentrated for regular validators.

Other research areas

51% Attack Recovery

It is often assumed that if a 51% attack were to occur (including attacks that cannot be cryptographically proven, such as censorship), the community would come together to implement a minority soft fork, ensuring that the good guys win and the bad guys are leaked or slashed for inactivity. However, this level of over-reliance on the social layer is arguably unhealthy. We can try to reduce reliance on the social layer by making the recovery process as automated as possible .

Full automation is impossible, since that would be equivalent to a >50% fault-tolerant consensus algorithm, and we already know the (very strict) mathematically provable limitations of such algorithms . But we can achieve partial automation: for example, a client could automatically refuse to accept a chain as final, or even as the head of a fork choice, if it censors transactions that the client has seen for a long time. A key goal is to ensure that an attacker cannot at least achieve a quick and complete victory .

Raising the quorum threshold

Today, blocks are finalized as long as 67% of stakers support it. Some argue that this is too aggressive. In the entire history of Ethereum, there has only been one (very brief) failure of finality. If this ratio were raised to 80%, the number of additional non-finality periods would be relatively low, but Ethereum would gain security: in particular, many of the more contentious situations would result in temporary halts in finality . This seems like a healthier situation than one where the "wrong party" wins immediately, whether that wrong party is an attacker or the client has a bug.

This also answers the question of “what’s the point of solo stakers?”. Today, with most stakers already staking through staking pools, it seems unlikely that a single staker could stake 51% of ETH. However, it seems possible for a single staker to achieve quorum-blocking of the minority if we try, especially if the quorum is 80% (so only 21% is needed for quorum-blocking of the minority). As long as solo stakers do not participate in a 51% attack (either by finality reversal or censorship), such an attack will not result in a “clean win”, and solo stakers will have an incentive to help organize a minority soft fork.

Resistant to quantum attacks

Metaculus currently believes that quantum computers could begin to crack cryptography sometime in the 2030s, albeit with large margins of error:

Quantum computing experts, such as Scott Aaronson, have also recently started to take the possibility of quantum computers actually working in the medium term more seriously. This will have 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 specifically means that we cannot assume that we will be able to rely forever on the superior performance of BLS aggregation to process signatures from large validator sets. This justifies conservatism in performance assumptions of proof-of-stake designs, and is a reason to more aggressively develop quantum-resistant alternatives.

Sector:
Layer 1
Smart Contracts
Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
1
Comments
Relevant content