consensus/NetRNGs.md

Network randomness schemes

These are our reviews of collaborative random number generators (RNGs) or other networked randomness schemes

Collaborative PRNGs

There are several true collaborative PRNG schemes in which all participants obtain the same output and can then run arbitrary randomised algorithms with identical seeds and results. As a result, we can employ more randomised algorithms that produce exact outputs like permutations of nodes, or require more complexity or tweaking.

Verifiable Delay Functions (VDFs)

VDFs employ a slow non-parallelizable computation and provide a PRNG with a proof that some time period elapsed between when seeds were available and when the output was available. Right now, the best ideas for this want a group of unknown order, like maybe the class group of an imaginary quadratic number field. https://crypto.stanford.edu/~dabo/pubs/papers/VDFsurvey.pdf

Justin Drake with Etherium research is very interested in VDFs because VDFs provide a collaborative PRNG in which one honest party suffices to produce a secure random number. We currently fear that VDFs deployment strategies have an excessively small security margin. An attacker might for example compute the VDF 10x faster to gains the random number early or even bias it. ASICS might be achieve this. At the extreme, superconducting computing can achieve speeds of 100 GHz with circuits consisting of 10^5 Josephson junctions. You’d need a rather large time window to use a VDFs, and you’d need an even larger time window to handle the highly optimised VDF node equivocating.

DFinity style VSS + VRF

We might not fully understand the VRF's roll here because the public key correctness ultimately depends on the VSS based DKG and this depends upon validator nodes raising accusations. We believe they do this so that one DKG yields numerous VRF outputs, maybe because the DKG is considerably more expensive, or not amenable to some optimisations.

Almost all the pure cryptography implementation work consists of following the DKG design in Secure Distributed Key Generation for Discrete-Log Based Cryptosystems by Rosario Gennaro, Stanisl􏱑aw Jarecki, Hugo Krawczyk, and Tal Rabin.

There is no actual production of a BLS signature produced there however, so one should also look over section 7 of DFINITY Technology Overview Series Consensus System (Rev. 1) by Timo Hanke, Mahnush Movahedi and Dominic Williams.

Schoenmakers PVSS ala EPFL

"A publicly verifiable secret sharing (PVSS) scheme is a verifiable secret sharing scheme with the property that the validity of the shares distributed by the dealer can be verified by any party; hence verification is not limited to the respective participants receiving the shares."

An implementation would follow A Simple Publicly Verifiable Secret Sharing Scheme and its Application to Electronic Voting by Berry Schoenmakers,
as well as the DEDIS group at EPFL's Kyber suite written in Go: https://github.com/dedis/kyber/tree/master/share

As written, the resulting secret is a random curve point, not a BLS signature or private scalar. In comparison, DFinity's VSS + VRF scheme produces a BLS signature, or even shared private scalar. If the message is known in advance, then PVSS could seemingly produce a BLS signature, although I need to think more about the timing of protocol messages in doing so. If correct, this would answer an important open question of DFinity's Timo Hanke, but maybe not the answer he wants, as PVSS probably need to be run for every signature produced.

Schoenmakers' PVSS avoids pairings but incorporates two rounds of DLEQ proofs. These are complex operations, but might prove faster than DFinity's VSS + VRF scheme, due to pairing based curve. Also, ee need to verify that a type III pairing does not make the protocol insecure and worry if components like the DLEQ proofs need to change for my proposed PVSS + VCF variant. We must also consider if any attacks can influence the public key.

Specific random results

There are various schemes that produce specific random results without actually producing a shared random value, but the result are necessarily inexact and may need to be simpler or complicate the consensus process.

These are mostly applications of verifiable random functions (VRFs), which normally consist of applying a random oracle to the output of a deterministic signature scheme applied to a shared value.

Competitive VRFs

It's hard to apply VRFs competitively because attackers may delay revealing their results, pretend not to see other's results, use network flood attacks on winners, etc., so roughly the same problems as simple commit and reveal.

Ouroboros style "slot filling" VRFs

We avoid the competitive VRFs issues by using VRFs to fill slots far more numerous than actual winning positions, say slots for block production. There remain related issues with timing and when block producers may skip earlier ones, which require more thought, and may impact other things.

Security proofs exist, but tricky UC ones.

See Ouroboros paper #2 TODO: link

Alistair's VRF leveraging random block selection

If we have a network randomness scheme picking block producers or many another specific random results, then they could include a VRF of the previous block. As above, each node's only options are to produce a block or not produce a block, so whatever alternatives nodes they have who could produce a block give them influence over the random number, but another user might produce a block first scooping them.

Although not a collaborative PRNG per se, this produces random numbers we might argue can be used like collaboratively produced ones. Alistair says we cannot wait for finalisation here, but disagreement results from multiple chains running in parallel.

Algorand

Algorand has similarities to Tindermint, but selects validators randomly from a pool, instead of using a fixed set, and does a Byzantine agreement for each block. All nodes produce possible blocks and a VRFs helps choose among them.

RANDAO

Nodes commit to a hash onion and use the layers like a local VRF, revealing one layer whenever doing so allows them to produce a block. RANDAO is less outright computation than local VRFs for verifiers. Also VRFs on different seeds do not aggregate well. RANDAO requires verifiers verify update records for all other verifiers though, which sounds more fragile than a VRF, meaning more sensitive code. RANDAO producers may take a performance hit from storing intermediate hashes, but if so Merkle trees give another similar option.

We think orphan blocks prevents us from slashing nodes for skipping their turn, so either all nodes must have a RANDAO contribution for each slot, or else nodes can increases their control over their revealed values by skipping blocks.

https://ethresear.ch/t/rng-exploitability-analysis-assuming-pure-randao-based-main-chain/1825/4 https://ethresear.ch/t/randao-beacon-exploitability-analysis-round-2/1980 https://ethresear.ch/t/making-the-randao-less-influenceable-using-a-random-1-bit-clock/2566

Network randomness uses

Validator group assignments

We think local VRFs, either competitive or slot filling, do not produce an even enough distribution and do not permit us to allocate stake well across validators. So we want a real collaborative PRNGs here.

Relevant questions:

• Can we produce a security proof for Alistair's VRF leveraging?
• How does Ouroboros handle similar situations?
• Why does DFinity want a VRF so bad?
• Are the issues with using PVSS?
• Is PVSS + VRF better?

Finality gadget leader assignments

Alistair thinks rotation solves everything currently.
An alternative is Algorand's local VRF.

Block production leader assignments

Etherium and Ouroboros handle this with RANDAO and their "slot filling" VRF, respectively. We think Ouroboros's VRF has significant implementation advantages, but we may reevaluate after we take performance more into consideration.

Fishermen incentivization

We envision creating a small about of random missbehavior so that fishermen always have some missbehavior to catch. We should do this with local VRFs so that nobody except the missbehaving node knows in advance, but the levels should be low enough that such missbehavior cannot accumulate.

Are there other fishermen related uses? Rob mentioned ordering fishermen, which sounds problematic.

Timing

TODO: Comment on relative block time vs. more absolute synced clock times.

RANDAO

We noticed possible timing issues with RANDAO that impact most other schemes: An attacker can manipulate the timing of their blocks to help maintain a forked chain. TODO: Add details.

Ouroboros rate metering

Ouroboros paper 3 describes minimum rate requirement for protection against long term attacks. The idea goes that a long-term attacker starts with relatively little stake, so initially they produce blocks slower than the overall network, but as their stake increases this rate goes up. Ouroboros wants to prevent this initial slow start, but this requires