There are clear benefits to being able to generate a random number that is accepted within a blockchain network. There are several options available:

- A centralized party generates the random numbers. Random numbers are provided by a trusted third party (i.e. random.org).

-Commitment method (hash-commit-reveal method). As mentioned in the AElf whitepaper, the AElf mainchain consensus is used to determine both the in_value and out_value of each block to determine the production order. The block producer generates a random hash locally. After an in_value is set privately, the promise (ie out_value) is announced, where out_value = hash(in_value), and the random hash value in_value is published later at the appropriate time. Other nodes only need to verify out_value == hash(in_value). The in_value here can be thought of as a random number.

- Collect blockchain state information as a seed and generate a random number in the contract with a set algorithm. Should the algorithm become known (the code of the smart contract is public) and the correct seed obtained, the random number generated by this scheme can then be successfully predicted.

Obviously, from the perspective of decentralization, the Commitment method is the only usable solution from the above mentioned options. In this situation the main concern can be alleviated by ensuring the person making generating the random number does not secretly disclose it in advance, or use it to cheat.

However, unfortunately, in the blockchain system, this cannot be guaranteed: we cannot guarantee that the person who generates the random number will not use the information for ulterior motives, such as when the random number is used as a gamble. When the lottery is set, the producer of the random number can still suspend the disclosure of the random number even if the promise is made before the start of the game — this is equivalent to an opportunity to “play again” because if the node doesn’t disclose this random number, either the system will choose another random number from another node, or the gamble will be void.

What if stochastic number producers were prevented from choosing to stop the attack? There are a series of mature solutions, see Secret Sharing.

Example: Now there are five people A~E, each of whom has a public-private key pair. At this time, A generates a random number Random, which generates the corresponding commitment. At the same time, the random number Random is encrypted with the public keys of B, C, D and E to get four Sharing Parts. When encrypting Sharing Parts, it is guaranteed that only two people in B~E can recover Random and make Sharing Parts and Commitment public together. So even if A does not publish Random’s value for his own reasons, any two people in B~Eare capable of decrypting Sharing Parts received by themselves with their own private key, and compile two decrypted values (to be encrypted according to A). Random can then be restored. In case one or two Sharing Parts fail to recover Random, they can only assume that A decided to act maliciously from the very beginning — In this occurrence, according to the blockchain economic system, only A will be penalized. For example, the direct deduction of A’s application is referred to as the margin paid by a random number producer.

In addition, we can choose not to rely on the random number generated by an individual, but select multiple individuals’ random numbers to further calculate the hash value as the available random number in the application scenario. In this way, we can obtain random numbers within a blockchain system with more stability and security.