Vitalik: What else can be improved in Ethereum POS?

Original title:>Possible Futures of the Ethereum Protocol, Part 1: The Merge

Author: Vitalik, founder of Ethereum, compiled: Deng Tong, Bitchain Vision

Initially, “The Merge” refers to the most important incident of the Ethereum agreement since its launch: long -awaited and hard -won transition from POW to POS.Nowadays, Ethereum has been operating stably for nearly two years, and this POS has performed very well in terms of stability, performance and avoiding centralized risks.However, POS still has some important areas to be improved.

The roadmap I painted in 2023 divides it into several parts:Improve technical characteristics, such as stability, performance, and accessability to small verificationrsAnd economic change to cope with centralized risks.The former became a part of “The Merge”, and the latter became part of “The Scourit”.

This article will focus on the “The Merge” section:What are the technical design of the Equity Certificate (POS) that can be improved and what are the ways to achieve these improvements?

This is not a detailed list of things that can be done by POS; on the contrary, this is a list of ideas that are actively considering.

Single Slot Finality (SSF) and pledge democratization (SSF)

What problems are we solving?

At present, Ethereum needs 2-3 EPOCH (about 15 minutes) to finally determine a block, and 32 ETH is required to become a pledker.

This was originally a compromise that made a balance between the three goals below:

• Maximize the number of verifications participating in pledge (which directly means the minimum quantity required for the minimum pledge)

• Minimize the final time

• To minimize the expenses of running nodes

These three goals are conflicting with each other: in order to achieve “economic final certainty” (Economic Finality, that is, attackers need to destroy a large number of ETH to restore the final determined block). Each final determination, each verification personTwo messages need to be signed.Therefore, if you have many verificationrs, you will take a long time to handle all the signatures, or you need very powerful nodes to handle all signatures at the same time.

Please note that all this depends on a key goal in Ethereum: ensuring that even successful attacks will cause high costs to attackers.This is the meaning of the word “economic final definity”.If we do not have this goal, then we can finally determine each slot to solve this problem by random selection of a committee (such as Algrand).But the problem of this method is that if the attacker does control 51% of the verifications, then they can attack at very low costs (revoked the final determined block, review or delay the final determination): Only the one in the committee of the committee is the one in the committee.Some nodes can be tested to participate in attacks and punish them, whether through SLASH or a small number of soft forks.This means that an attacker can repeatedly attack the chain.Therefore, if we want the economic final certainty, then the simple committee -based method is not unable. At first glance, we do need to participate in the collective participation.

Ideally, we hope to retain the economic final certainty, and at the same time improve the status quo in the two areas:

1. Complete the block within a slot (ideally, keep or even reduce the length of the current 12 seconds) instead of 15 minutes

2. Allowed verifications to pledge 1 ETH (originally 32 ETH)

The rationality of the first goal comes from the two goals. Both goals can be regarded as “the attributes of Ethereum are consistent with the attributes of the L1 chain that focus on performance (more centralized).”

First of all, it ensures that all Ethereum users can benefit from higher -level security guarantees achieved through the final determination mechanism.Nowadays, most users cannot enjoy this guarantee because they are unwilling to wait for 15 minutes; and using single slots to finalize the mechanism, users can immediately see the final confirmation of the transaction after confirming the transaction.Secondly, if users and applications do not have to worry about the possibility of chain rollback (unless there is a relatively rare non-activated leakage -Nactivity Leak), it simplifies the agreement and infrastructure around it.

The second goal is because of the desire to support SOLO pledges.Repeated public opinion surveys over and over again show that the main factor to prevent more people’s SOLO pledge is the minimum limit of 32 ETH.Reducing the minimum limit to 1 ETH will solve this problem so that other problems have become the main factor restricting SOLO pledge.

There is a challenge: faster certainty and more democratic pledge targets conflict with the target of minimized expenses.In fact, this fact is all the reasons why we did not adopt a single slot at first.However, recent studies have proposed some possible methods to solve this problem.

What is SSF and how does it work?

