The CENTUO Pool (ticker CENTU) has not generated any block in the last two epochs. I have attached the screenshot of status of the producer node. Is this normal with nearly 800k ADA in stake? Am I doing anything wrong in the pool configuration? I can see that the missed slot leader checks are minimal and acceptable, any suggestion what might be happening? Thank you ).
I’ve seen 4 consecutive epochs without blocks with more than 1M delegation, that’s very possible to happen in your case.
You should check if you have slots assigned to mint blocks every epoch, to be 100% sure it is just bad luck and not a real problem.
i have 700-800 K for SKULL pool you can see ive gone 3 epochs regularly with no block Rewards Pool [SKULL] | Cardano Explorer
It’s all just luck (or lack of) of the draw.
I had a similar problem and it turned out that the pool actually forged blocks but they were invalid because the opcert counter was wrong. See here for more info.
Do you find any useful information when you scan for “Forge:Error” in the log?
Thank you @Anti.biz, I can see this might be normal provided I do not have more than a million ADA in stake.
Thank you @georgem1976, this might be the reason, I might have bad luck in the last two epochs. Hopefully it might be better in the following ones.
It is not my case, I checked the counter and it is ok. Thank you.
Look into installing CNCLI so you can check for assigned leader slots.
Hi @Centuo
If you may be interested in considering the issue that you are describing from a governance perspective (see Voltaire era), then please review a draft Cardano Improvement Proposal (CIP) that I am currently authoring titled I Gave at the Office Feel free to get involved and express any thoughts about the CIP idea in the comments at Cardano Governance #376 as well.
The idea for I Gave at the Office emerged from another pool, GNP1, describing a very similar experience to what you are describing 20 Epochs without a block averaging around 300,000 in stake
For a complete list of the discussions foundational to the CIP idea, see the Rationale section at the end of the CIP draft.
Sincerely,
Hi,
SPOs interested in the current thread may also be interested in Small SPOs - have you noticed a change in the number of slots being allocated since Epoch 320 posted by @GrahamsNumberPlus1
CHG
Finally, after 6 epochs I can see that a block was assigned to be minted by my pool but apparently this block was minted by another pool with much higher stake (with around 60 millions ada!). I understand that the protocol selects the pool with lower stake when two pools are selected to mint the same block, correct me if I am wrong, is that normal this is happening to our pool? It seems we have extremely bad luck considering we have nearly 800k ada in stake.
I have already considered this but see my previous reply.
Not exactly.
Prior to the recent Vasil upgrade, “fork battles” were decided based on preferring the block with lower “leadership VRF” value. This did preference the smaller stake pool because they needed to get a lower leadership VRF in order to be a slot leader in the first place. So it was more likely the small pool would have a lower “leadership VRF” than the big pool.
However, after the Vasil upgrade this was changed to what people are calling the “block VRF”. This VRF result is based only on the following values:
This “block VRF” is deterministic and not based on the transactions in the block so it cannot be gamed. Choosing the winner based on lower “block VRF” produces a randomised outcome. In other words, now each contender has an equal chance of winning the “fork battle”. It doesn’t matter if your stake pool is big or small.
Thank you for your reply, I understand why now.
I forgot to offer my commiserations too. I feel like it is somehow not fair on small pools since they have many other disadvantages already to contend with.
See these Ouroboros GitHub comments from when the change was first discovered: Leader VRF value no longer settling ties · Issue #4051 · input-output-hk/ouroboros-network · GitHub
Originally I had thought it was a problem with cncli. See these comments. But then Andrew Westberg checked and found that his cncli implementation was correct.
You can see from the Ouroboros GitHub comments that it was confirmed as a deliberate change because the design always intended to settle the fork battles this way.
I don’t like it because I also run a small pool. So, I am biased.
I totally agree with you, it is harder now for small pools to mint new blocks. The Cardano community should suggest improvements to help small and non-saturated pools! I hope Cardano core developers treat this as a bug and fix it. Otherwise, this could negatively impact the pools decentralisation.
