MYLO pool received the IOG delegation of 3.4M ADA, which became active in epoch 297. Only 1 block was minted in 297, 0 block in 298 and 1 block scheduled in 299.
I was expecting 3 blocks in all epochs. I just setup cncli to calculate leaderLog 2 days back and it reported 1 blocks in 299.
How can leaderLog calculate 1 block in future epoch when it is generally expected 1 block per 1M ADA staked?
I have 2 relays (2 vCPU, 16Gib memory, 64Gb SDD) geographically distributed on Azure running 24/7 and topology updated daily.
1 BP (4 vCPU, 32Gib memory, 64Gb SDD) running 24/7 on Azure
I can share Grafana dashboard if needed.
Need help to analyze what could be wrong and why am I not minting 3 blocks as generally expected.
As long as your pool_id and vrf-key you supply to cncli is correct, nothing you do will change the number of slots you get assigned. Especially not the technical equipment in use for your nodes (as long as it is correctly configured). If you produced blocks for your assgined slots, you’re fine.
It’s statistics. You will have epochs with more then the expected number of slots as well - and complain less. Be patient!
According to cncli leaderLog, it says I am assigned 1 block at a specified slot and time. Do you think there is still a possibility to mint more blocks or zero blocks assuming my BP and relay configuration remains up and constant all the time?
No it is really accurate, you’ll get what is assigned.
Luck sometimes really sucks, i got 1-0-0-1-0 assigned blocks for the past 4 epochs and current one with active stake of over 3.7mil. Ofc many delegators left because of that and now i am at 2.7
Thanks this really calmed my nerve. Fortunately my delegators are die hard loyalists and not a single one left even after 3 months of blockless performance.
Man, delegators need to calm down… they should not worry if one epoch has bad luck… because next epoch the pool will have more blocks assigned… if u look on adapools u should have the total luck ~100%
The cncli runs the exact same lottery as the node for all 432000 slots in the epoch. The tool does it upfront the node does it in realtime. Therefore, its important, that your BP does actually run the lottery at the slot times that the tool predicted. A missed slot can for example occur when the BP is busy with Haskell garbage collection - a process that can hold the world for multiple seconds. Let’s say your BP did run the lottery and it actually won - it would then produce a block that one of the relays can pull. A BP that doesn’t have incoming connections would produce blocks that never get picked up by the network.
The whole process is totally deterministic entirely based on stake distribution and a few constants (i.e. your poolid). Because of this deterministic nature, the tool can predict the exact slot(s) when the BP is going to win the lottery.
When the tool predicts no blocks for period P, you might as well shut down the system for that P - which of course you wouldn’t actually do, but still this is also the time period for maintenance (e.g. node updates, reloading of the topology, restart because of those annoying GC memory leaks, etc)
Yes, it happened to me back in epoch 283 where I was assigned a block and BP minted it but due to mis-configuration the relays did not propagate it. Maybe I am punished now for that mistake, lol.
No, it is more like throwing a dice. Each throw doesn’t care whether you won/lost in previous throws. Specifically, whether you win/loose any given slot (out of 432000) is determined by a verifiable random function (VRF). This is why cncli tools and the node not only need the exact active/total stake but also the vrf.skey as input. The outcome is deterministic and anyone who holds the vrf.skey can produce it. All others cannot produce the output, but they can verify that the output is correct using the public vrf.vkey (i.e. they can verify that you are not cheating when claiming that you won a slot)
Just saying, is that mean that when the protocol rolling the dice, it doesn’t matter how’s the pool previous return? I mean, for example the average return of one delegator is around 4-6% p.a. right? So, if one delegator, delegate to one pool that never get block, will the protocol check and give the pool at least one block in a year to give return to the delegator?
The protocol has no notion of past events. It works both ways and it is probably fair to say that a fair game (i.e. the die is not biased) is the best possible setup.
You can of course assume that because of some funky cryptographic property not all pool ids and vrf.skey are equal and that some pools are always going to be more lucky than others than others. That however, would be a bug which would need to get verified. In the meantime, you might choose to delegate to such a pool until proven wrong. Jumping around is pointless IMHO.
Differences at that level will likely not matter much. What really matters is “effective cost per block”. You will want to find a pool that consistently produces blocks and does something meaningful with 6 x 340 x 2.0 => $4080 p.m. No one should need that much to have two simple servers running, while much of this profit could be doing something good in the world.
IMHO, it’d be good idea for the delegator community to gravitate towards non-profit pools. It would maximize their returns AND have meaning in the world.
