how do you check LeaderLogs?
- do you execute a) cncli synch and then b) cncli leaderlog
or is the cncli automatic synched? - can that be, that your node was not properly synched?
TTS
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 
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.
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
you are using cntools?
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
Thanks zwirny, alexd. I was missing the ledger-state.json file. But, even after making sure the file is available in /root/scripts, it’s still not showing an assigned slot for epoch 301. I should see 1, since I minted one this epoch.
One note on ledger-state: I couldn’t add an argument for it to the cncli leaderlog command. It gives me an error if I include the --ledger-state parameter when running the cncli leaderlog command
error: Found argument '--ledger-state' which wasn't expected, or isn't valid in this context
Did you mean --ledger-set?
USAGE:
cncli leaderlog --active-stake <active-stake> --byron-genesis <byron-genesis> --ledger-set <ledger-set> --pool-id <pool-id> --pool-stake <pool-stake> --pool-vrf-skey <pool-vrf-skey> --shelley-genesis <shelley-genesis>
So, I just made sure the ledger-state.json file is saved in /root/scripts.
Per cncli install guide, it shows this is an assumption. 5. that you dump the ledger-state.json in /root/scripts/
Here is the output I see. One thing that looks wrong is epochSlots. It shows 0. Is this meant to be the total slots in the epoch, which should be about 5 days* 24 hours* 60 mins* 60 secs?
root@vmi683311:~/scripts# ./cncli-leaderlog-current.sh
2021-11-11T14:08:27.127Z WARN cardano_ouroboros_network::protocols::chainsync > rollback to slot: 45073404
2021-11-11T14:08:27.128Z INFO cardano_ouroboros_network::protocols::chainsync > block 6487914 of 6487914, 100.00% synced
2021-11-11T14:08:29.705Z INFO cncli::nodeclient::sync > Exiting...
WOOF
{
"status": "ok",
"epoch": 301,
"epochNonce": "f5b2633269e0efb87760d029f39ceacb3a9e79c421afea4a77f49048afaa50ee",
"epochSlots": 0,
"epochSlotsIdeal": 0.19,
"maxPerformance": 0,
"poolId": "c22942e1b855136643d1e6e5a75266fb891d87727a8cbf06acd17208",
"sigma": 8.737146313191815e-06,
"activeStake": 208446510450,
"totalActiveStake": 23857504839454980,
"d": 0,
"f": 0.05,
"assignedSlots": []
}
`Epoch 301` 🧙🔮:
`WOOF - 0 `🎰`, 0% `🍀max, `0.19` 🧱ideal
Can u check the steps from coincashew guide?
18.12 Slot Leader Schedule - Find out when your pool will mint blocks
epochSlots should give you the number of assigned blocks
There’s something wrong with your epochNonce. The value is wrong so you get all the rest wrong as well.
Hi Xpriens
Can you tell it’s wrong, b/c you are comparing that to your own output for the current epoch?
I’ve verified all the inputs used by cncli nonce command. My mainnet-byron-genesis.json and mainnet-shelley-genesis.json match the downloads from IOHK for the current build num. My cncli.db has synced 100%.
When I run the nonce command it matches what I see, when I run the leaderlog. I assume we are not using extra entropy, so I ignored that parameter.
root@vmi683311:~/scripts# cncli nonce --byron-genesis /home/cardano/cardano-my-node/mainnet-byron-genesis.json --shelley-genesis /home/cardano/cardano-my-node/mainnet-shelley-genesis.json --ledger-set current
f5b2633269e0efb87760d029f39ceacb3a9e79c421afea4a77f49048afaa50ee
I’m running same script and I see 0 for epochslots as well
This is what i have c0e8aa015de7703c6fbec6c85a0aafb0974082e1eb4808061ad2e5ef23a2fd62
You had a block as well but wasn’t showing when you run leaderlog?
Hi earncoinpool,
I’m expecting it to be 1, since I minted a block in epoch 301. 0 is probaby correct for your pool as I don’t see any minted blocks.
Just curious, wheat is the nonce value you see? Same as xpriens?
“cb3aef21a34dbb2807aa508e03f1d35cffdcf98114d22a193bf8148983522711”
Weird, it should be what @Xpriens had. Are you using cncli v4.0.1 as well?
I used this project GitHub - asnakep/ReLeaderLogs: Cardano Stakepools: Check for scheduled blocks in current epoch. instead, which uses the BlockFrost API. I got the expected results for epoch 301. Notice that the nonce matches xpriens.
cardano@vmi683311:~/.local/bin$ ./ReLeaderLogs_linux.sh
Current Epoch: 301
Nonce: c0e8aa015de7703c6fbec6c85a0aafb0974082e1eb4808061ad2e5ef23a2fd62
Network Active Stake: 23857504839,454979
Pool Active Stake: 208446,510450
Pool Sigma: 8.737146313191817e-06
Checking SlotLeader Schedules for Stakepool: WOOF
Pool ID: c22942e1b855136643d1e6e5a75266fb891d87727a8cbf06acd17208
Leader At Slot: 171583 - Local Time 2021-11-08 15:24:34 - Scheduled Epoch Blocks: 1
1 Like
Yes v 4.0.1
Sorry that was for the next epoch 302. For current 301 it’s
c0e8aa015de7703c6fbec6c85a0aafb0974082e1eb4808061ad2e5ef23a2fd62
Which is the same as @Xpriens
So problem solved for the wrong results but why you get a wrong epochNonce?
Yeah, I’ll have to look into this later, but it’s very puzzling. It appears everything is correct on my end. I compared things to the coincashew guide as well. All of it looks good.
I’ll post back when I learn something.
Thanks all for the help!
2 Likes
I also had this issue of cncli being completely off. But nothing was incorrect with my node files or kes key.
I fixed the cncli leaderlog being incorrect by deleting all cncli db files. Then restarting the sync. It is possible to get a corrupted cncli.db and this will result in an incorrect cncli leaderlog result
rm cncli.db cncli.db-shm cncli.db-wal
cncli sync --host 127.0.0.1 --port <port> --db <path-to-db>
Hopefully this resolves the issue for those who have the correct KES but an incorrect cncli leaderlog output. I only knew as my small tldr:pool minted a block that cncli leader did not show. (We all should be trying to ensure stuff on telgram and discord makes it’s way onto the forum)
tldr; A possible solution is to remove and resync cncli db as it maybe corrupted
1 Like
Yes, this was how I fixed things for me as well. I recall that when I did the cncli syncing the first time, it ran for many hours (longer than a day). It did in fact fully sync and seemed to speed up at the tail end. However, using that sync data, I was getting incorrect leaderlogs info, and my epoch nonce was not matching. Subsequently, I deleted the cncli db data and re-ran the syncing process. It ran very quickly the next time (I don’t recall the exact timings, but it was less than a couple of hours I believe.). Using this data, the leaderlogs reports produced a correct epoch nonce.
I have no idea what caused the issue when I synced the first time. But, if syncing is taking a long time for somebody, then that probably means something is wrong, and you need to delete the cncli db and re-run.
1 Like