I have made many posts about this and I feel that I need to continue to bring this up as the current protocol just does not appear fair. According to gLiveView I have had an ideal of 0.25 or just under for the last year and yet my slot allocation does not reflect this percentage at all. In the last 40 Epochs I have been given one slot when statistically you would expect that to be somewhere around 10.
All I want to know is the facts. I have spent significant money investing in Cardano, running a Stakepool and promoting everything about Cardano for the past 2 years. My Stakepool is operating correctly and is configured exactly as it should be. Slot allocation was as expected for the first year then after Epoch 320 things suddenly changed and only one slot has been allocated since then.
I have heard from others that developers have said that Pools that have stake less than 1M do not get selected in proportion to their stake and Ouroboros favours larger Stake pools. Is this correct and if so why? Small Stakepools deserve to be rewarded in proportion to their stake and if not then there are some serious questions to be answered.
I understand Maths and Statistics so yes anything can happen with regards to slot allocated but things should tend towards the average over time. I have also heard from other StakePool operators who have around 300K to 400K in stake that have gone 20 Epochs without a slot selection. If this is the case this then how can this be acceptable. This is real money and real time that we are investing and yet I am getting absolutely no returns or rewards which I should be entitled to. I am doing my part in supporting decentralisation and the Network so I do expect some kind of explanation for this rather than the usual âwell you need to get more delegationâ or âits just bad luckâ - it gets to a point where this canât just be bad luck.
Sorry for the somewhat annoyed tone of this post but after 2 years of devoting myself to Cardano I just feel that it should not be this way and I appreciate any comments people may care to give.
Sorry to hear youâre struggling. When we were around 160k staked, we were around an ideal of 0.16 for a long while, which would become an estimate of a block every ~6 epochs. Our average time between blocks back then was actually more like 9-10 epochs. But I can certainly see that in the realm of statistics as a possibility. I donât do much math on that, but 20 epochs without a slot with 300-400k staked is indeed fairly unlikely.
Iâve implemented the tpraos algorithm in the cncli tool that gLiveView uses to calculate leaderlogs. The equation used for calculating âideal slotsâ is here:
If thereâs no issues with the pool and youâre still seeing active stake each epoch and a positive sigma value, the ideal slots value should be correct.
The tpraos (and praos once we hit babbage), are based on VRF (verifiable random function) keys. I canât see how this is anything other than just bad luck.
Weâre a small pool as well and on a little drought at the moment. I am just putting it down to bad luck. Unless there is something fundamentally wrong with the protocol, but I expect someone like Andrew would have pointed that out by now.
Itâs tough, but it is also the way the chips fall.
Thanks - the pool should be ok as everything checks out and we did get a block which was minted in Epoch 351 - nothing has changed with the pool (other than recent upgrade to 1.35.3) and we are showing active stake on all the explorers. The frequency of slot allocations just appeared to change abruptly after 320 which is why we are concerned. Still as you say maybe it is just poor luck but this is one 4 sided dice that just doesnât want to come in
It is purely (pseudo) random, based on VRF, so this less than 1M and favouring larger pool are fuds.
You can check here that the Praos preferred the smaller pools. How will TPraos work? I have no clue as I have not checked the latest code.
As I said it already, it - statistically - favors small pools to the big ones on slot battles, which makes sense as their loss can be much higher than some larger pools. Imagine, youâre entitled 1 block in 10 epoch and your pool has a slot battle at a certein slot with a larger pool who is entitled to create 30 blocks in that epoch. So you would loose ~10x of your pools epochâs rewards while the other just looses ~1/30 of it.
So, do not fall into Gamblerâs fallacy. Random is random. You, a littlebit contradict, because you says you understand statistics, but in other sentence you says otherwise e.g., things should tend towards the average.
You mixed the independent VRF eventâs with the law of large numbers in which the average would apporaches to the expected number, but it needs lot of trials. Thatâs why itâs called the law of large numbers.
I cannot see anything wrong with statistics and probability in Cardano.
Many thanks for your response and I appreciate your time.
Yes I understand how the slot battles work but I have not been allocated the slots to start with and this is confirmed as I run the cncli command to check for slots each 5 days
Yes as I have said I understand statistically that anything can happen and I have not said that what has happened is not just down to chance so there is no contradiction here. A number of people keep defending the protocol with Gamblerâs fallacy. This is an easy explanation to explain away anything. Yes I have said it could be due to chance and yes you can go and play Roulette and get 10 reds in a row and yes if the Roulette wheel has just rolled 25 reds the chance of a red on the next roll is still 1 in 2. I get all this but it may get to a point (maybe not) where the âjust bad luckâ answer may not be the reason. I am raising this now as I have detected a potential change in how the protocol is behaving. Yes at the end of the day it probably will all be all down to bad luck but we cannot just assume this all the time.
I have maintained and worked on this pool for 2 years now and have a number of faithful delegators that may be reaching the end of their patience. Some pools have had the luxury of getting a lot of stake for whatever reasons and good luck to them. The pool has cost me considerable money at this point in time with not much hope for the future based on current prices and the macro economic situation so please try to understand if I sound a little annoyed when I keep getting told âits just bad luckâ I hope this is so but right now I am extremely frustrated with the whole process.
Unfortunately, thatâs how itâs. You can be angry, frustrated, but it wonât change any facts does not matter how hard you would like to, as youâre biased i.e., you are on the suffering side (and youâre inclined to find anything that can prove your theory). I can understand, but this is how Cardano works. Theoretically there should be only k number of fully saturated pools and some tails.
VRF is very simple, it generates a verifiable random number (that all other nodes can verify) compared to your stake (as a chance e.g., like 1/6 of a dice or yourstake/totalstake what is used currently) and based on the slot number, epoch once (a random enthropy) and your VRF key. If that number is less than your stake as percentages (converted to a big number), then itâs true, otherwise itâs false. It always, generates randomly, if youâre in doubt than rise some concern in the proper forum against the VRF alg used in Cardano the Algorandâs VRF.
If you interested in a very simple explanation of VRF check my gist I wrote abt ~2 yrs ago, check Vincentâs link (or Even Andrewâs) for detailed explanation, but itâs not required, itâs very simple.
Thanks and I appreciate your response. I will continue to monitor the slots and see if the luck factor changes over time.
While there are probably good reasons for why the protocol functions as it does and I certainly do not want to challenge this I believe the frustration with myself and small pools in general is that we just want a fair go - if our stake gives us a probability of 1 in 4 per Epoch then we shouldnât have to wait years for the numbers to average out to this (if in fact this is the case but I am not saying it is)
I think it is important to also be sensitive to the plight of small pool operators. Many of us have lost quite a bit of money on running a Stakepool (let alone some considerable capital loss right now) and do put in a lot of time and effort to promote Cardano and build on the eco-system. While Cardano may have a theoretical k value and number of pools that are ideal for the network this is certainly not the message that many of us get from the community. We often see tweets and messages from IOG and others about how the eco system is strong with 3000 plus pools so we should not on one hand say we only need x amount of pools and then on the other hand say how strong the network is with thousands of pools. Small pool operators may not be that important to the network on a technical level but certainly from an appearance and growth perspective which leads to the promotion of the network we are vitally important. It is for this reason that I donât think we should be underplaying the importance of small pools getting the rewards that they are entitled to.
Once again thanks for the response but please let us not just brush aside the frustration that we feel as it is often the case that the only difference between a strong large successful pool and a small pool can be the luck of the draw when it comes to large delegation.
@GrahamsNumberPlus1 I sense your frustration at your lack of reward for hard work. I agree that things are not configured properly at present.
I think one thing that can be changed easily is to lower the min Ada fee from 340 down to something like 30 as proposed by IOHKâs @Colin_Edwards in this thread:
It wonât get you paid more initially but will give you more ability to attract delegators.
On my website I say the following:
I do not recommend you stake with Terminada pool yet because the protocol does not allow setting the fixed fee any lower than 340 Ada.
With a fixed fee of 340 Ada you will lose too much of your rewards to fees until the pool size is over 10 million Ada.
I am hoping that enough community support builds to change this min fee parameter soon.
In the longer term, there are proposals to redesign the staking + pledging benefit metrics like that proposed by @Michael.Liesenfelt at:
I agree with you 100% - currently we give most of our Pool Fee back to Delegators but this is a painful and laborious process. There are a number of issues with the Pool Fee. The first as you say is that it makes it totally uncompetitive for small pools as there is an immediate tax (so to speak) of over 50% for Delegators when a pool can only mint one block in an Epoch and so why would any Delegator
choose a small pool? Secondly there are a lot of claims that small pools pay as much as large pools which is simply not true because of this reason and this could lead to compliance issues down the road especially when Delegators are unaware of this or listen to some of the misinformation out there.
The Pool Fee as it currently stands comes across as some form of protectionism for those pools that regularly mint blocks as they know that there would be an immediate cut to their income if the pool fee was reduced to as you suggest 30 ADA. The thing is that this is supposed to be a competitive environment and those pools that best serve the community and the network should be the ones that survive and it should not be based on an artificial parameter. Let us not forget that many pools have invested a lot of money and time and they do have a right to exist on a level playing field.
I agree with that; these guys know what they are talking about.
The way I tend to think about this stuff is a binomial distribution
(your stake) / (all stake) = your chance at any block
in an epoch, there ~21600 blocks (but we lose some of them)
for example, if your pool was 250K, and 25 billion Ada total was staked:
(250e3 / 25e9) = 0.00001 (0.0010%)
In an epoch, you might have somewhat less than 21600 blocks (a bit over every 20 seconds), I typically assume about 5% lost
Thanks for this and yes I donât think there is any issue with the stats
so we would agree then that 1 slot in 40 Epochs would produce a very small chance of this happening. I agree that all these concepts are correct and of course you can have outliers in any statistical model. The guy that wins the lotto - he is an outlier that managed to defeat the odds of 1 in a million. I guess the issue is for me at what point does this no longer just become poor luck - after 60 Epochs?, 100 Epochs? - at which time of course my Stakepool will have no reputation at all for minting blocks
I tend to think about frequencies, so out of 2000 stake pools with 250K Ada delegated to them:
After 10 epochs (50 days): 215 of 2000 would have no blocks
After 20 epochs (100 days): 23 of 2000 would have no blocks
After 30 epochs (150 days): 2 or 3 would have no blocks
After 40 epochs (200 days): pretty much all the pools should have seen a block by now
(when observing the actual population of SPOs, there is some survivorship bias - the pools that survive tended to be a bit luckier than average)
That being said, after 40+ epochs (and 250K Ada), I would be suspicious that there is something else wrong: registrations, relays or some network thing.
Yes everything has been checked more than once and as stated above there was a slot allocated in Epoch 351 during this 40 Epoch stretch which was minted successfully so no configuration issues. I also check slots allocated using the cncli query every 5 days and so no blocks lost to slot battles or stolen or whatever - also 26 blocks minted reasonably regularly prior to Epoch 320 - this is why I am a little suspicious.
There were a number of changes around epoch 320 related to block size and memory usage around that time. There were no economic / ledger rule changes.
Not sure why those would lead to any issues; someone more familiar with the hardware requirements and might be able to answer (I am aware of the changes in a general âread the release notesâ sense, but there may be something I missed.)
If you are checking the leader logs with the correct information then this is deterministic. To be sure you could check using the cardano-cli rather than relying on an additional tool (cncli).
Change âcurrent to ânext for next epoch (after it is 3.5 days completed).
On the other hand, if your leader log says you got allocated a slot and your block producer didnât produce a block or it wasnât included in the blockchain, then you have a problem. The fact that you have produced blocks in the past, and these blocks coincided with your leader logs, indicates that you are doing the leader logs correctly.
You can also look at your luck percentage on a site like adapools. If your luck percentage is significantly less than 100% then you are either failing as an operator, or unlucky, or both.
One good thing is that as a small pool you shouldnât lose many slot battles