Single Slot’s final determination involves the use of consensus algorithms that finalize the block in a slot.This is not a difficult goal in itself: many algorithms (such as Tendermint consensus) have achieved this with the best attribute.One of the ideal attributes unique to Ethereum is “No activity leak Inactivity Leak”. Tendermint does not support the attribute. Even if more than one -third of the verificationrs are offline, the attribute allows the chain to continue to run and finally recover.Fortunately, this wish has been resolved: there are already proposals to modify the Tendermint consensus to adapt to the Inactivity Leak.

The leading single slot final definition proposal

The most difficult part of the problem is how to make a single Slot’s final certainty play a role when the number of verifications is very high, and it will not lead to high -end node operator overhead.For this reason, there are several leading solutions:

• Options 1: Battle-strive to achieve better signature aggregation protocol, which may use ZK-Snarks, which actually allows us to process the signatures from millions of verifications in each slot.

Horn, one of the designs proposed for a better aggregation agreement.

• Option 2: ORBIT Committee-a new mechanism that allows randomly selected medium committees to be responsible for completing the chain, but to retain the way we seek the cost characteristics of attack costs.
  One way to think about the ORBIT SSF is that it has opened up a compromise option space, from the X = 0 (Algorand style committee, which is the final certainty of the economy)At this point, Ethereum still has sufficient economic final certainty to ensure extremely secure, but at the same time, we have obtained the efficiency advantage of each slot with only medium -sized verifications to participate in each slot.

ORBIT uses the pre -existence of heterogeneity in the deposit scale to obtain as much economic final definition as possible, and will still give the corresponding role of SOLO verifications.In addition, ORBIT uses a slow commission to ensure that the high degree of overlapping between adjacent legal number is used to ensure that its economic final certainty is still applicable to the committee’s rotation boundary.

• Options 3: Two-layer pledge-one mechanism, of which the pledgee is divided into two categories, one type of deposit requirements are higher, and the other type of deposit requirements are low.Only levels with higher deposit requirements will directly participate in providing economic final certainty.There are various proposals (for example, see, seeRainbow pledgeArticle) to specifically explain what rights and responsibilities of levels with lower deposit requirements.Common ideas include:

• The right to entrust pledges to higher -level pledges

• Randomly extract lower -level pledges to prove and finally determine each block

• The right to generate the right of inclusion lists

What are the connections with existing research?

• The way to realize the final determination of a single slot (2022):>https://notes.ethereum.org/@vbuterin/single_slot_finality

• The specific proposal of the Ethereum Single Slot’s final determination protocol (2023):https://eprint.iacr.org/2023/280

• ORBIT SSF:>https://ethresear.ch/t/orbit-sSF-SOLO-Staking-Friendly-Validator-set-Management- SSF/19928>

• Further analysis of the ORBIT style mechanism:

• Horn, signature aggregation agreement (2022):>>https://ethresear.ch/t/horn-collecting-signatures-faster-finality/142199

• Signature merger of large -scale consensus (2023):>https://ethresear.ch/t/signature-Merging-For- Large-sCale- Consonsus/17386?u=asn>

• >KhovratovichWaiting for the signature aggregation agreement proposed:>>https://hackmd.io/@7dpnyqjkqgeyc7wmlpxhtq/bykm3ggu0 #/

• Stark -based signature aggregation (2022):https://hackmd.io/@vbuterin/stark_aggregation

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

What should I do to do?What do you need to weigh?

There are four main possible paths to choose from (we can also adopt a mixed path):

1. Maintain the status quo

2. ORBIT SSF

3, brute force SSF

4. SSF with two layers of pledge mechanism

1 means that you do n’t do anything and keep it, but this will make Ethereum ’s security experience and pledge centralization attributes worse than originally.

2 Avoid “high -tech”, and to solve the problem by subtly reorganizing the agreement: we relax the requirements of “economic final definiation”, so that we require that attack is expensive, but the cost of attack may be 10 times lower than that of the present now.(For example, the attack cost is $ 2.5 billion instead of $ 25 billion).It is generally believed that Ethereum’s current economic final definition far exceeds the level it needs. Its main security risk is elsewhere, so it can be said that this is acceptable sacrifice.

