Vitalik New Article: How does SSF stabilize the number of Ethereum single-slot signatures at 8192?

Original title: “Sticking to 8192 signatures per slot post-SSF: how and why”

Original article by Vitalik Buterin, ETH research

Original compilation: Luccy, BlockBeats

*Editor’s note: SSF (Single Slot Finality) stands for Single Slot Finality, which provides a way to significantly reduce Ethereum’s latency. In BlockchainConsensus Mechanism, finality means that a transaction or Block becomes irrevocable, ensuring that it cannot be tampered with or reversed. Achieving finality is essential for the trust and security of Decentralization systems, as it eliminates the risk of double spending and other malicious activity. *

*The SSF suggests that in BlockchainConsensus Mechanism, a single time slot or unit of time can be considered “final”. Unlike the original EthereumConsensus, it allows all validators to participate in acknowledging or signing slots, reducing transaction confirmation time and improving the overall user experience. *

Vitalik “returns” ETH research explores why it is necessary to have participating validators have two signatures per slot after SSF, that is, to reach 8192 signatures, and puts forward 3 hypotheses on how to achieve this goal, namely full staking, two-tier staking, and rotational participation, analyzes how to handle the number of signatures per slot more efficiently while maintaining the security of the protocol, and discusses their advantages and disadvantages and the impact on the protocol and users. BlockBeats compiled the original text as follows:

One major difference between Ethereum and most other (with finality) PoS systems is that Ethereum strives to support a very large number of validators: currently we have 895, 000 validators, which analysis of Zipf’s law shows is equivalent to tens of thousands of independent individuals or entities. The purpose of this is to support Decentralization, enabling ordinary people to participate in staking without requiring everyone to give up their ability to act and hand over control to one of the few staking pools.

However, this approach requires the Ethereum chain to process a large number of signatures per slot (about 28, 000 today; 1, 790, 000 after SSF), which is a very high load. In order to support this load, a number of technical sacrifices must be made:

• It requires a complex proof propagation mechanism where proofs are split across multiple subnets, super-optimized BLS signature operations to verify those signatures, and so on.
• We currently do not have a clear and efficient alternative to quantum resistance.
• Fork selection fixes like view merging are made more complicated by the inability to extract individual signatures.
• SNARK processing is difficult for so many signatures. Helios needs to run on a specialized extra signature, called a synchronous committee signature.
• It requires three sub-slots within a slot instead of two, which increases the safe minimum slot time.

A signature aggregation system may seem reasonable at first glance, but in reality it creates systemic complexity that pervades the entire system.

Moreover, it did not even achieve its goals. The minimum requirement for staking is still 32 ETH, which is out of reach for a lot of people. From a logical analysis point of view alone, the goal of a system that allows everyone to sign every slot in the long term does not seem feasible to truly provide staking for ordinary people: if Ethereum has 500 million users, 10% of whom participate in staking, that means 100 million signatures per slot. From an information theory perspective, processing penalties in this design requires at least 12.5 MB of data free space per slot, roughly equivalent to the goal of full sharding. It may be possible, but requiring the staking itself to rely on data availability sampling is a big complexity gain. And even then, only about 0.6% of the global population participates in staking, and it hasn’t yet begun to involve the computational problem of verifying so many signatures.

So instead of relying on cryptography to create magic bullets (or magic bulletproofs) to achieve an ever-increasing number of signatures per slot, I suggest a philosophical shift: first abandon such expectations. This would greatly expand PoS design space and allow for a great deal of technical simplification, make it more secure by allowing Helios to SNARKs directly on the EthereumConsensus, and solve the quantum resistance problem by making even an uninteresting but long-standing signature scheme like Winternitz feasible.

Why not “Use Committees Only”?

Many non-EthereumBlockchain facing this exact problem adopt a committee-based approach to security. During each slot, they randomly select N validators (e.g., N ≈ 1000) who are responsible for ultimately confirming the slot. It is worth reminding why this approach is not sufficient, as it does not provide accountability.

To understand why, let’s say that 51% of the attacks occurred. This could be a terminal reversal attack or a censorship attack. In order to carry out the attack, you still need the economic actor to control the majority of the stake to agree on the attack, i.e., run the software involved in the attack and participate in the attack with all the validators who are ultimately elected to the committee. Mathematically random sampling ensures this. However, the penalties they received for this were minimal, as most validators who agreed to the attack were not ultimately elected to the committee and were therefore not seen.

Currently, Ethereum does the exact opposite. If a 51% attack occurs, the majority of the entire attack validator collection will have their deposit cut. The current cost of the attack is about 9 million ETH (about $20 billion), and it is assumed that the network synchronization outage is carried out in the most favorable way for the attacker.

I think it’s a high cost, but it’s too high a price to pay, and we can make some sacrifices on this issue. Even an attack cost of 1-2 million ETH is perfectly sufficient. In addition, the main centralization risk that currently exists in Ethereum is reflected in a completely different place: if the minimum deposit amount is dropped to near zero, the power of large-scale staking pools will not be much diminished.

