How is the slot leader actually determined

It does not matter. You can imagine it like you loose your BP node (pool) half of the current epoch and build a new one which will be only available in the middle of next epoch.

So, what does that new node do when you start it?:

  1. gather all the blocks from peers
  2. build the current ledger state and other states from these blocks only and nothing else.

Meaning, when your BP node is back it will continue creating blocks as if nothing has happened.
As It was able to regenerate the state of the chain from the received blocks and therefore the new epoch nonce from the received blocks from other peers. Ofc, assuming, KES, VRF keys are the same and/or valid.

2 Likes

In simple words: The current Shelley era of Cardano blockchain, which runs on Ouroboros Praos, DO NOT USE MPC (Multiparty Computing) at all.
It was implemented only in Byron era that used the original Ouroboros (Classic), which has been replaced by Praos in Shelley.

re 1) But one can calculate the leaderlog for some other pool if I have the vrf key and the pool id and the ledger state.

Yes, like everybody can access to all of your ADA if they have your private part of your master key as an example, amd the similar thing applies to the VRF private key.

1 Like

@_ilap,

So after the node is restored from backup it will get blocks from peers and create ledger state. Then it will run the leaderlogs to know which slots are assigned to the node? Is that correct?

And then I guess the node stores the leaderlogs somewhere locally, and use this file to know when it should make a block. Finally whenever the slot is up it will create the block, correct?

If all this is correct, how can one check if this process went well. for example what if getting the ledger state or doing the calculation fails. how can one check that? Thanks again :slight_smile:

Validation question on that.
I’m running a BP and a failover BP (which acutally runs as a Relay).

Looking it from the failover (which currently runs as a Relay)

  • 1.5 days before epoch end the calculation happens. Since this node is runnign as a relay it does not calculate slot assignmetns for itself
  • Then a failover happens and I get promoted to be the master (restarting as a BP)
  • Will i know which blocks are assigned to me? The DB of this node was always synced. But the node did not know that it may be running as a BP laterwards. Will it still be able to continue block production?

From what you described i would assume that this is the case because all of the results are stored in the ledgetstate and my restart would make me read it from the perspective of the BP of this pool.

You explained before that if a old DB is used for starting a node it’s not a problem because it is able to re-create the ledger state. But in my scenario the DB is up to date already, but it was a relay when nonce was generated, ledger-state was update and epoch was changed. Is that a problem?

The node doesn’t run “leaderlogs”. It calculates whether it is leader “right now in this slot” once per second. If the answer is yes, then it makes a block. The node doesn’t know the future. Only cncli knows the future. :sunglasses:

4 Likes

Thanks so much @AndrewWestberg.

To finalize we can conclude that the vrf result of a pool for each slot in the next epoch is deterministic (hence will always give the same value) when combined with the slot number and nonce. This explains why it doesn’t matter when you run leaderlogs after the nonce has been published and why the node itself will also get the same value when doing the actual calculation at the current slot. Hence the VRF lottery is random but deterministic after it is combined with the nonce. Correct?

It always will give different result due the different slot. Nonce and VRF private key is the same, the slot number always different for each slots in the epoch the node tries to determine is leader schedule, therefore the randomness will differ for the same key, same nonce, different slot number and therefore different provable hash.

In simple words. Only for the nodes or those who have the VRF private keys (e.g. leaderLogs.py with VRF private/signing key) are the leader schedules are deterministic, no other parties can predict the leader schedule for a slot in advance only after when it’s exposed in the block itself (validating the rightness of it).

3 Likes