The main work is to verify whether the ORBIT mechanism is safe and has the attributes we want, and then fully formally formally form and implement it.In addition, EIP-7251 (increase maximum effective balance) allows voluntary verification to merge, which will immediately reduce chain verification overhead and serve as an effective initial stage launched by ORBIT.

3 Avoid ingenious re -thinking, but forcibly solve the problem with high -tech.To do this, it takes a short period of time (5-10 seconds) to collect a large number of signatures (more than 1 million).

4 Avoid ingenious re -thinking and high -tech, but it does create a two -layer pledge system, which still has centralized risks.The risk depends to a large extent on the specific rights obtained by the lower pledged layer.For example:

• If low -level pledges need to entrust the right to prove to senior pledges, then entrustment may be centralized, and in the end we will get two highly concentrated pledge levels.

• If random samples are required to approve each block, the attacker only needs to spend a small amount of ETH to prevent the final certainty.

• If the lower -level pledgee can only produce a list, the proof layer may maintain centralization. At this time, the 51% attack on the proof layer can review the list itself.

You can combine multiple strategies, such as:

1 + 2: Add ORBIT, but do not execute the final nature of the single slot

1 + 3: Use strong technology to reduce the minimum deposit amount without the need for single slots to finalize.The required aggregation amount is 64 times less than the situation (3), so the problem becomes easier.

2 + 3: Use conservative parameters to execute ORBIT SSF (for example, the 128K verification committee, not 8K or 32K), and use brute force technology to make it super efficient.

1 + 4: Add Rainbow pledge, but do not make a single slot final confirmation

How does SSF interact with other parts of the roadmap?

In addition to other benefits, the final determination of SLOT also reduces the risk of multiple MEV attacks of certain types of MEV.In addition, in the final determination world of single slots, the proofer-proposal separation design and other inner block production channels need to be designed in different ways.

The weakness of the brute force strategy is that they make it more difficult to reduce SLOT time.

Single Secret Leader Election (SSLE)

What problems are we solving?

Today, which verifications will propose that the next block can be known in advance.This will produce a security vulnerability: the attacker can monitor the network, determine which IP address corresponding to which verifications, and launch a DOS attack on it when the verifier is about to propose the block.

What is SSLE and how does it work?

The best way to solve the DOS problem is to hide which verifications will generate the next block information, at least before the actual block is generated.Please note that if we delete the “single” requirements, this is easy: a solution is to allow anyone to create the next block, but Randao is required to reveal less than 2 256/ n.On average, only one verifier can meet this requirement -but sometimes there are two or more, sometimes there will be no.It has always been a problem to combine the “secret” requirements with the “single” requirements.

A single secret leader election agreement uses some encrypted technology to create a “blind” verification person ID for each verification person, and then give many proposalists the opportunity to reorganize and re -blindize the blind ID pool (this is similar to the MixNet working method of working ways), Thus solved this problem.In each time, a random blind ID is selected.Only the owner of the blind ID can generate effective proofs to propose the block, but no one knows which verification of the blind ID.

Whisk SSLE protocol

What are the connections with existing research?

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

• Whisk (specific proposal for Ethereum, 2022):https://ethresear.ch/t/whisk-a-practical-shuffle-base-sprotocol-thereum/11763

• Single secret leader election label on ethresear.ch:https://ethresear.ch/tag/SINGLE-SECRET- Leader-Election

• Simplified SSLE using the ring signature:https://ethresear.ch/t/simplify-ssle/12315

What should I do to do?What do you need to weigh?

In fact, the rest is to find and implement a simple and simple protocol so that we can easily implement it on the main network.We attach great importance to Ethereum as a fairly simple agreement, and we don’t want the complexity to increase further.The SSLE we saw has added hundreds of line specifications and introduced new assumptions in complex encryption.Finding a sufficiently effective anti -quantum SSLE implementation is also a suspended problem.

In the end, this may occur: only when we boldly tried and introduced the mechanism to execute the general zero-knowledge certificate in the Ethereum protocol in the L1 in other reasons (such as the state tree, ZK-EVM)”Sexual” will fall to a sufficiently low level.

Another choice is to ignore SSLE at all, but to solve the DOS problem with an alleviating measure (such as at the P2P layer) outside the protocol.

