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?:
gather all the blocks from peers
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.
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.
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.
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
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.
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).
I used all the information provided here and by Andrew’s video’s and feedback to write a low-tech blog explaining how the slot lottery works. Please feel free to correct what ever is incorrect in it!
Hi Andrew, the reason why cncli “knows the future” is because all information for the current epoch is available once the epoch nonce is known and the active stake snapshot has been taken, correct?
Say a pool enters in epoch ep + 1, then the distribution is defined by the state contained in the block sequence up to and including the last block in epoch ep − 1. (or the genesis block for the first two epochs). Furthermore, the epoch randomness for epoch ep + 1 (to refresh the lottery) is extracted from the previous randomness, and the seeds are defined by the first two-thirds of the blocks in epoch ep (for the first epoch, the randomness is defined by the genesis block).
So when the node calculates the VRF for the current slot, the inputs are ep -1 nonce, private VRF key which is tied to the pool certificae (?) and current slot number. Is that correct?
Not exactly. I was just referring to how we are able to find out the randomness used for leader logs “nonce” before the next epoch but only after 2/3 of the previous epoch has been “seeded”. To be honest this level of cryptography and mathematics I am not knowledgeable or capable to explain without making many mistakes.
