This will make the lives of technology implementers easier, as well as builders of supporting infrastructure such as light clients.
Written by: Vitalik Buterin, ethresearch
Compiled by: Songxue, Golden Finance
The main difference between Ethereum and most other (finality) proof-of-stake systems is that Ethereum attempts to support a very large number of validator objects: we currently have 895,000 validator objects, and simple Zipf’s law analysis shows that this corresponds to Tens of thousands of validator objects are unique individuals/entities. The purpose of this is to support decentralization and even allow ordinary individuals to participate in staking without requiring each person to give up their agency and give control to one of a handful of 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. Supporting this load requires significant technical sacrifices:
- This requires a complex proof propagation mechanism involving splitting the proof across multiple subnets, requiring hyper-optimization of BLS signature operations to verify these signatures, etc.
- We do not have a clear alternative that is sufficiently efficient to be quantum resistant.
- Fork-select fixes like view merging become more complex because individual signatures cannot be extracted.
- SNARKing signatures is difficult because of their large number. Helios needs to operate on a dedicated additional signature, called a synchronization committee signature.
- It increases the safe minimum time slot by requiring three subtime slots in a time slot instead of two.
The signature aggregation system may seem reasonable at first glance, but in fact it creates systemic complexity that permeates every aspect.
What’s more, it doesn’t even serve its purpose. The minimum requirement for staking is still 32 ETH, which is out of reach for many. Just from a logical analysis, in the long run, it seems unfeasible for a system where everyone signs in to truly provide staking for ordinary people: If Ethereum has 500 million users, and 10% of them pledge, then this means There are 100 million signatures per slot. In information theory terms, the processing cuts in this design require at least 12.5 MB of data free space per slot, roughly as much as the goal of full daksharding (!!!). Perhaps doable, but requiring the staking itself to rely on data availability sampling would come with a large complexity gain - even if that’s only about 0.6% of the world’s population staking, and that doesn’t even begin to get into the computational problems of verifying so many signatures.
So instead of relying on cryptographers to create a magic bullet (or magic body armor) that makes it possible to have an ever-increasing number of signatures in each time slot, I suggest we make a philosophical shift: give up on such expectations in the first place . This would greatly expand the PoS design space and allow for a lot of technical simplification, making it more secure by allowing Helios to SNARK directly on the Ethereum consensus, and by making even boring long-standing signature schemes like Winternitz It can also be feasible to solve the problem of quantum resistance.
Why not “just use committee”?
Many non-Ethereum blockchains that face this exact problem use a committee-based approach to security. In each time slot, they randomly select N validators (for example, N is approximately equal to 1000), and these validators are responsible for completing that time slot. It’s worth reminding why this approach falls short: it lacks accountability.
To understand why, imagine a 51% attack. This could be a final reversal attack or a censorship attack. To launch an attack, the economic actor who controls the majority of the stake still needs to agree to carry out the attack, i.e. run the software that participates in the attack, along with all validators who are ultimately elected to the committee. The mathematics of random sampling guarantee this. However, the penalty they bear for such an attack is small because most validators who agree to the attack end up not being seen because they were not elected to the committee.
Currently, Ethereum takes the opposite extreme. In the event of a 51% attack, a majority of the entire attacking validator set will have their stake slashed. The current cost of the attack is approximately 9 million ETH (approximately $20 billion), and this assumes that network synchronization is disrupted in a manner that maximizes the attacker’s benefit.
I think it’s a high cost, and it’s a cost that’s 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. Furthermore, the main centralization risk that currently exists for Ethereum lies in a completely different place: if the minimum staking amount is reduced to close to zero, the difference in strength of large-scale staking pools will not be much.
That’s why I advocate a modest solution: make some sacrifices in validator accountability, but still keep the total amount of slashable ETH fairly high, and in exchange it gives us a smaller validator set most of the benefits.
What would 8192 signatures per time slot look like under SSF?
Assuming a traditional two-round consensus protocol (similar to the one used by Tendermint, and inevitably used by SSF), each participating validator requires two signatures per time slot. We need to get around this reality. I see three main ways we can do this.
Method 1: Go all-in on the decentralized pledge pool
Python has a very crucial saying:
There should be one - preferably only one - obvious way to do this.
Regarding the issue of staking equalization, Ethereum currently violates this rule because we simultaneously implement two different strategies to achieve this goal: (i) small-scale individual staking, and (ii) using distributed validator technology ( DVT) decentralized staking pool. Due to the above reasons, (i) only a subset of individual stakers can be supported; there will always be many people whose minimum deposit is too large. 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 stake amount to 4096 ETH and set a total cap of 4096 validators (approximately 16.7 million ETH). Small stakers are expected to join the DVT pool: either by providing funds or becoming node operators. To prevent abuse by attackers, the node operator role needs to be limited by reputation in some way, and pools will compete with each other by offering different options in this regard. Funding will be permissionless.
We can make collective staking in this model more “forgiving” by limiting penalties, for example. to 1/8 of the total pledge provided. This will reduce trust in node operators, although it is worth approaching with caution due to the issues outlined here.
Method 2: Two-level pledge
We create two tiers of stakers: a “heavy” tier, requiring 4096 ETH, to participate in finalization, and a “light” tier, which has no minimum staking requirements (also no deposit and withdrawal delays, and no risk of slashing), which Adds another layer of security. For a block to be final, both the heavy layer needs to finalize it and the light layer needs >= 50% of online light validators to attest to it.
This heterogeneity is beneficial for censorship resistance and attack resistance, as both the 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 heavy layer is corrupted, it can be punished.
Another benefit of this approach is that the lightweight layer can include 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 and large stakers.
Method 3: Take turns participating (i.e. committee but responsible)
The approach we take is similar to the super committee design proposed here: for each time slot, we select 4096 currently active validators, and we carefully adjust this set during each time slot to ensure that we remain secure.
However, we made some different parameter choices in order to get the “maximum benefit” within this framework. In particular, we allow validators to participate with arbitrarily high balances, and if a validator owns more than a certain amount M of ETH (which must be floating), then they participate in the committee every epoch. If the verifier has N <M ETH，那么他们有 N/M 在任何给定时间段内进入委员会的概率。
An interesting lever we have here is to decouple the “weight” for incentive purposes from the “weight” for consensus purposes: the reward for every validator within the committee should be the same (at least for validators with ≤M ETH) , to keep the average reward proportional. We can still perform a consensus count of the validators in the committee using ETH as the weight. This ensures that breaking finality requires an amount of ETH equal to greater than one-third of the total amount of ETH in the committee.
Zipf’s law analysis will calculate the 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 every balance level except levels above barrier M (validators are always on the committee).
Therefore, we have Log2(M) level for every K validators at the above level, and K+K/2+…=2K above level validators. Therefore, K=4096/Log2(M)+2.
The largest validator will have M*k ETH. We can work backwards: if the largest validator has 2^18=262144 ETH, this means (roughly) M = 1024 and k = 256.
The total amount of pledged ETH is:
All rights and interests of the top 512 validators (2^18*1+2^17*2+……+2^10*2^8=2359296)
Plus smaller bets from random sampling (2^8*(2^9+2^8+2^7…) is approximately equal to 2^8*2^10=2^18)
We gained a total of 2621440 ETH, or the cost of the attack was approximately 900k ETH.
The main disadvantage of this approach is that it introduces some more complexity within the protocol to randomly select validators in a way that allows us to still achieve consensus security when the committee changes.
Its main advantage is that it retains a recognizable form of independent staking, retains a single system, and even allows the minimum stake amount to be reduced to very low levels (e.g. 1 ETH).
Summarize
If we determine that behind the SSF protocol, we want to stick with 8192 signatures, which will make the lives of technical implementers easier, as well as builders of supporting infrastructure such as light clients. It becomes easier for anyone to run a consensus client, and users, staking enthusiasts, and others can immediately work on this assumption. The future load of the Ethereum protocol is no longer unknown: it could be improved in the future via hard forks, but only if developers are convinced that the technology has improved enough to be able to handle more signatures per time slot with the same ease.
The rest will be to decide which of the three approaches above we want to take, or perhaps a different approach entirely. It’s going to be a question about what trade-offs we’re comfortable with, especially how we solve the problems involved, like liquidity staking, which can probably be solved separately from the technical issues that are becoming easier now.
