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 suggests that in the blockchain consensus mechanism, a single time slot or unit of time 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's "return" to ETH research discusses the need for validators to have two signatures per slot after SSF, reaching a total of 8192 signatures, and proposes 3 hypotheses on how to achieve this goal: comprehensive staking, two-tier staking, and rotational participation. It analyzes how to more effectively handle the number of signatures per slot while maintaining protocol security, 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 (with finality) proof-of-stake systems is that Ethereum strives to support a large number of validators: currently, we have 895,000 validators, and Zipf's law analysis indicates that this is equivalent to tens of thousands of independent individuals or entities. The purpose of 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 a few staking pools.
However, this approach requires the Ethereum chain to process a large number of signatures at each slot (about 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 split across multiple subnets, requiring highly optimized BLS signature operations to verify these signatures, and so on.
- We currently do not have a clear, efficient quantum-resistant alternative.
- Fork choice repairs like view merging become more complex because individual signatures cannot be extracted.
- It is very difficult to process SNARKs for so many signatures. Helios needs to run on a dedicated additional signature called the synchronous committee signature.
- It requires three subslots in a slot instead of two, increasing the minimum slot time for security.
At first glance, a signature aggregation system seems reasonable, but in reality, it introduces systemic complexity throughout the entire system.
Furthermore, it does not even achieve its goal. The minimum staking requirement is still 32 ETH, which is unattainable for many. From a logical analysis perspective, a system that requires everyone to sign at every slot in the long term seems infeasible for ordinary people: if Ethereum has 500 million users, with 10% participating in staking, that means there are 100 million signatures per slot. From an information theory perspective, handling penalties in this design requires at least 12.5 MB of data availability 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. And even then, only about 0.6% of the global population participates in staking, and the computational problem of verifying so many signatures has not even begun to be addressed.
Therefore, instead of relying on cryptographers to create magic bullets (or magic bulletproof vests) to continually increase the number of signatures per slot, I suggest a philosophical shift: first, give up on such expectations. This will greatly expand the design space for proof of stake and allow for significant technical simplifications, by allowing Helios to directly run SNARKs on Ethereum consensus, making it more secure, and by making even boring but long-standing signature schemes like Winternitz feasible to address quantum resistance issues.
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, because it does not provide accountability.
To understand the reason, suppose a 51% attack occurs. This could be a finality reversal attack or a censorship attack. To carry out the attack, you still need economic participants controlling the majority of the stake to achieve consensus in the attack, i.e., running software participating in the attack and participating in the attack with all validators eventually selected for the committee. Mathematical random sampling ensures this. However, the punishment they receive for this is minimal, as most validators who agree to the attack are not ultimately selected as committee members and therefore go unnoticed.
Currently, Ethereum's approach is completely the opposite. If a 51% attack occurs, most of the attacking validators will have their deposits slashed. The current cost of an attack is about 9 million ETH (about 20 billion USD), assuming network disruption occurs in a way most favorable to the attacker.
I think this is a high cost, but the cost is too high, and we can make some sacrifices on this issue. Even if the cost of an attack is 1-2 million ETH, it is completely sufficient. Furthermore, the main centralization risk that Ethereum currently faces is in a completely different place: if the minimum deposit amount is lowered to near zero, the power of large staking pools will not be significantly weakened.
This is why I advocate for a moderate solution: making some sacrifices on validator responsibility, but still maintaining a very high total slashable ETH amount. In exchange, we can enjoy most of the benefits of a smaller set of validators.
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 needs two signatures per slot. I see three main ways to address this issue.
Method 1: Fully adopt decentralized staking pools
The Zen of Python contains a very crucial line:
There should be one-- and preferably only one --obvious way to do it.
For the issue of making staking equal, Ethereum currently violates this rule, as we are simultaneously pursuing two different strategies to achieve this goal: (i) small-scale independent staking, and (ii) decentralized staking pools using Distributed Validator Technology (DVT). For the reasons mentioned above, (i) can only support some individual stakers; there will always be many people whose minimum deposit amount is too large. However, Ethereum is paying a very high technical cost to support (i).
One possible solution is to abandon (i) and go all-in on (ii). We can raise the minimum deposit amount to 4096 ETH and set the total validator limit to 4096 (about 16.7 million ETH). It is expected that small-scale stakers will join DVT pools: by providing capital or becoming node operators. To prevent abuse by attackers, the role of node operators needs to be restricted in some way by a reputation threshold, and different pools will compete by offering different options in this regard. Capital provision will be permissionless.
We can make staking more "tolerant" in this model by setting a penalty cap (e.g., 1/8 of the total provided deposit). This will allow for reduced trust in node operators, although caution is warranted due to the outlined issues.
Method 2: Two-tier staking
We create two tiers of validators: a "heavy" tier, requiring 4096 ETH for finality confirmation, and a "light" tier with no minimum requirement (also no deposit and withdrawal delay, no slashing vulnerability), adding a second layer of security. To finalize a block, both heavy tier finality confirmation and at least 50% of online light validators' proofs are required.
This heterogeneity is beneficial for censorship and attack resistance, as a successful attack requires corrupting both the heavy and light tiers simultaneously. If one tier is corrupted and the other is not, the chain will stop; if the heavy tier is corrupted, it can be penalized.
Another benefit of this approach is that the light tier can include ETH used as in-app staking. The main drawback is making staking less equal by establishing a divide between small-scale and large-scale stakers.
Method 3: Rotational Participation (i.e., committees with accountability)
We take an approach similar to the supercommittee design proposed here: for each slot, we select 4096 currently active validators and carefully adjust this set for each slot to maintain security.
However, we make some different parameter choices within this framework to get "bang for the buck." In particular, we allow validators to participate with any high balance, and if a validator's ETH amount exceeds a certain amount M (which will have to be floating), they participate in the committee at each slot. If a validator has NM ETH, they have a probability of N/M to participate in the committee in any given slot.
Here we have an interesting lever, decoupling "weight" for incentive purposes from "weight" for consensus purposes: the reward for each validator in the committee should be the same (at least for validators using ≤M ETH) to maintain proportional average rewards to balances, but we can still calculate the consensus validator weight in the committee using ETH weighting. This ensures that the amount of ETH required to break finality is more than one-third of the total ETH in the committee.
A rough Zipf's law analysis would calculate this ETH amount 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 participation from each balance level, except for levels exceeding the barrier M, where validators are always in the committee.
Note: To display the calculation data more clearly, the following steps will be shown in a screenshot.
The main drawback of this approach is a slight increase in the complexity of randomly selecting validators in the protocol to achieve consensus security in the event of committee changes.
The main advantage is that it preserves independent staking in a recognizable form, maintaining a single-class system, and even allows the minimum deposit amount to be lowered to a very low level (e.g., 1 ETH).
Conclusion
If we decide to stick to using 8192 signatures after the SSF protocol, it will make the work of technical implementers and builders of infrastructure such as light clients much easier. Anyone can run a consensus client more easily, and users, staking enthusiasts, and others can immediately work based on this assumption. The future load of the Ethereum protocol is no longer unknown: it can be increased through a hard fork in the future, but only when developers are confident that the technology has improved enough to handle more signatures per slot at the same ease.
The remaining work will be to decide which of the three methods mentioned above to adopt, or possibly a completely different method. This will be a question of which trade-offs we are comfortable with, especially how we handle issues such as liquid staking, which may be separate from the technical issues that are now becoming easier to solve.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
