Random beacons recorded on block are very useful in many aspects. For example, in order to achieve random but unpredictable id generation for each node, we use the random beacon in future blocks and requires the future random beacon to be verifiable, unpredictable and unbiasable.
Verifiable delay function (VDF) can be used to generate such random beacon, but we consider VDF as not production ready yet. The goal of this proposal is to purpose a production ready version of the random beacon that is as close to our requirements as possible.
We propose that each block header includes an 128 byte random beacon field, where the first 32 bytes are VRF output, and the rest 96 bytes are VRF proof. The VRF output in block X is produced by the proposer of block X using his key pair, and use the 32 byte VRF output in block X-1 as input. In such way, assuming the current block height is X, the VRF in block X+R is essentially unique (deterministic) given private keys of all block proposers between block X and X+R, but is unpredictable if any of these private keys are unknown.
In order for the block proposer at height X to bias the random beacon, he can choose not to produce block X and trigger view change and let the next valid proposer to produce block X. As a result, he will lose the mining reward in block X. This is different from the commonly known last revealer attack because even if the attacker decides not to produce block X, he cannot predict the random beacon in block X proposed by next proposer, unless the next proposer is his colluder. The probability that he has K options (the next K-1 valid proposers are also his colluders) decreases exponentially with K. This is not strictly unbiasable, but can be considered as good enough in some cases, e.g. to generate random id.
Note that the manipulation probability may not be trivial if some node will be the proposer of every round with significant higher probability (e.g. with significant staking in PoS, or significant computational power in traditional PoW). This is not a problem in NKN because each node has similar probability to propose a block, and each node has a unique key pair, so even if an attacker has a large amount of nodes, he has to know or predict exactly which node will propose which block, and the number of combinations grows exponentially with the number of nodes so it’s not feasible to consider all different combinations.
The VRF proof uses 64 bytes of random data when selecting nonce (but can also use hash of data and key pair together to ensure the uniqueness of nonce) to provide enough entropy in proof in case people want to use the VRF proof as another random number that is less secure but has more entropy.
Thanks to @insider for the discussion.