We’re running a Cardano validator for more than 2 months, and current active staking is 25m, the validator was running OK to perform 24-26 blocks in the past, and matches to the leadership-schedule.
We encountered an urgent issue: the leadership-schedule only allocated 16 slots for current epoch 444, is there anything wrong for our pool? The pool id is pool1luyjjta9jja0nvh4wzqt4jvtesrlt893dj4c7x533dvfq9zshvp
And the next epoch leadership-schedule will be 27 slots, so we don’t know what to do now
Any help will be appreciated
That sounds like normal fluctuation. (For example, in epoch 441, you had 42 blocks, so a fluctuation in the other direction.)
The block allocation is a random process and it can happen that you get more or less blocks allocated.
It only hints at a problem with your setup if you do not get any blocks allocated at all or if your pool does not produce the blocks allocated to you.
Thanks for the quick response and it’s helpful
Is there any reference / formula to determine this random value? The range is a bit too big and affect our SLA to our users
An explanation is here: https://www.ada4good.com/post/how-is-a-stake-pool-selected-to-mint-a-block-slot-lottery-explained (Observe that the advantage for small pools in slot battles mentioned there has been removed in the Babbage/Vasil hard fork.)
Specifications can be found on: https://github.com/input-output-hk/cardano-ledger The leader value calculation is in Section 16 of the Shelley formal specification as far as I found it.
You probably shouldn’t make agreements that the architecture of Cardano doesn’t guarantee.
The key part is random. There’s no guarantee per epoch, just a long term expectation.
Thanks for the info again and your recommendations are noted
One more question on this: is there a better way to query the leadership-schedule within the epoch because it’s already determined and we don’t want to load the node to check these allocated slots again
We want to build an efficient monitor to check our node performing well and mints all the allocated blocks
OK, I found the answer from the article you shared to use CNCLI tool, we’ll try out accordingly
But please let us know if there is any other better approaches
Thanks for your response and noted the “long term expectation” is interesting
Looks like the lottery algorithm can still ensure the 1 million per block per epoch in the long run
Yeah, it is close to 1M, but I think it is more like 1.3M or 1.4M now. There’s some equation behind it.