Original Title: "Sticking to 8192 signatures per slot post-SSF: how and why"

Original Author: Vitalik Buterin, ETH research

Translated by: Luccy, BlockBeats

Editor's Note:

SSF (Single Slot Finality) provides a way to significantly reduce Ethereum's latency. In the field of blockchain consensus mechanisms, finality means that transactions or blocks become irreversible, ensuring that they cannot be tampered with or reversed. Achieving finality is crucial for the trust and security of decentralized systems, as it eliminates the risk of double spending and other malicious activities.

SSF proposes that a single time unit or slot in the blockchain consensus mechanism can be considered "finally determined". Unlike the original Ethereum consensus, it allows all validators to participate in acknowledging or signing slots, reducing transaction confirmation time and improving overall user experience.

Vitalik "returns" to ETH research to discuss why it is necessary to have two signatures per slot for participating validators after SSF, that is, to reach 8192 signature counts, and proposes three hypotheses on how to achieve this goal, namely, full staking, two-layer staking, and rotating participation. He analyzes how to more effectively handle the number of signatures per slot while maintaining protocol security, and discusses their advantages and disadvantages and their impact on the protocol and users. BlockBeats has translated the original article as follows:

One of the main differences between Ethereum and most other (finality-based) proof-of-stake systems is that Ethereum aims to support a large number of validators: currently, we have 895,000 validators, and analysis of Zipf's law suggests that this is equivalent to tens of thousands of independent individuals or entities. The purpose of doing this is to support decentralization, allowing ordinary people to participate in staking without everyone having to give up their agency and hand control over to one of a few staking pools.

However, this approach requires the Ethereum blockchain to process a large number of signatures in each slot (approximately 28,000 today; 1,790,000 after SSF), which is a very high load. To support this load, many technical sacrifices must be made.

· It requires a complex proof propagation mechanism, where proofs are divided between multiple subnets and requires super-optimized BLS signature operations to verify these signatures and so on.

· Currently, we do not have a clear and efficient quantum-resistant alternative solution.

· Fixing forks like view merging has become more complex because individual signatures cannot be extracted.

· It is very difficult to perform SNARK processing on so many signatures. Helios needs to run on a dedicated additional signature called the synchronized committee signature.

· It requires three sub-slots in a slot instead of two, thereby increasing the minimum safe slot time.

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

In addition, it has not even achieved its goal. The minimum requirement for staking is still 32 ETH, which is unattainable for many people. From a logical analysis perspective, it seems impractical to have a system where everyone signs in every slot in the long term, which is the real goal of providing staking for ordinary people: if Ethereum has 500 million users, of which 10% participate in staking, it means that each slot has 100 million signatures. From an information theory perspective, processing penalties in this design requires at least 12.5 MB of data available space per slot, roughly equivalent to the goal of full sharding. Perhaps it is feasible, but requiring staking itself to depend on data availability sampling is a significant complexity gain. Moreover, even so, only about 0.6% of the global population participate in staking, and the computational problem of verifying so many signatures has not yet begun to be addressed.

Therefore, instead of relying on cryptographers to create magic bullets (or magic bulletproof vests) to constantly increase the number of signatures in each slot, I suggest we undergo a philosophical shift: first, let go of such expectations. This will greatly expand the design space for proof of stake and allow for significant technical simplifications, making it more secure by allowing Helios to perform SNARK directly on the Ethereum consensus, and solving quantum resistance problems by making even boring but long-standing signature schemes like Winternitz feasible.

Why not "just use committees"?

Many non-Ethereum blockchains facing this exact problem adopt a committee-based security approach. During each slot, they randomly select N validators (e.g. N ≈ 1000), who are responsible for finalizing that slot. It is worth noting why this approach is insufficient, as it does not provide accountability.

In order to understand the reason, let's assume that a 51% attack has occurred. This may be a finality reversal attack or a censorship attack. To carry out the attack, you still need economic participants to control the majority of the shares in order to reach consensus in the attack, that is, to run the software that participates in the attack and participate in the attack with all validators who are ultimately selected as the committee. Mathematical random sampling ensures this. However, the punishment they receive is minimal because most validators who agree to the attack are not ultimately selected as committee members and therefore are not seen.

Currently, the approach of Ethereum is completely opposite. If a 51% attack occurs, most of the attack validators will have their deposits reduced. The current cost of the attack is about 9 million ETH (about 20 billion US dollars), assuming that the network synchronization is interrupted in the most favorable way for the attacker.

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

This is why I advocate for a moderate solution: make some sacrifices in terms of validator responsibilities, but still maintain a high total reducible ETH amount. In exchange, we can enjoy most of the benefits of a smaller validator set.

What will happen to each slot with 8192 signatures under SSF?

Assuming a traditional two-round consensus protocol is used (like the protocol used by Tendermint, as well as the protocol that SSF will inevitably use), each participating validator requires two signatures per slot. We need to address this reality, and I see three main methods to solve this problem.

Method 1: Fully Adopt Decentralized Staking Pools

The Zen of Python contains a very important sentence:

Regarding the issue of making staking more equitable, Ethereum currently violates this rule because we are simultaneously implementing two different strategies to achieve this goal: (i) small-scale independent staking, and (ii) decentralized staking pools using Distributed Verifier Technology (DVT). Due to the aforementioned reasons, (i) can only support some individual stakers, and there will always be many people whose minimum deposit amount is too high. However, Ethereum is paying a very high cost to support (i) from a technological burden perspective.

One possible solution is to abandon (i) and go all-in on (ii). We can increase the minimum deposit amount to 4096 ETH and set the total validator limit to 4096 (approximately 16.7 million ETH). We expect small-scale stakers to join the DVT pool by providing capital or becoming node operators. To prevent attackers from abusing the system, the role of node operator will be limited by some form of reputation threshold, and each pool will compete by offering different options in this regard. Capital provision will be permissionless.

We can make the staking in this model more "tolerant" by setting a punishment cap (e.g. 1/8 of the total deposit provided). This will allow for less trust in node operators, although caution should be exercised due to the issues outlined.

Method 2: Double Staking

We create two layers of stakers: a "heavy" layer that requires 4096 ETH for finality confirmation, and a "light" layer with no minimum requirement (and no deposit or withdrawal delay, no slashing vulnerability), adding a second layer of security. To finalize a block, both heavy layer finality confirmation and at least 50% of online light validators' proof are required.

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

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia