This is just a design draft that serves as a discussion starting point. All claims and designs are subject to updates/corrections

Protocol overview:

• Collectors commit to collections of transactions. • Hotstuff primary forms a block by including collections and reconstructing the threshold signature (Random Beacon signature)

• ENs receive the formed block, including the Random Beacon [RB] signature.

• ENs execute the block, using the RB signature as the source of randomness in all randomness calls in the block. The execution is split into verifiable chunk computation.

( Remark: after discussing with Dieter, the randomness might be all passed as a callback in Cadence, and will be called in the same order they appeared in transactions, at the end of the block. Some updates still need to be made to this solution to adapt to the callback, but the CSPRG idea should still apply. )

Cadence Feature and security requirements:

To provide an API in Cadence Random() uint64 that each transaction can call an arbitrary number of times (the number is not necessary known from a static analysis), satisfying the following security requirements:

1. The outputs are not distinguishable from an output of a random oracle
2. For each chunk of a block, all outputs are deterministic (verifiable) based on an initial "seed" relative to the chunk.
3. The user (transaction submitter) should not predict any bit of the Random() outputs, at the time they submit/commit to the transaction.
4. When transactions are being executed, the user should not be able to manipulate (bias) any bit of the output of the future calls to Random() (in the same transactions or in a subsequent ones) given any arbitrary number of past outputs.
5. Nodes should not predict any bit of the output, till a block is formed.
6. All nodes should not manipulate (bias) any bit of the random outputs, before a block is formed or during the block execution.