How is the slot leader actually determined

I read somewhere that the slot leader is determined locally by the block producer node. Is that true and if so, would that mean that there is a lottery on each BP node with a potentially conflicting outcome? When there are multiple BPs proposing a block for the same slot, how is it decided which one to take?

I was also wondering, whether it is known upfront when a BP is expected to do some work? If not every slot is equal, there would be good/bad times to do maintenance (i.e. take the node down for a little while).

In other words, for how long can a block producer go offline without forfeiting its chance to mint a block?

cheers
– thomas

1 Like

Hello,

I run a stake pool and through the command line I am able to see the block allocation for my pool at the start of the epoch.

Blocks are allocated per a lottery like you say, so each ada is a lottery ticket. If someones ada delegated to TBO is chosen to create a block, TBO creates it. Those future blocks are known from the start of the epoch. I always post TBO’s block allocation number (not date and times) into our telegram channel.

This is good because we know when we can perform updates etc. To the pool without missing a block

This video is good at explaining staking and how blocks are chosen

3 Likes

Thanks, could you perhaps share that CLI command? I still somehow doubt that the protocol relies on the good will of the SPO to keep the pool running if it’s known that there is zero chance for reward. IOW, all pools that don’t have one of their tickets drawn, could safely shut down (to save cost) until the next lottery. There must be some other motivation to stay online, which I’m likely not seeing.

2 Likes

I’m not the techy person behind our pool so I can give you the command line but I don’t know much else after that.

cd ~/git

./leaderLogs.py --pool-id pool id here --epoch 240 --vrf-skey $CNODE_HOME/priv/pool/TBO/vrf.skey -bft --sigma 0.0008755706338504188

If you put another pools ID it still shows your own slot allocation.

Yeah a pool could easily shut down for an epoch, turn on just before the snapshot to see if they have block allocation, if not then close down again. It wouldn’t do any harm at all.

However, you have to be sure the nodes and relays will start up without any issues each time. Also if you are running your pool off a cloud based server then you’re not achieving anything by turning it all off. Maybe people running hardware servers in their own homes or something, but the power consumption is so low, not sure it would really have any benefits.

I would say turning nodes and relays off when there is no block allocation is just unnecessary people hours with the small risk of problems when starting up again.

I’m a technical person and quite familiar with the process of spinning up servers in a matter of minutes (if not seconds) - we do this all the time in managed container environments. My question is not aiming so much at saving cost when there is no chance of winning, instead I’d like to understand the protocol and what it actually does. Ultimately, when there are indeed good/bad times for an SPO to do maintenance, I’d think most SPOs would like to know about that.

Do you perhaps have the link to that python script?

Is it perhaps this one

I think we have very quickly gone into an area I do not know. I hope someone comments who is able to answer these questions for you.

Thanks for your time and quick responses - much appreciated

1 Like

Do these metrics play a role in this?

# Access the Prometheus metrics
docker exec -it prod curl 127.0.0.1:12798/metrics | sort

cardano_node_metrics_Forge_forge_about_to_lead_int 21024
cardano_node_metrics_Forge_node_not_leader_int 21024
cardano_node_metrics_slotsMissedNum_int 86
  1. Typed Chronicles, every block producer pool roll a dice which has a probability based on their stake.
  2. Statistically, it can happen and the pool with lower leaderVRF (VRF output) value will win. It has a side effect: usually the pool with smaller stake would win (statistically) in a case when more than one leader is elected for a slot.
  3. Already answered.
1 Like

This is lovely, thanks

Great input, was looking for these, thanks!

From what I learned this is my assumption:

  • 1,5 days before epoch ends, the block producer of each pool goes through all slots within the epoch and calculates for each slot to see if his vrf is lower than his treshhold and if yes that pool is leader for that slot.

This means that if a pool is not online 1,5 days before epoch ends it 100% sure gets zero blocks assigned for next epoch.
This also means that it is the block producer node itself that does the vrf calculations

Right?

Remaining question:
When its time to make the assigned block how can the pool prove it was leader since the vrf is a random function and will be different every time. Does the pool somehow save some kind of proof in some local file?

