Now that I’ve started using cncli to check the leader log to see if my pool has been assigned a slot, I’m wondering if it’s possible for my pool to still create a slot in an epoch where cncli leaderlog returns an empty array for assignedSlots in the current epoch? I was lucky & was assigned 1 block in epoch #253, the first epoch my pool was eligible. #257 is now the 4th epoch in a row with no assigned slots. Also, does “epochSlotsIdeal: 0.95” mean I’m SOOOO close to being guaranteed at least 1 slot, but not yet?
1 Like
Great question, I am not sure but I would like to know about this too
1 Like
epochSlotsIdeal=0.95 means that you can reasonably expect to mint 73 x 0.95 => 69 blocks p.a. Those will not be distributed homogeneously over all epochs. Instead they follow the Bernoulli distribution. This pool here has a epochSlotsIdeal=0.84 and as you can see, there is 43% chance that it does not win a block in any given epoch, no matter what happened before.
2 Likes
So even though I was not assigned a slot when querying the leader log for this epoch, are you saying there is still a chance my pool could be nominated for a slot?
I don’t think so, leaderlog runs the same lottery algorithm as your node does and unless there is a bug somewhere, I’d say it is a good time to do some maintenance - leaderlog is reliable AFAIK.
I wanted to point out that the chance to win one block is not 95%. Instead, it follows the Bernoulli distribution - only on average over many rounds you win 0.95 blocks / epoch.
1 Like
Thank you for the explanation, tom. I just applied for the IOHK delegation assistance program and will hopefully be up over ₳1,063,183 soon. My Live Stake is ₳995,576, only ₳67,607 away! 
So with the Bernoulli distribution, if my epochSlotsIdeal was higher than 1.0, I can reasonably assume to create at least 73 blocks/year, but that doesn’t guarantee at least 1 block per epoch? ie.I may have an epoch where I create 2 blocks, which would mean I’d have at least 1 epoch/year with no blocks? I’ll hopefully have much more stake in the months to come and not have to even think about whether my pool will be nominited every epoch. I understand the distribution over the year but my stakers don’t and think there’s something wrong with the pool.
For your delegators, the picture is not so rosy. There is a cost to the reward they are receiving, which is as follows …
340 / (64 x 750) => 0,7%
340 / (32 x 750) => 1,4%
340 / (16 x 750) => 2,8%
340 / (8 x 750) => 5,6%
340 / (4 x 750) => 10,12%
340 / (2 x 750) => 20,24%
340 / (1 x 750) => 40,48%
Assuming your pool has a 0% margin and that the block reward is 750 ADA, it follows that for every epoch your pool mints at least 1 block you as the owner will keep 340, which will not be distributed to the delegators. i.e. your delegators will loose > 40% of their rewards by delegating to your pool instead of a saturated pool that makes 64 blocks per epoch (on average). The cost for the saturated pool is also 340 ADA i.e. a much smaller slice of the total reward that is taken away before the rest is distributed.
Such a loss is very hard to justify. Even worse, if your pool reliably mints one block per epoch, the owner receives 6 x 340 => 2040 ADA per month for running two simple nodes (also assuming 0% margin). This is far more than anyone should need to run the pool. There is currently no automated way for an owner to distribute at least some portion of that to the delegators.
This mechanism helps, that the system will eventually converge towards k saturated pools, with k=500 as it is now. k may increase substantially in the future, but there is a healthy upper bound because the network cannot sustain an unbounded number of pools.
You can also look at this in a much more optimistic way. The ROA that a delegator can expect from a (staturated) pool is about 5,8%. Ok, with a small pool he/she will “only” get 3,45% and for most people a delta of -2,35% p.a. is not so important, if at the same time the project as a whole is successful, which may result in an increase of their stake value, which then dwarfs these small number games.
Still, especially with friends/family it is probably good style to let them know that, so they can make their own (educated) decision.
2 Likes
I kept the knowledge that k=500 would probably increase soon in the back of my head when I launched my pool March 3rd. I am hopeful that if the saturation level becomes 32 million, many stakers will be forced to choose pools with more room, giving my pool a better chance of a healthy saturation level. I’ve communicated to the friends/family who currently stake with me that it could be a bit bumpy for the first few months. But for those who’ve staked with my pool that I don’t know, they could decide to leave after a few more epochs of not creating a block, which would only perpetuate my current sitation of a low stake amount. I have social media accounts for the pool on all major platforms, but I wish there were some way of communicating with all stakers, even if just a one-way announcement channel.
I like to approach this in a radical altruistic way, as an owner I don’t want to receive more rewards than any other delegator, which creates a very nice situation that we indeed can be on this journey together.
2 Likes
Unless a fundamental change in pledge effect is implemented the k will most likely stay at 500. At the moment it would only lead to big pools starting second basically 0 pledged pools instructing their happy delegators to move there.
2 Likes
Altruistic approaches seem to be a viable way! Many of the SPOs just claim to be committed to the idea/network/community, but are they truely willing to share and sacrifice their piece of cake? We are:
https://poolg.de/Cooperative.html
So far it takes off pretty well. You might want to copy the altruistic way, or even come up with something new/better. Let’s walk the talk!
1 Like
We had the case. Fresh starting pool, little delegation and we got our first block very quickly. I suppose we got a block due to some other pool missing its block?!
Not necessarily. It works similar to this … There is a jar with 22.83b lots. For every ADA of your active stake there is a winning lot, all the others loose. Every 20sec, your node reaches into the jar and draws a lot - it does this 21600 times per epoch. In your case, the node reached into the jar and got lucky - voila, your first block - Congratulations.
Unfortunately, I can’t comment on collisions, because I don’t know exactly how that works. Sometimes slots are not getting filled (density is < 5) and there is also the possibility of more than 21600 blocks (density > 5). Maybe somebody else could shed light on that.
2 Likes
The node reaches into the jar every second and evaluates if they are the slot leader.
see excerpt from my log, each of these records is 1second apart
“TraceNodeNotLeader”),(“slot”,Number 2.5838704e7)
“TraceNodeIsLeader”),(“slot”,Number 2.5838705e7)
“TraceNodeNotLeader”),(“slot”,Number 2.5838706e7)
1 Like
Ah, ok. Do you also know how Chain Density 0.05 comes into the game? There are 5 x 24 x 360 => 432000 seconds in an epoch. 432000 x 0.05 => 21600 blocks per epoch. Somehow only every 20th draw counts.
Yes, apparently the node software is prepared for other densities and returns NodeNotLeader in both cases slot being leader-less and slot lead by other pool. Not a bad design at all.
1 Like