← head back


Single Slot Finality


A few weeks ago, I've read Vitalik's post on Single Slot Finality (SSF) and left both excited and a little disheartened. Solving fast finality with as many validators as Ethereum has is very interesting but at the same time it might be compromising either the security of the network or the 32ETH deposit and hence decentralization that already felt high to me.

I kept thinking about it since and came up with the following "scheme" that aims to give a third solution to the problem of effectively capping validator count for faster finality.

Might be worth mentioning that I haven't worked with the Ethereum consensus layer before and my experience spans with other parts of the protocol.

Single Slot Finality

Single Slot Finality aims to solve a few issues the current consensus of Ethereum has such as slow finality for transactions (~15m), re-org incentives for MEV bots and other malicious actors and protocol complexity / interaction bugs between LMD-Ghost and Gasper FFG.

It does that by making Ethereum consensus closer to BFT and utilizing the ability to finalize the chain in a single slot if there are enough attestations. This new consensus could still support more validators than other BFT-like systems using efficiency of BLS signatures and won't halt if >33% are offline but would enter an inactivity leak state similar to the current consensus of Ethereum.

There's one catch, the new consensus would still require reducing the validator count from hundred of thousands to tens of thousands to efficiently operate. within the bounds of one slot.

The HackMD post discusses two ideas to get there.

Ideas from the HackMD post

Idea 1: Super-committees

Randomly select a super-committee of tens of thousands of participants for each slot.

Instead of all validators participating in each Casper FFG round, only a medium-sized super-committee of a few tens of thousands participates, allowing each round of consensus to happen within a single slot.

Super-committees allow us to not put further economic restrictions for validators but their drawback is that they reduce the total amount of ETH required to attack Ethereum as each committee has a fixed number of validators.

For example, 62.5K validators per super-committee means 1M ETH at stake and 2M ETH security as 62.5 * 32 ETH = 2M ETH which is much lower that the current economic security of Ethereum ie. ~900K * 32 ETH = 28.8M ETH.

Idea 2: Validator set size capping

Cap the total ETH deposited or the validator count.

We could try to adopt either (or both) of two kinds of caps:

  1. Capping the total ETH deposited
  2. Capping the total validator count

Either cap could be implemented either with an order-based mechanism (stack or queue) or with economic mechanisms.

Validator set size capping allows to not reduce the amount of ETH required to attack Ethereum but require either increasing the required amount for staking or alter the permission-less of Ethereum. Increasing the stake could also cause griefing attacks where big validators split their stake to push smaller validators out.

Blending the two ideas

The proposal is to have a one committee for each discrete amount of ETH deposit. Committees will have different chances to be selected to produce the next block based on the amount of ETH deposit (eg. the 64 ETH committee will have double the chances of the 32 ETH committee). Each committee should randomly select validators that the total number of validators for all committees is fixed (eg. 10 committees with 8K validators each).


Allow staking with a discrete deposits D1,...,DnD_1,...,D_n, where Di=2iD_i = 2^i for i=m,..,ni=m,..,n. For example, if m=1m=1 and n=10n=10 the deposit values will be 2,4,...128, 512 and 1024 ETH.

Each deposit committee will have a fixed number of validators Kcommittee=KK_{committee}=K. Since there are nn committees, the total number of validators will be Ktotal=(nm+1)Kcommittee=(nm+1)KK_{total}=(n-m+1)*K_{committee} = (n-m+1)*K. If there are more validators in any deposit committee the participating validators will be randomly selected.

In each slot, every committee votes and when the aggregated votes are weighted based on their deposit value ie. Vweighted_votes=Vcommittee_votesDiV_{weighted\_votes}= V_{committee\_votes}*D_i. Vote aggregation can still utilize BLS signatures for efficient. There's just nm+1n-m+1 extra multiplications at the end of each slot to calculate aggregate vote across the all committees.

Given that validators now have uneven deposit values, there should be an adjustment to the block production selection to account for the lower and higher validator deposits. The probability each committee produces a new block is the adjusted by the committee deposit and the total deposits of all committees. Each committee has a chance of Pcommittee P_{committee} to produce a new block and each individual validator has a chance of PvalidatorP_{validator} .

The PcommitteeP_{committee} and PvalidatorP_{validator} are given by:

    Pcommittee=DiStotal=2ii=mn2i=2i2n+12m+1P_{committee} = \dfrac{D_{i}}{S_{total}} = \dfrac{2^{i}}{\sum_{i=m}^{n} 2^i} = \dfrac{2^i}{2^{n+1} - 2^{m+1}}

    Pvalidator=PcommitteeKcommitteePcommitteeKP_{validator} = \dfrac{P_{committee}}{K_{committee}} ≈ \dfrac{P_{committee}}{K}


    ii is the index of the committee and m<i<nm<i<n

    StotalS_{total} is the total deposit given by i=mn2i=2n+12m+1\sum_{i=m}^{n} 2^i = 2^{n+1} - 2^{m+1}

    KcommitteeK_{committee} is the committee validator count and should approach KK