@AndrewWestberg, if you have the time, please feel free to help with this since you definitely know the answer :slight_smile: thanks.

Uuuugh, I think you mixed up the current VRF implementation with the old MPC calculations, which has been completely replaced by the Algorand’s VRF (pseudorandom) function.

Forget, the old MPC. VRF is based on the all stakes (delegated, pledged which is also a delegation though) of the pools and nothing else (not really but you do not need to know the details).

Meaning, if a pool has some (active) stake (calculated in advance in the prev epochs) then it probably would be able to create a block in an epoch based on its active stake compared to the total stake.

You need to understand that VRF function I have linked above, though I created a simple pseudo code to understand, how it works:

final prover = Prover(has_sk, has_pk);
final verifier = Verifier(has_pk); // The other full-nodes including pools

final message = "The input to be hashed by VRF";
final message_hash = prover.hash(vrf_sk, message); // it always produces the same ouptput from the same inputs.
final message_proof = prover.prove(vrf_sk, message);   // over generating the proof that the message_hash is the correct ouput
 
// And VRF allows anybody to deterministically obtain the `message_hash` from the `message_proof`.
final message_hash = verifier.proof_to_hash(message_proof);

// i.e. prover.hash(vrf_sk, message) == verifier.proof_to_hash(prover.prove(vrf_sk, message))
// Also, message_proof allows a verifier to verify that `message_hash` is the correct hash of the input `message`.
// i.e. valid if:
if (message_hash == verifier.proof_to_hash(message_proof)) {
 return true;
} else { 
 return false;
}

The message is always generated for an epoch and every pool uses that message and the current slot number to generate the proof.

For example, the verification nodes will receive the block header (that contains almost all info for verification: the vrf public key, that message proof, and the slot number). Only data is missing is the creator’s stake distribution, what every nodes know.

So, based on these every individual nodes can verify whether the block is legit or not.

I suggest using cncli from GitHub - AndrewWestberg/cncli: A community-based cardano-node CLI tool

leaderlog command is explained in usage.md

For details you can also contact Andrew - he’s a nice guy. Maybe he already did a youtube video about it, did not watch all of his nerd outs.

Yes, this is actually already built into the nessus-cardano docker images.

1 Like

I’ve just found the nerd out for your question: NerdOut - Deep Dive: The Slot Lottery - YouTube

1 Like

This is great insight. Trying to put it to some interpretation. Please agree or disagree with the following:

  • Every node is calculating the slot assignment for all pools itself
  • With the input parameters of active stake snapshot and the pool vrf it comes to a predictable result
  • So every node comes to the same result
  • Calculation happens 1.5 days before epoch chance (if you are off your node will not know it has to produce a block)
  • Everyone is able to verify when you publish the block if it was assigned to you through public/private key approach

I did not listen to the video, but that’s my understanding.

  1. Only block producers calculating the slot assignment and for only themself for each slot.
  2. ok, but nonce is also required.
  3. Every BP pools comes to different results for each slot.
  4. No 1.5 day is only generate the next epoch’s nonce and every node can do it without any MPC.
  5. No, every one is able to verify that the published block for a slot is rightfully published by you by vrf vk attached to he block header, the slot nr, the vrf proof + vrf output (these two concatenate pd and called bheaderL) in the block header. But it requires that tje validator must know the creators active stake what every node know as vrf is assigned to BP pool.

The vrf output is (sorry: can be interpreted as) 256 bit long number and if you divide it with max number of that 256-bit field, you will get a percentage and if that is smaller then your active stake your block creation right is valid.

Hope makes sense.

Sorry typing in tablet.

2 Likes

Thanks a lot for your answers @_ilap very useful.

Regarding this point. Let me describe an example:
Imagine a bp node server is destroyed somehow and a 3 day old backup is restored. We are at 4,5 days within epoch as the backup is restored. so what happens now with the leader calculation? Does the node immediately start calculating the leaderlogs for all slots? Or will it never do the calculations since it should have already calculated it when the nonce was selected?