Cncli-leaderlogs accuracy

Staking & Delegation Operate a Stake Pool
1

Just wondering how accurate the cncli leaderlogs scripts are meant to be? The same question applies to the python projects which use blockfrost API to determine slots.

WOOF pool minted a block yesterday (first one ever!), but prior to the epoch, the leaderlogs-next script did not report any assigned slots for the pool. And now running the leaderlogs-current script does not show any assigned slots.

Is this a fluke, where some other pool missed their assigned slot, and then the next lottery went to my pool? Other explanations?
Thanks
Kurt

2

Hi,

The CNCLI is 100% valid for me… are u using the correct files for CNCLI? (VRF FILES)

3

Thanks Alex,
Hmmm… that’s weird.

Ok, I double-checked and all the args to the leaderlog command look correct.
I also ran the ReLeaderLogs python script using the BlockFrost API, and it gave same results of no assigned slots.

I must of just got very lucky. I’m not complaining. :wink:

4

But this is a very interesting question. What happens if I am scheduled to mint a block but my server goes offline. Who gets to mint it and how could cncli predict that?

5

missed , this will be the status of the block … and no other pool will create it

Block status

  • Leader : Scheduled to make block at this slot
  • Ideal : Expected/Ideal number of blocks assigned based on active stake (sigma)
  • Luck : Leader slots assigned vs ideal slots for this epoch
  • Adopted : Block created successfully
  • Confirmed : Block created validated to be on-chain with the certainty set in cncli.sh for CONFIRM_BLOCK_CNT
  • Missed : Scheduled at slot but no record of it in CNCLI DB and no other pool has made a block for this slot
  • Ghosted : Block created but marked as orphaned and no other pool has made a valid block for this slot → height battle or block propagation issue
  • Stolen : Another pool has a valid block registered on-chain for the same slot
  • Invalid : Pool failed to create block, base64 encoded error message can be decoded with echo <base64 hash> | base64 -d | jq -r
1 Like
6

Where can one see the block status?

Here is the block info from adapools

7

On glive, are u using glive? Can u share how do u run the CNCLI script?

8

It shows
image

Maybe the pool that missed the slot sees Missed count in their gLiveView?

9

Here’s my current script

10

You mean no other pool i think. If you miss it its gone. No one else can mint that block assuming the slot is not assigned twice. Which happens on ~5% of the blocks

1 Like
11

yeah, no … corrected thx

12

So, it sounds like if cncli-leaderlogs shows no assigned slots for a pool, there may still be a remote chance to mint a block in another nearby slot for the 5% of assigned slots that are missed.

I’m guessing these other slots get pre-assigned with a leader, too, but they are just not used.

13

Nope, misses blocks are missed… will not be created by another pools

14

Ok, so then I can’t explain why I got a block last epoch.

15

Because it was assigned to you from the begining of the epoch? All blocks are assigned with 1.5 days before the new epoch start

16

how do you check LeaderLogs?

  1. do you execute a) cncli synch and then b) cncli leaderlog
    or is the cncli automatic synched?
  2. can that be, that your node was not properly synched?

TTS

17

Hi! I can recommend you this article which explains how slots are assigned: https://www.ada4good.com/post/how-is-a-stake-pool-selected-to-mint-a-block-slot-lottery-explained

This was a research work of the xSPO community which Vahid from Ada4Good published through his blog. New joiners to the community are always welcome BTW :slight_smile:

A few facts about the comments above:

  • Leaderlogs are deterministically precalculating which slots are assigned to the pool
  • It is not possible the a block comes out of the surprise.
  • Slot assignments are calculated based on the Nonce (calculated 36 hours before epoch change), the VRF (which is not changing for your pool) and the stake amount
  • None of the above is changing during the epoch!
  • Slot assignments of any pool are not influencing slot assignments from other pools. By that a slot can be assigned twice which will result in a slot battle
  • If one pool misses a slot no other pool will mint the block instead. Every pool is just taking the slots which it’s meant to mint

Given all of that I only can think of the following reasong for your observation:

  • Your leaderlog calculation was for a different epoch
  • Something is wrong with the way how you are calculating the leader log (wrong VRF key, not synced, no current snapthot)
  • You calculated it exactly at the 36 hour border before the epoch. I’ve heard about scenarios where calculating it directly at the border resulted in calculating it with a wrong nonce. So better not do it exactly at the 36 hour border. 15 minutes later should be fine.
18

Example Script based on Guild Operators with CNTools in place

## Context Preperation
export CARDANO_NODE_SOCKET_PATH=/opt/cardano/cnode/sockets/node0.socket
cd /opt/cardano/cnode/guild-db/cncli

## Calculate ledger state
cardano-cli query ledger-state --mainnet > /tmp/ledger-state

## Sync DB
cncli sync --host 127.0.0.1 --port **YOURPORT** --db /opt/cardano/cnode/guild-db/cncli/cncli.db

## Calculate leader log
cncli leaderlog --ledger-state /tmp/ledger-state --ledger-set next --byron-genesis /opt/cardano/cnode/files/byron-genesis.json --pool-id **YOURPOOLID** --pool-vrf-skey /opt/cardano/cnode/priv/pool/**YOURPOOLNAME**/vrf.skey --shelley-genesis /opt/cardano/cnode/files/genesis.json
19

you are using cntools?

20

Yes, just added the info above to be clear about it.
I took a look on the script from @extramileit above.
Not sure if the “ledger-state” is handled correct there. I don’t find the accoring parameter in his script.

1 Like