Original title: Sticking to 8192 signatures per slot post-SSF: how and why
Original author: Vitalik Buterin, ETH research
Original compilation: Luccy, BlockBeats
Editors note: SSF (Single Slot Finality) stands for Single Slot Finality, which provides a way to significantly reduce Ethereums latency. In the field of blockchain consensus mechanisms, finality means that a transaction or block becomes irrevocable, ensuring that it cannot be tampered with or reversed. Achieving finality is critical to trust and security in decentralized systems because it eliminates the risk of double spending and other malicious activity.
The SSF suggests that in the blockchain consensus mechanism, a single time slot or unit of time can be considered finalized. It differs from the original Ethereum consensus in that it allows all validators to participate in endorsing or signing slots, reducing transaction confirmation time and improving the overall user experience.
Vitalik returns to ETH research and discussed why it is necessary to allow participating validators to have two signatures per slot after SSF, that is, reaching 8192 signatures. At the same time, he proposed three assumptions on how to achieve this goal, namely full staking, Two-tier staking and rotating participation analyze how to handle the number of signatures per slot more efficiently while maintaining the security of the protocol, and discuss their advantages and disadvantages and their impact on the protocol and users. BlockBeats compiles the original text as follows:
One of the key differences between Ethereum and most other proof-of-stake (with finality) systems is that Ethereum strives to support an extremely large number of validators: currently we have 895,000 validators, and Zipfs Law analysis shows that this Equivalent to tens of thousands of independent individuals or entities. The purpose of this is to support decentralization and enable ordinary people to participate in staking without requiring everyone to give up their ability to act and hand over control to one of a handful of staking pools.
However, this approach requires the Ethereum chain to handle a large number of signatures per slot (about 28,000 today; 1,790,000 after SSF), which is a very high load. To support this load, a number of technical sacrifices had to 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 have no clear quantum-resistant alternative that can effectively cope with it.
Forked selection fixes like view merging become more complex because individual signatures cannot be extracted.
SNARKing so many signatures is difficult. Helios needs to run on a specialized additional signature called a sync committee signature.
It requires three subslots within a slot instead of two, thereby increasing the safe minimum slot time.
A signature aggregation system may seem reasonable at first glance, but in reality it creates systemic complexities that pervade the entire system.
Furthermore, it doesnt even achieve its goal. The minimum requirement for staking is still 32 ETH, which is out of reach for many. Just from a logical analysis point of view, the goal of a system that allows everyone to sign in every slot and truly provides staking for ordinary people seems unfeasible in the long term: if Ethereum has 500 million users, and 10% of them participate Staking, that means 100 million signatures per slot. From an information theoretic perspective, processing in this design requires at least 12.5 MB of data free space per slot, roughly equivalent to the goal of full sharding. Maybe doable, but requiring the staking itself to rely on data availability sampling is a big complexity gain. And even so, only about 0.6% of the global population participates in staking, and that doesn’t even begin to involve the computational problems of verifying so many signatures.
So rather than relying on cryptographers to create magic bullets (or magic bulletproofs) to achieve an ever-increasing number of signatures in each slot, I suggest we make a philosophical shift: give up on such expectations in the first place. This will greatly expand the proof-of-stake design space and allow for a lot of technical simplification, make it more secure by allowing Helios to SNARK directly on the Ethereum consensus, and make even uninteresting but long-standing signature schemes like Winternitz It is feasible to solve the problem of quantum resistance.
Why not just use committee?
Many non-Ethereum blockchains that face 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 finalizing the slot. It’s worth reminding why this approach is insufficient because it does not provide accountability.
To understand why, assume a 51% attack occurs. This could be a final state reversal attack or a censorship attack. In order to conduct an attack, you still need economic actors to control a majority of the shares to agree in the attack, i.e. to run the software that participates in the attack, and to participate in the attack along with all the validators who are ultimately selected to serve on the committee. Mathematical random sampling ensures this. However, they were minimally punished for this because most validators who agreed to the attack were not ultimately elected to the committee and therefore were not seen.
Currently, Ethereum is doing exactly the opposite. If a 51% attack occurs, a majority of the entire attack validator set will have their deposits slashed. The current cost of the attack is approximately 9 million ETH (approximately $20 billion) and assumes that network synchronization disruption occurs in a manner that is most beneficial to the attacker.
I think its a high cost, but its so high that we can make some sacrifices on this issue. Even if the attack cost is 1-2 million ETH, it is completely sufficient. Furthermore, the main centralization risk currently present in Ethereum manifests itself in a completely different place: if the minimum deposit amount is reduced to close to zero, the power of large-scale staking pools will not be reduced much.
This is why I advocate a middle-of-the-road solution: make some sacrifices in validator responsibility, but still keep the total amount of slashable ETH high, and in exchange we get most of the benefits of a smaller validator set.
What will happen with 8192 signatures per slot under SSF?
Assuming a traditional two-round consensus protocol (like the one used by Tendermint, and inevitably used by SSF), each participating validator requires two signatures per slot. We need to address this reality, and I see three main ways to address this.
Method 1: Fully adopt a decentralized pledge pool
The Zen of Python contains a very crucial sentence:
There should be one-- and preferably only one --obvious way to do it.
Regarding the issue of making staking equal, Ethereum currently violates this rule because we are simultaneously executing two different strategies to achieve this goal: (i) small-scale independent staking, and (ii) using distributed verification A decentralized staking pool based on Virtual Machine Technology (DVT). For the above reasons, (i) only a few individual stakers can be supported; there will always be many people whose minimum deposit amount is too high. However, Ethereum is paying a very high technical burden cost to support (i).
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 a total validator limit of 4096 (approximately 16.7 million ETH). Small stakers are expected to join the DVT pool: by providing capital or becoming node operators. To prevent abuse by attackers, the node operator role needs to be limited by a reputation threshold in some way, and individual pools will compete by offering different options in this regard. Capital provision will be license-free.
We can make staking in this model more forgiving by setting a penalty cap (e.g., 1/8 of the total deposit). This would allow for less trust in node operators, although it is worth treating with caution due to the issues outlined.
Method 2: Two-layer pledge
We create two tiers of stakers: a heavy tier, which requires 4096 ETH to participate in final state confirmation, and a light tier, which has no minimum requirements (and no deposit and withdrawal delays, and no slashing loopholes), adding a second tier safety. In order for a blocks final state to be confirmed, both the heavy layers final state confirmation and at least 50% of the online light validators in the light layer are required to prove it.
This heterogeneity is beneficial for censorship and attack resistance, as both heavy and light layers need to be corrupted for an attack to be successful. If one layer is corrupted and another is not, the chain will stop; if a higher layer is corrupted, it can be punished.
Another benefit of this is that the light layer can contain ETH that is also used as in-app collateral. The main disadvantage is that it makes staking less equal by establishing a divide between small-scale stakers and large-scale stakers.
Method 3: Rotating participation (i.e. committee but with accountability)
We take an approach similar to the super committee design proposed here: for each slot we select the 4096 currently active validators and carefully adjust this set in each slot so that we still have security .
However, we made some different parameter choices within this framework to get value for money within it. In particular, we allow validators to participate with arbitrarily high balances, and if a validators amount of ETH exceeds a certain amount M (which will have to be floating), they participate in the committee in each slot. If the verifier has N
Here we have an interesting lever that decouples weight for incentive purposes from weight for consensus purposes: the reward for every 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 weight in the committee by ETH weighting. This ensures that the amount of ETH required to break finality is equal to more than 1/3x the total ETH in the committee.
A rough Zipfs law analysis would calculate 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.
Therefore, the committee will have an equal amount of ETH participating from each balance level, except for levels above barrier M, where validators are always on the committee.
Note: In order to display the calculated data more clearly, the next steps will be shown with screenshots.
The main disadvantage of this approach is the slightly increased complexity of randomly selecting validators in the protocol so that we can achieve consensus security in the event of committee changes.
The main advantage is that it preserves independent staking in a recognizable form, maintains a single category system, and even allows the minimum deposit amount to be reduced to very low levels (e.g. 1 ETH).
in conclusion
If we determine that we will stick to 8192 signatures behind the SSF protocol, it will make the lives of technical implementers and builders of side infrastructure such as light clients much easier. It will be easier for anyone to run a consensus client, and users, staking enthusiasts, etc. can immediately work from this assumption. The future load of the Ethereum protocol is no longer unknown: it can be improved via hard forks in the future, but only if developers are convinced that the technology has improved enough to be able to handle more signatures per slot with the same level of ease.
The rest of the work will be to decide which of the above three approaches we want to take, or perhaps a completely different approach. Its going to be a question of what trade-offs were comfortable with, especially how we deal with related issues like liquid staking, which can probably be solved separately from the technical issues that are now becoming easier.
