How to Implement Random Number Generation in a Blockchain
The blockchains with the smart contract (i.e. Ethereum, EOS) do not provide a random function. Due to the nature of the blockchain, the same results on any node is required in the validation of any transaction. In this post, we will explain the existing models in generating random numbers and we will show you how NBLab. suggests.
Using the state value of the block Approach
A block has several state values and main ones are listed below;
- Height of block: No. of created blocks
- Generation time: Time the block was created
- Block Hash: Unique value representing the previous block and the transactions included in the current Block.
Normally the block hash value with its unpredictability of the future is used in the random number generation from various state values. Depending on the configuration of the transaction involved, the block hash value will be different. Because you will not be able to know which transaction will be included in the future block, we can assume that it is a reasonable way to generate a random number
Disadvantage: Miner dependency
The block hash value will be the same on all nodes. However, the value is generated by a single node which also created the block originally. Since the only one node generates a block hash, there is a possibility that the configuration of the transaction in the block can be altered to meet his/her preference. And we call this possibility a miner dependency. Due to this dependency, there is a possibility that the random number can be biased.
Commit and Reveal Approach
The Commit and Reveal method is a method by which a preprocessed seed is selected by a random number requester. For an easier explanation, let’s consider the following game.
Guessing the Number Game
There are seven doors and the random numbers from 1 to 7 are written behind each door.
A person who participates in the game must choose a number between 1 and 7.
Then open the door to see the number behind.
If the number behind the door matches the number the person have chosen earlier, then the person earn the prize.
The concept of the Commit and Reveal method is similar to the game described above.
In this method, the unknown number behind the door is a hashed seed in the smart contract.
How to Generate Random Numbers
- A person who participates in the game must choose a number between 1 and 7.
- Then open the door to see the number behind.
- If the number behind the door matches the number the person have chosen earlier, then the person earn the prize.
- The random number requester selects one of the hashed seeds.
They provides another seed to the contract.
The smart contract generates a random number by combining these two seeds.
Manipulation by the contract creator
Because the contract creator is aware of the value of hashed seeds, there is a possibility that the creator will always play a winning game if he/she participates. In the example above, the person who creates the game knows the numbers behind the doors and hence always win.
Contract size issue
If more than one participates, you will need more hashed seeds. If the same hashed seed is selected by two requesters, one request must be cancelled. Therefore, with the increasing no. of requesters you have, the size of the contract increases to store hashed seeds. In our example above, the more users you have, the more doors you have to create to facilitate them. That is, as the number of users increases, the contract storage space must increase. Consequently this is a design with much less scalability.
The Signidice approach improves the issue of increasing the storage of the contract with the increasing requesters in the previous approach. In smart contracts, instead of storing the hashed seeds of each random numbers, the Public Key is released. The seed provided by the random number requester is signed by the private key corresponding to the public key. This signature information is used to generate random numbers. In short, a random number is generated by a combination of the seed provided by the random number requester and the private key hidden by the random number provider.
Contract size issues
It can also have a problem with the size. It is an algorithm that seems to have solved the size issue, but it may seem strange that the same problem still exists.
In the case of the commit and reveal method, a large size is required to provide the seed, but in the Siginidice, it is required to record the results of random number generation.
Why is the latter required?
It is because the same random number will be generated when the same seed is reused.
In addition, storing the data has a disadvantage of increasing the resources required to generate random numbers.
In the commit and reveal method, the requester simply selects the hashed seed, but in the case of Signidice, a time is required to check whether the provided seed has been used previously. Hence the time will increase with the increasing number of requesting seeds.
RNG proposed by NBLab
NBlab has devised a different method of generating a random number that satisfies both fairness and scalability by taking advantages of previous mentioned approaches. The only disadvantage that we know of in Signidice approach is that all the seeds are recorded in the contract. In order to solve this, we use the state value of a block. A request that combines the state value and a seed from a requester can be treated as a new request. There is no need to write the seed in the contract, every time it is requested.
In the end, NBLab’s new proposed algorithm was able to generate fair random numbers through the blockchain, and at the same time improves the scalability.
NBLab is launching an slot dApp on EOS with the proposed algorithm. The slot game will provide fair results and the scalability.
You can find more detailed description of our dApp in the next post NBLab’s EOSlot (available soon) and play at https://slot.nblab.io.
(Three Stars Slot is not available in some countries.)