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

Published in

aelf

7 min readMar 24, 2020

Commitment-Reveal Scheme: A reliable random number generation scheme

In a blockchain network, the smart contract code is open-source, so the on chain data is public and may potentially be manipulated, especially any blockchain with a POS consensus or dpos consensus. Even if no one uses the economic system design to attack the chain, it does not exclude that individual production nodes may profit by controlling the hash value of some blocks and other data on the chain.

To generate an unpredictable random number, the chain’s generating mechanism must involve many parties. That is to say, the applicant of a random number and the inherent data with random properties on the chain together will generate a random number. The easiest way to understand and implement this approach is with the Commitment Scheme. (BMS, founder of EOS, mentioned this scheme in a related response to random numbers).

We can consider the Commitment Scheme as a commit-reveal scheme. In this scheme, the random number generation process can be roughly divided into two steps, namely:

The two parties makes an open commitment (to a secret);
The two parties disclose their secrets, and they generate random numbers by some operation.

Among them, since both parties first disclose the commitment, then the commitment can be verified after the random number is generated. Moreover, before both parties disclose their secrets, neither party can know the other party’s secrets (otherwise, they can’t be called secrets), so the random number is also can’t be predicted by either party.

Assuming that the two parties are A and B respectively, the above process can be simply expressed as follows:

A generates a value secret_A locally and publishes a commitment hash (secret_A); B generates a value secret_B locally and publishes a commitment hash (secret_B);
A publishes secret_ A, B verifies that hash (secret_A) is consistent with the commitments previously published; B publishes secret_B, A verifies that hash (secret_B) is consistent with the commitments previously published;
If the verification is passed, the generated random number hash (secret_A, secret_B) is recognized by both parties.

Design of random number generation service interface

Since the generation of random numbers requires the participation of multiple parties, the random number generation service interface must reflect this interaction process. When designing the interface, we select random number applicants (users who can send transactions or a DApp) and random numbers contracts as participants in the blockchain scenario. In other words, random number applicants and random number contracts need to exchange commitments first, then reveal and verify each other’s secrets, and finally generate a random number based on the secrets of both parties.

On the one hand, random number applicants can directly publish their commitment by sending a transaction to generate a hash value. On the other hand, the random number contract code is open-source, if it is needed to generate a “secret”, it can only be achieved through other mechanisms (for example, the implementation of aedpos contract on random number interface), or by using Future data on the blockchain. Even though the future data of a blockchain has a certain probability of being manipulated, due to the fact that the random number applicant has a secret and open commitment, the unpredictability of the generated random number can still be guaranteed.

Based on this, the random number applicant (regarded as A) can generate a random number through two interactions with the random number contract:

A sends transactions to the random number contracts, that is, transfers the commitments;
After a while, A sends the transaction to the random number contract again, passing the secret used in the previous commitment, and receives the random number.

Of course, the premise that the random number can be trusted is that the random number contract used by A is open-source, and the commitment and secret disclosed by the random number contract are reliable.

Standard design of random number generation

Based on the above scenario, the common interface for generating random numbers can be described by Protobuf as follows:

‘RequestRandomNumber’ represents the transaction sent by the random number applicant, which is the first step in the random number generation process. According to the Commitment Scheme, random number applicants can pass the commitment as a parameter to the contract.

Random number contracts attach their own commitments after receiving random number generation applications from random number applicants. This commitment can be updated by the maintainer of random number contracts out of chains, or a secret can be directly generated by using other relatively random data on some chains. Finally, the order information ‘randomnumberorder’ for this random number application process is returned. The order information contains two messages: 1. The height that the random number can be obtained. 2. Hash value, or the unique identification order, which we call Token Hash. As for the generation logic of the Token Hash, it depends on the logic of the random number contract itself.

Finally, after the random number commitment height is reached, the random number applicant can send the second transaction ‘GetRandomNumber’. The transaction parameter should be the secret used by the previous reveal commitment. Random number contracts need to verify 2 hash values: ensuring the commit equals the hash (secret). After the verification is passed, the random number can be generated based on the secrets and used as the return result of the transaction ‘GetRandomNumber’.

Commitment Scheme Contract: Generate random numbers through cooperation

Next, we analyze a contract used by the test Commitment Scheme, which is located in the test folder of the aelf system repo.

The core data structures used throughout the contract are the two MappedStates, whose key values are the addresses of the applicants for the random numbers. The disadvantage is that applicants for random numbers can only apply for one random number at a time, using a hash value that contains the address of the random number applicant and the promises it provides as a key will break this restriction. Commitments are used to save the commitments provided by random number applicants. RequestSlots stores the Round information of random number applicants in the AEDPoS consensus. It is obvious that the promises and secrets provided by random number contract parties are directly based on the AEDPoS consensus and maintained by a random production node.

The following analyzes why a production node has the ability to (continuously) produce commitments and secrets.

In AEDPoS，block production is conducted in Rounds，and each production node occupies a time slot in random order in each round. However, the determination of the time slot sequence is applied through the commitment scheme:

When the first round of block production is started for each production node, the order is determined according to the configuration file or the vote ranking of each production node. Each production node randomly generates a hash value, which is called in_value_1. The hash value is kept secret, and the production node announces the hash value (in_value_1) in the first round production block, which is called out_value_1. The second round of sorting is based on the out_value_1 of each production node. In the second round of block production, it is also necessary to verify each production node in the first round: Whether out_value_1 of each (other) production node is equal to hash (in_value_1)，If not, the new round of blocks of this node will be automatically rejected. At the same time, each production node needs to generate an in_value_2 locally in the second round, and publish a hash(in_value_2)，i.e. out_value_2，which is to be verified in the third round.

In a word, the Round information of AEDPoS actually includes the process of commitment and secret generated by the contractor in the Commitment Scheme.

Therefore, when the commitment scheme contract applies random numbers to the random number applicants, the relative position of the block in the round information is recorded immediately: what round, what time slot.

When each random number order is recorded with the time slot location of its block, it is equivalent to the random number order being bound with an in_value to be disclosed in AEDPoS. For example, the Commitment Scheme contract selects the in_value published in the next time slot of the record block, and the out_value published in the last round, as the secret and commitment provided by the random number contract party.