Getting an error trying to generate the leadership-schedule for the next epoch:
$ cardano-cli query leadership-schedule --mainnet --next
Command failed: query leadership-schedule Error: Failed to successfully decode the current epoch state: DecoderErrorDeserialiseFailure “EpochState (BabbageEra StandardCrypto)” (DeserialiseFailure 1131577892 “An error occured while decoding asset name exceeds 32 bytes:.\nError: 47686f7374636861696e30313035320060289d05000000002c0000000000000001000000000000000c002800ea12daa6839715fc56d53d704f9327a1f8620d6eae322c1f4008ec9234343738000000”)
$ cardano-cli version
cardano-cli 8.0.0 - linux-x86_64 - ghc-8.10
git rev 69a117b7be3db0f4ce6d9fc5cd4c16a2a409dcb8
Decoding the hex bytes gives some info possibly on what asset name is exceeding 32 bytes:
Ghostchain01052`(,(êÚ¦üVÕ=pO’¡øb
n®2,@ì4478
Anyone else see this?
1 Like
So far running fine for me.
1 Like
Weird. I wonder if voting in the recent poll had something to do with it. Out of curiosity, has your pool voted and published the tx with the metadata attached?
1 Like
Have you got all of the required arguements for that command? cardano-node/9_leadership_schedule.md at master · input-output-hk/cardano-node · GitHub
Also, were you running it 1.5 days before the end of the epoch? (i.e. not earlier)
1 Like
Yes, I have all the params except using --mainnet instead of --testnet-magic, and it’s been working for all the epochs up to now. I just got the same result looking for the next epoch just now.
1 Like
U can open an issue on github… also voting not working for 8.0.0 + cntools
1 Like
It is too early to be doing the next epoch, it just rolled over to the new epoch (or did you mean you tried it just before the end of the last epoch a few hours ago?)
P.S. sorry if these are dumb questions, just wanting to make sure it isn’t anything you’ve overlooked.
1 Like
This looks like an issue from last year, but was apparently fixed. [BUG] - VASIL cardano-cli query leadership-schedule Error · Issue #4128 · input-output-hk/cardano-node · GitHub
You haven’t been running out of RAM? I noticed my leadership check used a bit more ram on 8.0.0 than before.
1 Like
That’s a great thought - I can double check the memory usage while running. Also I was running at the end of the last epoch, within 24 hours of the end of the epoch so it should have been fine in terms of timing.
1 Like
Should the issue go on cardano-node repo? There’s a cardano-cli repo but it seems like it’s not super active.
1 Like
Here’s a great update - now that the end of the epoch has passed, changing the --next flag to --current seems to have fixed the issue. I’ll see if it starts working again in 3-4 days at the end of this epoch. If it fails again I’ll try to get more info.
I did just measure the memory consumed and it used all the physical memory but only dipped into the swap about 20%.
2 Likes
Update #2, now that the end of this epoch is nearing, I tried it again with --next instead of --current and it’s failing with the same error message 
How did you get cardano-cli: did you build from source or download some binaries? Try compiling from source if you’ve downloaded the binaries and vice versa.
So I had built it from source. Your comment caused me to revisit the release notes and at the bottom I noticed something I didn’t have:
Please note that this version contains breaking changes
- Needs newer libsodium-vrf revision
dbb48cce5429cb6585c9034f002568964f1ce567
I re-installed the newer libsodium-vrf and restarted the node itself. This time it worked for the --next epoch slots.
Thanks everyone for your feedback. This appears to be resolved.
4 Likes
Good to hear! Rubber ducking is always useful. 
1 Like
I am a little confused when reading the build instructions now. There is still the section Using the ported c code for development. If I understand this section correctly it means that you can build against a standard Debian/Ubuntu libsodium-dev because IOG have included some extra c code somewhere else in the source files which you use when compiling if you add the following to your cabal.project.local file:
package cardano-crypto-praos
flags: -external-libsodium-vrf
Is this still a safe way to compile the node? I compiled using an external Debian libsodium-dev library and everything seems to be working properly including using cardano-cli to calculate my leadership schedule.
Another question:
Does anyone know why IOG is persisting with using an old version of libsecp256k1? There have been 3 releases since git tag ac83be33 and Debian has release tag v0.2.0 in it’s Testing (Bookworm) repository. I compiled against that Debian Bookworm libsecp256k1 library and everything is working OK after running for 3 epochs now including generating leadership schedules and producing blocks.
I am hoping the reason is that there are probably no important changes since tag ac83be33 affecting anything IOG uses in cardano-node??? But why not use one of the release tags? Are they just waiting for a release version of libsecp256k1 to be in stable Debian/Ubuntu?
1 Like
I’m still using cncli for calculating leadership schedules. It is now much faster, uses less memory footprint and the output looks a bit nicer.
Since I’m sending tips and slots to pooltool.io with cncli, I have a sync’ed database anyway.
However, since there was a change in the JSON file cardano-cli generates for the stake-snapshot request I had to change the scripts. Here is an example:
echo "request snapshot"
cardano-cli query stake-snapshot --stake-pool-id $POOLID --mainnet >snapshot.json
echo "find leaderlog"
cncli leaderlog --tz Europe/Vienna \
--pool-id $POOLID \
--pool-vrf-skey vrf.skey --byron-genesis mainnet-byron-genesis.json \
--shelley-genesis mainnet-shelley-genesis.json \
--pool-stake $(cat snapshot.json | jq 'first(.pools[]).stakeMark') \
--active-stake $(cat snapshot.json | jq '.total.stakeMark') \
--db db/cncli.db \
--consensus praos \
--ledger-set next
In order to make it work you’ll have to set POOLID and you may have other filenames or paths.
Thanks, that’s very helpful!
FWIW - I just used the following sequence of commands to build the libsodium library on Linux:
$ ./autogen.sh
$ ./configure
$ make
as super user:
$ make install