The total amount of ETH TstakeT_{stake} deposited in all committees is i=mn2iK=K(2n+12m+1)\sum_{i=m}^{n} 2^i * K = K * (2^{n+1} - 2^{m+1}) ETH.

Picking the parameters

Deciding the maximum index nn for fixed m=1m = 1 and K=8kK=8k:

n=8n=8     \implies Tstake=4.06MT_{stake}=4.06M ETH, Pmin=0.19%P_{min}=0.19\% and Pmax=50.2%P_{max}=50.2\%

n=10n=10     \implies Tstake=16.3MT_{stake}=16.3M ETH, Pmin=0.05%P_{min}=0.05\% and Pmax=50.0%P_{max}=50.0\%

n=12n=12     \implies Tstake=65.5MT_{stake}=65.5M ETH, Pmin=0.01%P_{min}=0.01\% and Pmax=50.0%P_{max}=50.0\%

Deciding the minimum index mm for fixed n=12n = 12 and K=8kK=8k

m=1m=1     \implies Tstake=65.5MT_{stake}=65.5M ETH, Pmin=0.01%P_{min}=0.01\% and Pmax=50.0%P_{max}=50.0\%

m=3m=3     \implies Tstake=65.4MT_{stake}=65.4M ETH, Pmin=0.08%P_{min}=0.08\% and Pmax=50.1%P_{max}=50.1\%

m=5m=5     \implies Tstake=65.0MT_{stake}=65.0M ETH, Pmin=0.38%P_{min}=0.38\% and Pmax=50.4%P_{max}=50.4\%

Deciding committee validator count KK for fixed m=1m = 1 and n=12n=12

K=6kK=6k     \implies Tstake=49.1MT_{stake}=49.1M ETH, Pmin=0.01%P_{min}=0.01\% and Pmax=50.0%P_{max}=50.0\%

K=8kK=8k     \implies Tstake=65.5MT_{stake}=65.5M ETH, Pmin=0.01%P_{min}=0.01\% and Pmax=50.0%P_{max}=50.0\%

K=12kK=12k     \implies Tstake=98.2MT_{stake}=98.2M ETH, Pmin=0.01%P_{min}=0.01\% and Pmax=50.0%P_{max}=50.0\%

Note: PminP_{min} and PmaxP_{max} are the probabilities the smallest and largest committees produces a block respectively.

Source code for calculation:

1const m = 1, n = 12, k = 8_000 2 3const Tstake = k * (2**(n+1) - 2**(m+1)) 4const Pmin = (2**m - 1) / (2**(n+1) - 2**(m+1)) 5const Pmax = (2**n - 1) / (2**(n+1) - 2**(m+1)) 6console.log(Tstake, Pmin, Pmax) 7

A numerical example

Let's take m=1m=1, n=12n=12 and K=8kK=8k as an example. To simplify the maths I'll only consider a perfectly balanced system where each stake value is filled with the exact number of validators it's cap is but that definitely won't be the case in practice.

In this example, there would be 8k validators at 1 ETH, 8k validators at 2 ETH and so on until 4096 ETH. The total number of validators is K=8k12=96kK=8k*12= 96k.

As mentioned before, to calculate the block production chances for each committee we need to calculate the adjusted probability each committee has based on their stake. So the sum of 1+2+...+4096=81911 + 2 + ... + 4096 = 8191 . That means that the 1 ETH committee has a probability of 181910.012%\dfrac{1}{8191} \approx 0.012\% to produce a block and the 4096 ETH committee has a probability of 4096819150.0%\dfrac{4096}{8191} \approx 50.0\% .

To get the probability of a single validator in the committee producing a block we just have to divide that committee probability with the committee validator count ie. 8k8k. This means 1 ETH validators has a chance of 0.012%8k0.0000015%\dfrac{0.012\%}{8k} \approx 0.0000015\% of producing a block that turns out to be years and 4096 ETH validators has a chance of 50%8k0.00625%\dfrac{50\%}{8k} \approx 0.00625\% which is a few days.

In this configuration the total amount of ETH stake is 8k(1+2+...+4096)=8k(8191)=65.5M8k*(1 + 2 + ... + 4096) = 8k*(8191) = 65.5M ETH.

Open Questions

  1. Picking the correct implementation parameters ie. the validator count cap per committee KK and the range of discrete deposit values mm and nn?
  2. Investigating the dynamics when smaller deposit values get filled out? Are griefing attacks still meaningful and should be protected against?


[1] https://notes.ethereum.org/@vbuterin/single_slot_finality

[2] https://eth2book.info/capella/part2/building_blocks/committees/

[3] https://github.com/ethereum/consensus-specs

Related Posts

Andreas Tzionis @