BP node block producing capability checkup command

A single node command that would simulate/test minting blocks with pools stake and keys and a return that can be reported or verified to pool explorer sites. That would unequivocally confirm that the pool’s BP node is capable of minting blocks.

Currently there are many indicators and checks of various technical difficulty SPO is required to do (pool registration) or can additionally do (key checks against ledger state) but even with all of them SPO is not sure everything is in order until a block is minted.

The biggest issue is that small SPO can wait for several months until they are finally selected during which they or their delegates might leave the pool or owner to leave the network.

If possible to create such a feature it would be extremely helpful to small SPOs now and in future.

2 Likes

You can generate your expected slot leader position(s) at the beginning of each epoch. Then compare that to actually produced blocks. You can save yourself some server fees by turning off your equipment through the epochs you won’t be making any blocks.

We are not talking about same issue.

Even if we were, checking leader logs *each epoch will not do much for SPO that has around 150k of total stake (or less) and 3% chance of being selected (or less).

SPO and any potential delegator could find very useful a reportable, verifiable response that pool is unequivocally ready and capable of minting blocks if selected. It would ease the mind of SPO that has entered the network and make their pool more attractable to potential delegates.

*I believe leader logs needs to be checked for each current epoch, if I’m mistaken please someone correct me but this still wouldn’t solve issue I raised

What a node can check:

  1. Verify your KES keys are valid.
  2. Your opcert expiry (KES Period) has not reached
  3. Verify that you’ve started your node as a leader with keys (valid VRF keys).

Your block propogation

All of the above is already reported via EKG and sorry to say - is very easily queryable.
Going beyond to validate whether the keys used is correct for a pool, whether your pool was registered correctly, etc is really subjective to individual steps (it is more like asking “tell me if even number in the envelope is what I thought in my mind” without sharing what’s in your mind).

Regardless, the human aspect (about right keys and validity of pool registration) is pretty much you entering information and validating it, it hasnt got much to do with protocol can/should do.
The other part (metrics already available in EKG) is something you can whip up a script to verify if everything is fine - the node already does spoon feed this information making it available as a metric.

If you do not wish to query EKG yourself, you can use the scripts that do this readily for you (eg: gLiveView ).