Leaderlogs

View whether you are scheduled to mint a block or not

What are Leaderlogs?

As a stake pool operator, it is possible for you to run queries to determine whether your pool is scheduled to mint blocks. This is an important capability so that the SPO can schedule maintenance activities around these block minting times.

Can I view Leaderlogs for all epochs?

Right now, we can only view leaderlogs for the following epochs:

  • Previous epoch

  • Current epoch

  • Next epoch (only available 1.5 days before end of current epoch)

Can I check Leaderlogs any time?

Theoretically, if you are looking for the leaderlogs of the previous or current epoch, you can can check leaderlogs any time. If you are looking for the leaderlogs of the next epoch however, you should only run leaderlogs within 1.5 days from the end of the epoch. This will ensure that the information is already available and accurate.

Aside from the above timing, you should be aware that checking leaderlogs used to require a ledger dump which takes a significant amount of CPU and memory resources. The code has since been improved to use significantly less memory but it still uses a lot of CPU and memory resources towards the end of the process. Because of this, your block producer may stall and in extreme cases if you have limited memory, your Cardano node process may restart when you check leaderlogs.

Therefore, it is highly recommended to check leaderlogs only during times when you are not expected to mint blocks. To be safe, look for a stretch of a few hours where no block is expected and run leaderlogs then.

Can I check Leaderlogs from a relay?

As discussed above, checking Leaderlogs is a resource intensive process which can potentially bring down your BP. A safer alternative is to run Leaderlogs from a relay node. This will require you to have the vrf.skey copied to that relay. For added security, this relay can be an unregistered relay so it can't easily be discovered in the network. With this setup, you will not be worried of bringing down your BP whenever you check your leaderlogs.

What are the ways to check Leaderlogs?

Currently there are three ways to check Leaderlogs:

1. CNTOOLS

If you are using cntools, then you should be all set as you can view leaderlogs directly via one of the cntools menu. You can ignore the rest of this section.

2. Cardano-cli

In recent versions of cardano-cli, you can check leaderlogs using the command below. Remember to change the directory locations and other details like pool-id according to your own setup:

cardano-cli query leadership-schedule
--genesis /home/cardano/cardano-my-node/mainnet-shelley-genesis.json
--mainnet
--vrf-signing-key-file /home/cardano/cardano-my-node/vrf.skey
--stake-pool-id a23fbbedd487b28b919ac516697ab3ff1baa5c02b5774ff0bffbb883
--current # To check leaderlogs for next epoch, change this line to "--next" 
--out-file RAWLEADER.txt

The output will look like this

 SlotNo                          UTC Time 
------------------------------------------------------- 
 53036997                   2022-08-05 23:16:53 UTC
 53038481                   2022-08-05 23:41:37 UTC

Take note that currently the timezone format is only in UTC. However, I have since created a wrapper script for this so you can see the output in other time zones. The script can be found in the WISH Pool github here:

https://github.com/bclens/scripts/blob/main/leadblk.sh

3. Cncli

This method uses a third party tool called cncli which was written by Andrew Westberg. The instructions to install cncli and check leaderlogs can be found in

https://github.com/cardano-community/cncli

Nevertheless, to speed up installing and checking Leaderlogs, I created the following wrapper scripts:

  • LeaderlogInstall - script to download and install latest code

  • LeaderlogCalculate - script to calculate the leaderlogs and save them to file

Both of these scripts can be found in the WISH Pool Github here:

What are best practices regarding Leaderlogs?

Once you know your block minting schedule, it is a good idea to keep the schdule a secret to prevent targeted Denial of Service attacks. Of course, this will not prevent a determined attacker who performs a sustained attack over several days/weeks. In these cases, you can block the attacker’s IP through the firewall.

Last updated