That’s why I’m advocating a middle-of-the-road solution: make some sacrifices on validator responsibilities but still maintain a high total cuttable ETH amount, and in exchange we can enjoy most of the benefits of a smaller set of validators.

What happens if there are 8192 signatures per slot under SSF?

Assuming a traditional two-round Consensus protocol (like the protocol used by Tendermint, and the protocol that SSF inevitably uses), each participating validator needs two signatures per slot. We need to address this reality, and I see that there are three main ways to solve this problem.

Method 1: Fully adopt Decentralization staking pools

The Python Zen contains a very crucial phrase:

There should be one-- and preferably only one --obvious way to do it. ）

Ethereum is currently violating this rule when it comes to making staking equal, as we are simultaneously implementing two different strategies to achieve this goal: (i) small-scale independent staking, and (ii) Decentralization staking pools using distributed validator technology (DVT). For the above reasons, (i) only a few individual stakers can be supported, and there will always be many people whose minimum deposit amount is too large. However, Ethereum is paying a very high technical burden cost to support (i).

One possible solution is to give up (i) and go all out (ii). We can increase the minimum deposit amount to 4096 ETH and set the total validator cap to 4096 (about 16.7 million ETH). Small-scale stakers are expected to join the DVT pool: by providing capital or by becoming Node Operators. To prevent abuse by attackers, the Node Operator role needs to be limited by the prestige threshold in some way, and pools will compete by offering different options in this regard. The provision of capital will be permissionless.

We can make staking in this model more “forgiving” by setting a penalty cap (e.g., 1/8 of the total deposit provided). This will allow for less trust in Node operators, although it is worth treating with caution due to the issues outlined.

Method 2: Two layers of staking

We created two layers of stakers: a “heavy” layer that requires 4096 ETH to participate in final state confirmation, and a “light” layer with no minimum requirements (no deposit and withdrawal delays, no cut-down vulnerabilities), adding a second layer of security. In order for a block final state to be confirmed, both a heavy layer final state confirmation and at least 50% of the light layer of online light validator proofs are required.

This heterogeneity is beneficial for censorship and attack resistance, as both heavy and light layers need to be corrupted in order for an attack to be successful. If one layer is corrupted and the other is not, the chain will stop, and if the heavy layer is corrupted, it can be punished.

Another benefit of this is that the light tier can contain ETH that is also used as in-app collateral. The main drawback is that staking becomes less equal by establishing a divide between small-scale and large-scale stakers.

Method 3: Rotational participation (i.e. committee but accountability)

We take an approach similar to the supercommittee design proposed here: for each slot, we select 4096 currently active validators and carefully adjust the set in each slot so that we still have security.

However, we made some different parameter choices within this framework in order to get “value for money” in it. In particular, we allow validators to participate with arbitrarily high balances, and if validators have more than a certain amount of ETH (which would have to be floating), they participate in committees in each slot. If a validator has N<M ETH, then they have a probability of N/M in any given slot to participate in the committee.

Here we have an interesting lever to decouple the “weight” on the incentive purpose from the “weight” on the Consensus purpose: the reward for each validator in the committee should be the same (at least for validators using ≤M ETH) to keep the average reward proportional to the balance, but we can still calculate the Consensus validator weights in the committee by weighting ETH. This ensures that the amount of ETH needed to break finality is equal to more than 1/3 of the total ETH in the committee.

A rough analysis of Zipf’s law calculates this amount of ETH as follows:

• At each quadratic level of the total balance, the number of validators is inversely proportional to that balance level, and the total balance of these validators will be the same.
• As a result, the committee will have an equal amount of ETH from each balance level participating, except for those that exceed barrier M, where validators are always on the committee.

Note: In order to show the calculated data more clearly, the next steps will be screenshots

The main disadvantage of this approach is a slight increase in the complexity of randomly selecting validators in the protocol so that we can get consensus security in case of committee changes.

The main advantage is that it retains independent staking in a recognizable form, maintains a single-class system, and even allows the minimum deposit amount to be dropped to a very low level (e.g. 1 ETH).

Conclusion

If we decide to stick with 8192 signatures after the SSF protocol, it will make the work much easier for technology implementers and builders of side infrastructure such as light clients. Consensus clients can be run more easily by anyone, and users, staking enthusiasts, and others can immediately work on this assumption. The future load of the Ethereum protocol is no longer unknown: the future can be boosted by a hard fork, but only if developers are confident that the technology has improved enough to handle more signatures per slot at the same level of ease.

The rest of the work will be to decide which of the three methods we want to adopt, or maybe a completely different approach. It’s going to be a question of what trade-offs we’re comfortable with, specifically how we deal with related issues like liquid staking, which may be solved separately from the technical issues that are now much easier.

Link to original article