Pls check the latest design and ledger spec.
Now I see where my confusion is coming from and I understand what sigma a youâre talking about.
Could you please link your version of the design spec? I only have this one:
Thatâs why I like science, as itâs immune to our believes, feelings and opinions.
I just made a rough calculation assuming:
- pool is oversaturated 230m
- it forges all 144 blocks of 21600 i.e. 1/k
- Total stake 31bn, active stake 12bn.
The sigmaa makes p=35%
If only sigma would be used then p=89%
if capped sigmaa then p=100%. (fair as apparent performacne should be based on the ratio of the generated and expected blocks relating to their stake to a max 1/k) and by no any other factors.
So, pls tell me that 35% apparent perfomance does not over penalise that oversaturated pool
This is the link to the latest
âhttps://hydra.iohk.io/job/Cardano/cardano-ledger-specs/delegationDesignSpec/latest-finished/download/1â
1 Like
So do I. Unfortunately I was referring to an outdated version of the design spec. Is there a compiled version, I donât have latex installed on my current machine.
Edit: thx for the link!
I linked the latest link above. Use that one.
I have to get off now, I will check the latest docs tomorrow. But from a first glance I donât see the benefit in the change they made. The older spec I was referring to seemed fine to me in regard of rewards distribution.
IMO, It was a rational step, but they forgot capping the sigma a, or left it on purpose for overpenalising the oversaturated pools and their delegators for incentivising them to re-delagate to smaller pools.
Cos that 35% (if I did not calculate it wrongly and assuming they implemented what is in the spec) penalty after 100% blocks would hit them very hard.
It says slot leader election is based on sigma a, so in your example the pool would produce more than 1/k of all blocks. So performance would be 100 % if the pool produced all expected blocks.
Yes, I missed that and you seems right, and all good then.
Hi Umed, not sure I understand the problem⌠maybe the term âoptimal pool rewardsâ is misleading. âCappingâ at saturation happens for optimal pool rewards, i.e. a fully saturated pool canât increase its optimal rewards by growing even larger. Actual rewards, however, are optimal rewards multiplied by performance. And performance is not capped and can be > 100%.
So a fully saturated pool that performs perfectly can have performance > 100% and will receive more than its optimal rewards when that happens. A pool that does not miss any blocks will - on average - get itâs maximal rewards, no matter its size.
3 Likes
Lars,
Thank you for providing the the clarification. The essence of problem was to determine if there was some kind of hard cap in place that wouldnât allow pools to categorically receive rewards beyond some threshold.
I see from your response that there is a cap on rewards but no cap on performance which means a saturated pool can receive rewards above its reward cap in any individual epoch but eventually its average rewards will converge toward the cap, regardless of interim fluctuations.