aelf Tech Talks — aelf’s Verifiable Random Number Generation Standard Pt 2

aelf Developer

Published in

aelf

4 min readMar 31, 2020

Read pt 1 here.

AEDPoS contract: Production nodes participate in generating random numbers

The AEDPoS contract also provides a random number generation standard. The implementation of the scheme is slightly different from the Commitment Scheme.

Random number providers do not need to provide a commitment and a secret, they will only need to consider the uniqueness of the hash value for each transaction. The hash value of the ‘RequestRandomNumber’ transaction sent by the random number requester can be directly used as the secret that the random number provider does not need to verify.

However, the random number provided by the random number contract (i.e. AEDPoS contract) becomes extremely strict:

Each random number application order will be directly bound to the out_value of (2/3+1) production nodes and the in_value of the same number of production nodes in the next round. Due to the uncertainty of the next round order, it is also uncertain which production nodes will participate in the generation of random numbers. In other words, in the random number contract party, there will be (2/3+1) production nodes participating in generating secrets, and the production nodes involved are uncertain. This greatly increases the difficulty of cheating in the process of random number generation: it needs more than two-thirds of production nodes to collude.

In this process, a ‘RandomNumberRequestHandler’ is used to process random number requests.

When receiving a random number application, you need to check the time slot of the current AEDPoS consensus:

If the block nodes of this round is not more than one third, the round can generate random numbers, return to a height higher than the height when the current round is executed to two thirds plus one time slot.
Otherwise, the random number needs to be generated in the next round.

Another class, RandomNumberProvider, is used to return a previously applied random number: as mentioned above, the “secret” of the random number contract party will be generated, based on the “secret” of the (2/3+1) production nodes to ensure the number is as random as much as possible.

The AEDPoS contract directly uses the above two classes for the implementation of ACS6.

Provide a random number at each height

Although the above logic process is rigorous and can ensure the quality of producing a random number, it is a pity that the actual process is too complex.

In order to make it easier for developers to use, the AEDPOS contract only uses consensus information and provides a way to get random numbers: GetRandomHash.

In the consensus system contract for each block, a random number is generated using the following code:

State.RandomHashes[Context.CurrentHeight] = randomHash;

Using the latest signature, the random number generated from the same height is calculated to get a new random number.

The ‘signature’ is the signature described in the consensus module of the aelf whitepaper. It is obtained directly from the Round information here to use a series of in value calculation results.