Vitalik's PoS Simplification Proposal: Stick to 8,192 Signatures per Slot After SSF
TechFlow Selected TechFlow Selected
Vitalik's PoS Simplification Proposal: Stick to 8,192 Signatures per Slot After SSF
This will make it easier for technology implementers and builders of auxiliary infrastructure such as light clients.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin, ethresearch
Translation: Songxue, Jinse Finance
The main difference between Ethereum and most other (finality-oriented) proof-of-stake systems is that Ethereum aims to support a very large number of validator objects: we currently have 895,000 validator objects, and simple Zipf's law analysis suggests this corresponds to tens of thousands of validators being unique individuals or entities. The goal is to support decentralization and allow ordinary individuals to participate in staking without requiring everyone to give up their agency and hand control over to one of a few staking pools.
However, this approach requires the Ethereum chain to process a large number of signatures per slot (around 28,000 today; 1,790,000 after SSF), which represents a very high load. Supporting this load necessitates numerous technical compromises:
-
It requires a complex attestation propagation mechanism involving splitting attestations across multiple subnets, ultra-optimizing BLS signature operations for verifying these signatures, and more.
-
We do not have a clear, sufficiently efficient post-quantum alternative.
-
Fork choice fixes like view-merge become more complicated because individual signatures cannot be extracted.
-
SNARKing over signatures is difficult due to their large quantity. Helios needs to operate on an additional dedicated signature called the sync committee signature.
-
It increases the security minimum slot time by requiring three sub-slots instead of two within each slot.
Signature aggregation systems may seem reasonable at first glance, but in practice they create systemic complexity that permeates every aspect.
Moreover, it doesn't even achieve its intended purpose. The minimum staking requirement remains 32 ETH, which is unattainable for many people. Logically analyzing further, a system where everyone signs in seems fundamentally infeasible in the long run: if Ethereum has 500 million users and 10% stake, this would mean 100 million signatures per slot. From an information-theoretic standpoint, processing slashing in such a design would require at least 12.5 MB of data availability per slot—roughly as much as full danksharding targets (!!!). It might be feasible, but requiring staking itself to depend on data availability sampling introduces significant added complexity—even though this only involves about 0.6% of the world’s population staking—and we haven’t even begun addressing the computational challenges of verifying so many signatures.
Therefore, rather than relying on cryptographers inventing magic bullets (or magic bulletproof vests) to make ever-increasing numbers of signatures per slot possible, I suggest a philosophical shift: abandoning such expectations from the start. This would greatly expand the PoS design space and allow substantial technical simplifications—enabling Helios to directly SNARK over Ethereum consensus for improved security, and solving quantum resistance by making even old, boring signature schemes like Winternitz viable.
Why not just use committees?
Many non-Ethereum blockchains facing this exact problem use a committee-based security model. In each slot, they randomly select N validators (e.g., N ≈ 1000) responsible for finalizing that slot. It's worth recalling why this method isn't sufficient: it lacks accountability.
To understand why, suppose a 51% attack occurs—either a finality reversion or censorship attack. Launching such an attack still requires a majority of economically staked participants to agree to attack, i.e., run software participating in the attack and coordinate with all validators eventually selected into the committee. Random sampling math ensures this. However, those agreeing to the attack face minimal penalties because most who consent never get selected into the committee and thus remain unseen.
Currently, Ethereum takes the opposite extreme. If a 51% attack happens, the vast majority of the attacking validator set gets slashed. The current cost of such an attack is approximately 9 million ETH (about $20 billion), assuming network synchrony breaks in ways maximally favorable to attackers.
I believe this is an excessively high cost, and we can afford to make some trade-offs here. Even an attack cost of 1–2 million ETH would be entirely sufficient. Moreover, the primary centralization risks in Ethereum today lie elsewhere: if the minimum staking amount were lowered close to zero, the power disparity among large staking pools wouldn't be significantly reduced.
This is why I advocate a moderate solution: making some sacrifices in validator accountability while still keeping the total slashable ETH quite high. In exchange, we gain most of the benefits of a smaller validator set.
What would 8192 signatures per slot look like under SSF?
Assuming a traditional two-round consensus protocol (similar to what Tendermint uses, and inevitably what SSF will use), each participating validator requires two signatures per slot. We need to work around this reality. I see three main approaches to achieving this.
Approach One: Fully commit to decentralized staking pools
Python has a key principle:
There should be one—and preferably only one—obvious way to do it.
Ethereum currently violates this rule regarding staking equalization because we simultaneously pursue two different strategies: (i) small-scale solo staking, and (ii) decentralized staking pools using Distributed Validator Technology (DVT). For the reasons above, (i) can only support a subset of individual stakers; there will always be many people for whom the minimum deposit is too high. Yet Ethereum pays a very high technical overhead cost to support (i).
A possible solution is to abandon (i) and fully embrace (ii). We could raise the minimum staking amount to 4096 ETH and cap the total number of validators at 4096 (approximately 16.7 million ETH). Small stakers would join DVT pools either by contributing funds or becoming node operators. To prevent abuse, the node operator role would need to be reputation-limited in some way, and pools would compete by offering different models along this dimension. Fund contribution would remain permissionless.
We could make pooled staking more "forgiving" in this model by capping penalties—for example, at 1/8 of the total staked amount. This would reduce trust assumptions on node operators, though care must be taken given the issues outlined here.
Approach Two: Two-tier staking
We create two tiers of stakers: a "heavy" tier requiring 4096 ETH to participate in finalization, and a "light" tier with no minimum staking requirement (and also no deposit/withdrawal delays or slashing risk), adding another layer of security. For a block to be finalized, it must be finalized by the heavy tier and attested by >50% of online light validators.
This heterogeneity benefits censorship resistance and attack resilience because a successful attack would require corrupting both tiers. If one tier is corrupted and the other isn’t, the chain halts; if the heavy tier is corrupted, it can be penalized.
Another advantage is that the light tier could include ETH serving as collateral within applications. The main drawback is that it creates a distinction between small and large stakers, making staking less egalitarian.
Approach Three: Rotating participation (i.e., committees but accountable)
We adopt an approach similar to the super-committee design proposed here: for each slot, we select 4096 currently active validators, carefully adjusting this set during each slot to maintain safety.
However, we make different parameter choices to extract the “maximum benefit” within this framework. Specifically, we allow validators to participate with arbitrarily high balances. If a validator holds more than a certain threshold M of ETH (which must be dynamic), they participate in the committee every period. If a validator holds N < M ETH, they have an N/M probability of entering the committee in any given period.
Here we have an interesting lever: decoupling “weight” for incentive purposes from “weight” for consensus purposes. Rewards inside the committee should be equal for each validator (at least for those with ≤M ETH) to keep average rewards proportional. Yet we can still count validators in the committee with ETH-weighted voting for consensus. This ensures breaking finality requires controlling more than one-third of the total ETH in the committee.
Zipf's law analysis calculates ETH distribution as follows:
At each quadratic level of total balance, the number of validators is inversely proportional to that balance level, and the total ETH held by validators at each level remains constant.
Thus, the committee will have equal amounts of ETH from each balance tier, except for tiers above barrier M (where validators are always in the committee).
Hence, we have Log2(M)+2 levels below the top K validators, and K + K/2 + … = 2K validators above those levels. Therefore, K = 4096 / (Log2(M) + 2).
The largest validator will hold M×k ETH. We can reverse-calculate: if the largest validator holds 2^18 = 262,144 ETH, this implies (approximately) M = 1024 and k = 256.
Total staked ETH would be:
Full stakes of the top 512 validators (2^18×1 + 2^17×2 + … + 2^10×2^8 = 2,359,296)
Plus randomly sampled smaller stakes (2^8 × (2^9 + 2^8 + 2^7 + …) ≈ 2^8 × 2^10 = 2^18)
Totaling 2,621,440 ETH, or an attack cost of approximately 900,000 ETH.
The main drawback of this approach is introducing additional complexity into the protocol to randomly select validators in a way that maintains consensus security even when the committee changes.
Its main advantages are preserving a recognizable form of independent staking, maintaining a single system, and even allowing the minimum staking amount to drop to very low levels (e.g., 1 ETH).
Conclusion
If we decide that after the SSF protocol, we want to stick with 8192 signatures per slot, this would make life easier for technical implementers and builders of auxiliary infrastructure like light clients. Running a consensus client becomes easier for anyone, and users, staking enthusiasts, and others can immediately build on this assumption. The future load of the Ethereum protocol would no longer be unknown: it could increase via hard fork in the future, but only when developers are confident that technology has advanced enough to handle more signatures per slot with equal ease.
The remaining work will be deciding which of the above three approaches—or perhaps a completely different one—we want to take. This will come down to questions about which trade-offs we are comfortable with, especially how we address related issues like liquid staking, which may now be separable from the technically easier problems.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
