Advantages of Random Beacon (Threshold signature) over block hash

Problems with using the block hash

Block hash (called ID() in our code base) can be biased by a consensus node. It is possible for consensus nodes to loop over possible blocks and choose one with a block ID with the random outputs they prefer. The protocol has a safer entropy source which is the random beacon, that is unpredictable and unbiasable (based on BLS threshold signatures). The plan is to wire its output to Cadence to export a safe randomness.

Details:

• Conceptually, consensus nodes construct the block, they have influence on which transactions go in the block and potentially can know what transactions are in the block.
• A consensus node first constructs the block locally, before broadcasting it. Lets say we have a single malicious consensus nodes, and lets call it Eve. Eve can locally construct 1000 different variants of a block (e.g. by just varying what it includes and what not ... typically there is combinatorially a very large degree of freedom).
  • Given a block, the calculation to get the random number generator seed for each transaction is fully deterministic, and the algorithm is open source. Meaning, Eve can locally calculate the random seed for each transaction.
  • This is essentially like hash-grinding (or proof of work 😉 ). It takes a lot of computation, Eve is frequently unsuccessful, but with a small but non-zero probability she can post-select blocks where the random seed for one particular transaction is favourable.
• Lets say you are a web-3 casino. Typically, your margins are razor thin. You loose with probability 49% and win with 51%. It might be that somebody walks out of your casino with a million dollar. But that is an outlier, statistics is on your side. Averaged over many games and many people, you will statistically earn more money than you loose ... as long as your source of entropy is unbiased.
  • Now Eve walks into your casino. 😅 She has enough money to play many games. Some games she looses. She mainly submits gambling transactions around the time it is her turn to propose a block. And when it is her turn to propose, she publishes that block (out of the many she builds internally) that seeds the random number generator for her transaction favourably. Hence, Eve is able to bias the probability of winning slightly ... just enough so the odds of winning are higher for her than your Casino. Slowly but surely, she will bleed your casino of all funds. 💀

The underlying insight is: Any data object that a single node constructs and where the node has any influence how the byte representation looks as a bad source of entropy. The message creator can always construct multiple variants and only release favourable ones.

Flow is one of the very few networks that has a unpredictable and relatively unbiasable source of entropy, aka our Random Beacon.

summary of problems using hash as entropy source:

• Here, Eve constructs the block and can thereby "grind" the hash. You are right that the probability for eve to be successful might not be small here, if she has very very large computing resources available.

• Though, what I was trying to illustrate:

  Even if Eve's success probability to post-select favourable seed is relatively small, it can still make a materially large difference.

Threshold signature (aka random beacon) as entropy source

Section 4.3.4 in our paper [link] describes the random beacon, which is conceptually very different than the block hash:

1. As the following figure illustrates, the source of randomness generated by the random beacon is not part of the block, it is a threshold signature over the block

   

   So if Eve is constructing block A, she has to publish it first. Meaning at the time of block construction, the source of randomness is unknown (first difference to block hash).