How can it interact with other parts of the roadmap?

If we add a proofer-the ATTESTER-PROPOSER Separation (APS) mechanism, such as Execution T 4, then the execution block (that is, the block trading of Ethereum) will not need SSLE because we can rely on it to rely onSpecialized block builders.However, for consensus blocks (that is, blocks including protocol messages such as proofs, parts that may include lists, etc.), we will still benefit from SSLE.

Fast trading confirmation

What problems are we solving?

It is valuable that the transaction confirmation time of Ethereum is further shortened from 12 seconds to 4 seconds.This will significantly improve L1 and Rollups -based user experience, while making the DEFI protocol more efficient.It will also make L2 easier decentralization because it will allow a large number of L2 applications to work on ROLLUPS -based, thereby reducing L2 to build its own committee -based decentralized sorting needs.

Fast trading confirmationWhat and how do it work?

There are generally two technologies here:

1. Reduce the slot time, such as reducing to 8 seconds or 4 seconds.This does not necessarily mean the final certainty of 4 seconds: the final determination itself requires three -wheeled communication, so we can set each round of communication to a separate block, which will be at least preliminary confirmation after 4 seconds.

2. Allowers to publish pre -confirmation during the period of SLOT.In extreme cases, the proposal can include the transactions they see in real time, and immediately publish the pre -confirmation message for each transaction (“My first transaction is 0 × 1234 …”, “I amThe second transaction is 0 × 5678 … “).The proposal issued two conflicts of conflict confirmation can be handled in two ways: (i) punishment for the proposal, or (ii) to use witnesses to vote for which one is earlier.

What are the connections with existing research?

• Based on pre -confirmation:https: //ethresear.ch/t/based-preconfirmations/17353

• Agreement forced proposal promises (PEPC):>https://ethresear.ch/t/unbundling-PBS-TOWARDS-PROTOCOL-PROPOSER-COMMITMENTS- PEPC/13879

• The staggered cycle on the parallel chain (the idea of ​​low latency in 2018):https://ethresear.ch/t/staggered- periods/1793

What should I do to do?What do you need to weigh?

It is unclear to shorten the feasibility of SLOT time.Even today, pledgeers in many areas in the world are difficult to obtain proof enough.There is a risk of concentration of verifications at the SLOT time of 4 seconds, and due to delay, it is impractical to become an authenticator outside a few privileges.

The weakness of the proposal pre -confirming the method is that it can greatly improve the inclusion time of the average situation, but it cannot improve the worst situation: if the current proposal is running well, your transaction will be pre -confirmed in 0.5 seconds instead of (average) 6 6 6It is included in seconds, but if the current proposal is offline or running poorly, you still need to wait for 12 seconds to start the next time and provide new proposals.

In addition, there is an unreasonable problem, that is, how to motivate pre -confirmation.The proposal has the motivation to maximize their options as long as possible.If the witness signed the pre -confirmed timeliness, then the transaction sender can immediately predict the conditions to be predicted, but this will bring an additional burden to the witness, and it may make it difficult for the witness to continue to act as a neutral “dumb dumbDumb Pipe.

On the other hand, if we do not try to do so and keep the final determination time in 12 seconds (or longer), the ecosystem will pay more attention to the pre -confirmation mechanism of the 2nd floor, and the interaction across the 2nd floor will take longer.time.

How can it interact with other parts of the roadmap?

Based on the pre-confirmation of the proposal, it actually relies on the proofer-proposal separation (APS) mechanism, such as

Quantum computing experts, such as Scott Aaronson, have recently begun to consider the possibility of quantum computers in the middle of the middle period.This will have an impact on the entire Ethereum route map: this means that each Ethereum protocol that rely on the elliptical curve needs some hash or other anti -quantum alternatives.This particularly means that we cannot assume that we will always be able to rely on the excellent performance of BLS aggregation to handle the signatures from the large -scale authentication set.This proves that the conservativeness of the assumption of the design performance of equity is reasonable, and it is also the reason why the anti -quantum alternative scheme is more actively developing.

Thank you for feedback and review of Justin Drake, Hsiao-Wei Wang,@Antonttc and Francesco.