Understand the Risk of Slot Battles and Ghosted Blocks

Staking & Delegation Operate a Stake Pool
1

Intro
While a pool is small it’s hard to understand how many blocks are typically lost to height battles (ghosted) and slot battles. Being Part of the xSPO Alliance (Link: https://www.xspo-alliance.org/) I want to share my idea of this in the hope new pool operators can get a better understanding of how Cardano works.

Disclaimer:
The included calculations are assumption-based. I do not have mathematical proof or 100% evidence that my calculations are correct. If you see any mistakes in the calculation or the idea behind it please let me know!

Pre-Knowledge
If you want to know what a ghosted block is, please take a look here: Ghosted Blocks - How to optimize Propagation Times - Action Required
Slot battles mean in simple words that multiple pools have the same slot assigned and only one can be kept, the other is lost.

Both scenarios are as per design and nothing to be afraid of. It’s just good to know how often this typically occurs.

Lost blocks influence the Network Density. Theoretically, it is 5% as on average every 20s a block is produced. Based on the lost blocks this theoretical average is not reached.

Numbers
Let’s get straight away to the numbers:
image

Details and explanations

  • The 5% Slot battle is not 100% mathematically correct. The underlying logic is that the chance that any pool got a slot assigned is 5%. Now, this is not exact because it ignores the fact that your own pools slots cannot be overlap and slightly reduce that risk.
  • It’s assumed that 50% of slot battles are won. In reality, this depends on the pool size. Lower Saturated pools tendentially win more battles.
  • Ghosted slots depend on Propagation times which are varying between pools based on their setup and network latency towards connected peers. If you did not receive a previously generated block before minting your own block your block will be discarded.
  • Also for ghosted the calculation is not 100% accurate as there are different factors influencing which block is in the end discarded. Anyways, the assumption is that every 1s Propagation Delay leads to a ~5% risk of one block being dropped. Increased propagation times heavily impact the risk of ghosted blocks. The given percentages for (% 1s, %2s, …) are based on typical stats which are reported by CNODE. It’s just an example
  • There is a chance of slots and height battles occurring at the same time. This is not considered in the calculation.

High-Level Validation
To validate the results on a high level I took a look at the Network Density.
Based on the calculations it should be around 4.72% with the current Propagation Times.
image

Details and explanations

  • The network Density is around the expected number of 4.72%
  • In Epoch 313 there was a drop in network density.
  • This drop is related to two reasons.
  • Release of Node 1.33.0 → In this version the rewards calculation time period was extended. Before it was 1 day which led to 1 day of 1-3s propagation times, the rest <1s. Now a bigger portion of blocks exceeds the 1s border.
  • Increased Network Usage: Based on e.g. SundaeSwap related Transactions. Bigger blocks means a longer time to Propagate.
6 Likes
2

Someone else will need to provide the actual mathematical formula because I don’t know it precisely. However, determining if your pool is a slot leader for a particular slot is based on 4 factors:

  • stake pool key
  • epoch nonce
  • slot number
  • total stake controlled by stake pool (relative to total stake delegated to all pools)

The formula results in 5% of slots having at least one pool being the slot leader. I am not sure how to calculate the average incidence of slot battles (where two or more pools are determined to be slot leaders for the same slot). I don’t think this figure is as high as 5% though.

My simplistic understanding is: A calculation (VRF) is done using the stake pool key, epoch nonce and slot number. If this VRF result is lower than the total stake controlled by the pool then it is a slot leader. So smaller pools, with less total stake, need to get a lower VRF result in order to be a slot leader. Thus smaller pools will be slot leaders for less slots.

Now, if two pool are slot leader for the same slot and they both produce valid blocks then the “winning” block, accepted by the network, is the one produced by the pool with the lower VRF value. So smaller pools will win this comparison more often, but not always, because they needed to get a lower VRF score in the first place just to be a slot leader.

Single block forks occur when two pools produce conflicting blocks exactly as you described above resulting from delays causing the second pool to produce a block with the same block number and many of the same transactions. Only one of these blocks can be accepted as valid. But, it is not necessarily the second block that is discarded. If both forks are only 1 block high the nodes determine the valid block based on the lower VRF score wins again. So smaller pools have an advantage here too.

See: Consensus should favor expected slot height to ward off delay attack · Issue #2913 · input-output-hk/ouroboros-network · GitHub

I am not sure of the mathematical formula for what percentage of blocks on average will result in these single block forks (ghosted blocks) for average transmission delays of 1s, 2s … 5seconds etc.

By the way, you can have blocks delayed by 30 seconds or more causing forks that are still resolved based on this VRF comparison. And, the pool that had the delayed block can, and often does, win based on this vRF comparison.

Sometimes it is good to be a small pool.

1 Like
3

I think this is a very interesting detail that is not covered in the calculation above already.
Here comes my wild theory about it:

In a slot battle between a 1M pool and a 4M pool:

  • 3.5 of 4 times the small pool wins
  • 0.5 of 4 times the big pool wins

For a 1M against a 2M it would be:

  • 1.5 of 2 times the small pool
  • 0.5 of 2 times the big pool

Why 0.5 of 2 times:

  • 50% chance: big pools VRF is > 1; small pool winds
  • 50% chance (remaining): Both pools could have a VRF < 1 → 50% chance for both = 25% absolute chance

If this theory is correct this has quite a massive impact.
I’m lacking data to prove this theory. I will take a look if PoolTool Data can be used for this.
While I’m doing so it would be interesting if someone finds arguments against my theory!

The next step would be to incorporate the different Win Chance into the Saturation examples.
And I would also include this in the Profitability Calculation Logic as it of course also impacts expected ROA: Stakepool Profitability Calculation - #46 by Markus-VITAL

1 Like
4

So who can tell me now if it’s really the truth that a 1M pool wins in 99% against a 50M pool?
Can that really be? This makes a difference of 4,95% and therefore would be more important than the average margins which are set by most pools! Proof me false please :wink:

1 Like
5

I think your logic is basically correct.

I have mostly won battles with other pools much larger than mine. However, I lost a battle last epoch to a Binance pool. The Binance pool produced a block for the next slot after mine but before it had received my block. On checking the leader VRF scores this much larger Binance pool did indeed get a lower VRF score than mine so my block got orphaned. The Binance pool had over 20 times more stake than mine. Based on your logic, my pool should win such a battle >97.5% of the time. So, on this occasion, I was very unlucky.

1 Like
6

No. The calculation is about a Slot Battle (both pools got the same slot assigned). If Binance was one Epoch after you it was a Height Battle (ghosted Block)

7

Yes, I understand the different terminology which is why I just called it a “battle” as opposed to a “slot battle”. However, the outcome of both types of “battle” is similarly determined by the VRF score because it is not really a height competition when each fork is only 1 block high.

8

Good point. My calculation is wrong in that regard. Actually, the Ghosted Block scenario is also determined based on VRF (see link below). So the same chance/risk calculation that applies to slot battles also applies to height battles (ghosted). This means: If you have not fetched the previous block because proptime e.g. is >1s the samller VRF has the bigger chance to win that battle (just like the height)

Link regarding ghosted VRF: Consensus should favor expected slot height to ward off delay attack · Issue #2913 · input-output-hk/ouroboros-network · GitHub

Thanks for pointing this out @7.4d4 !

9

As VRF based battles get this high importance I ran some calculations.
The calculation is based on the current (Epoch 329) Active stake of all current pools.
It’s a win scenario between an assumed stake against each individual other pool weighted by the number of blocks of the according pool.

So here is the table:
image

10

I incorporated the new findings into the overall sheet. Following changed:

  • Slot Battle win chance now considers pool size
  • Height Battle now considers pools size
  • Propagation Times distribution was updated based on a currently collected data set from PoolTool
  • Height Battle risk is multiplied by 2 as a block before AND after your block is exposing a risk
    → low Propagation times get EXTREMELY important for small pools in this calculation

Screenshot of the key results:
image

@AndrewWestberg: I would be very interested in your view on the topic. Is my assumption correct, that a ghosted scenario needs to be considered for previous and following blocks with the same (VRF based) risk depending on my pool size? Those numbers are quite insane. Almost 6% ghosted block risk for a fully saturated pool. 10% overall risk of losing an average block.

11

Yes.

However, if there is enough delay that another pool creates a block on top of another fork then this will result in a “height battle” which will be resolved by “longest chain wins”. The VRF comparison is only applied if the forks are of equal length.

According to Duncan Coutts: The current ordering rule is the lexicographic combination of the following, in order:

  1. compare chain length
  2. when (same slot number) then (compare if we produced the block ourselves) else equal
  3. when (same block issuer) then (compare operational certificate issue number) else equal
  4. compare (descending) leader VRF value

See: Consensus should favor expected slot height to ward off delay attack · Issue #2913 · input-output-hk/ouroboros-network · GitHub

12

Yes. There are more complex scenarios which influence the propabilities. Would not be able to calculate that and I think I’m Ok with a rough number here which kind of gives a realistic impression.

13

Just realized that the shared link is not working.
Here is the latest version on Google Docs: Cardano - Lost battle risk by pool Size - Google Sheets