How to Check if your VRF skey is properly registered to the Ledger

Hi folks,

Some people were interested in figuring out how to check whether or not your VRF signing (private) key was the correct VRF key registered onto the blockchain.

A problem with using the wrong VRF signing key on your producer node would result in not correctly computing the VRF output needed to determine slot leadership, so you would end up missing slots without knowing. Having a misconfigured VRF signing key shouldn’t be a problem if you only generate one VRF pair and don’t intend on making another pair (there isn’t really a reason to).

To check if your vrf.skey is registered to the ledger:

  1. Derive the public verification key (vkey) from the private signing key (skey). This doesn’t need to be done if you didn’t lose your original vrf.vkey. This could also be a useful exercise to verify that your current vkey is truly the vkey paired to the skey:
  • cardano-cli shelley key verification-key --signing-key-file vrf.skey --verification-key-file vrf.vkey
  1. Download the ledger state from blockchain:
  • cardano-cli shelley query ledger-state --mainnet --out-file ledger-state.json
  1. Search for your pool’s node ID to find the registered VRF metadata.
  • Example, my pool node ID is 593dfbc66c5b8dfc040851a2f4d87191490d4c2312c65dd4418f7b23
  • After searching the ledger, I find the VRF entry in your pool’s metadata. Mine looked like:
  • “vrf”: “6f3a4457f9a09b0e918c33d065695dafe25f970538de0cb589a65c5027b05c70”,
  1. The VRF value registered in the ledger is the key-hash of the VRF vkey. You need to compute the key-hash of your vkey and see if it matches the value registered to your pool on the ledger:
  • cardano-cli shelley node key-hash-VRF --verification-key-file vrf.vkey --out-file vkeyhash.out

The output file, vkeyhash.out, should match the VRF value that appeared on the ledger in order for your vrf.skey to be correct. If it is not, then you are using the wrong vrf.skey.

A note on changing VRF keys and registering a new pair. Remember that newly registered pool information takes effect 3-epochs from the time you changed your pool information. So, don’t throw away your old VRF pair, since they are still needed for the current and next 2 epochs before it transitions to the new pair.

8 Likes

@BEAVR it sounds from what you are saying that the block producer node will still need to refer to the old VRF key even though the pool registration has specified a new VRF key.

So how and when would the new key be specified to cardano-node while it is still using the old one? There’s only one --shelley-vrf-key option that I know of and it would only take a single vrf.skey file. How would it, and how would we, transition from one to the other?

I ask because, although we have no plans to change our VRF key, the same rules and procedures should also apply to KES keys and we are coming up to our KES expiry time.

@COSDpool
First, VRF key pairs and KES key pairs are not the same in how they are registered to the blockchain. Only the VRF vkey gets published onto the ledger when you register your pool:

  • cardano-cli shelley stake-pool registration-certificate
    –cold-verification-key-file cold.vkey
    –vrf-verification-key-file vrf.vkey
    –pool-pledge
    –pool-cost
    –pool-margin
    –pool-reward-account-verification-key-file stake.vkey
    –pool-owner-stake-verification-key-file stake.vkey
    –mainnet
    –pool-relay-ipv4
    –pool-relay-port
    –metadata-url https://git.io/JJWdJ
    –metadata-hash
    –out-file pool-registration.cert

The ledger knows when you’ve made changes to your registration, so your changes will take effect 3 epochs from the current epoch you made the change in.

KES is different because you only apply that to the node certificate, which is not registered to the blockchain. So the effect of changing your KES key pair is in effect immediately.

1 Like

thanks, I had a fake memory of submitting both KES & VRF public keys at registration time… that must have come from setting up the cardano-node command which itself has to point to both those private keys.

Which leads to the related question: if we change our VRF key:

  • In what manner would we run the cardano-node command so it is aware of the old key (which it must continue to use) and the new key (to which it will transition at the next boundary?
  • Or are we expected to restart cardano-node ourself precisely at the relevant epoch boundary, pointing to the new key?

And please, how on earth did you identify this issue? I’m impressed but still curious if uncommon issues like this are documented anywhere. It seems like the kind of thing pool operators would run into only by accident: in this case, only finding out upon investigating why they were unable to produce the blocks they were elected for… :cry:

Answers inline

  • In what manner would we run the cardano-node command so it is aware of the old key (which it must continue to use) and the new key (to which it will transition at the next boundary?
    I can only theoretically say how this will work, so don’t take my word for it. The VRF pair should not need to be regenerated. To ensure you don’t have any downtime in your producer node, you could run two BPs, one with the old VRF skey, and one with the new VRF skey. There is no risk of forking the chain since only one VRF will be during an epoch. Once the network has transitioned to the epoch where the old VRF pair is no longer needed, then you can close the second producer node.

  • Or are we expected to restart cardano-node ourself precisely at the relevant epoch boundary, pointing to the new key?
    See answer above. You don’t need to. You can theoretically run two producer nodes with two different VRFs at the same time.

  • And please, how on earth did you identify this issue?
    There were folks that accidentally generated and registered a new VRF pair as part of the steps when they were rotating their KES keys, so some folks were wondering why they weren’t minting blocks.

I found these verification steps because I was having extremely bad luck at the start of Shelley and was wondering if anything was wrong with my setup. I had checked the Leader logs from the producer and all was good, but was wondering if I had flubbed my VRF key pair. Turns out I didn’t, after verifying using the steps in the OP, and had just encountered really bad luck because I was able to mint in epochs after with the same setup.

2 Likes

That’s a brilliant workaround; I didn’t think of it. Also thanks for providing the rest of the problem history :sunglasses:

This is a key piece of information that I missed along the way and has caused more than a little head scratching. I was operating off of the premise that updates take place after two epochs.

1 Like

Yeah. The reason for that is to prevent stake pools from ramping the fee to 100% and trapping stakers in a snapshot, since rewards are distributed 2 epochs after a snapshot.

4 Likes

Thanks this was very helpful, I had multiple vrf.skey files, obviously got them mixed up and subsequently kept producing invalid blocks due to the mismatch between the registered vrf.vkey and vrf.skey used to run the node.
I managed to locate the correct vrf.skey and restart the node.
I swapped the vrf.skey within the same epoch to resolve the issue.