A Method for Generating Random Numbers in Blockchain Smart Contracts

[0001] The present application relates generally to a blockchain system, and in particular to a method for generating random numbers in blockchain smart contracts.

[0002] The environment in which we live is full of randomness. The concepts of luck, probability, and fate have always been closely linked to randomness. Everything that humans cannot understand or predict is often classified as random. Physiologically, we are also immersed in an ocean of randomness. From the movement of clouds to the behavior of particles and waves, randomness is ubiquitous.

[0003] However, although humans are exposed to a variety of random things and are familiar with randomness, it is still difficult to translate it into something that computers can use. When we talk about randomness in computer systems, we really mean pseudo-randomness, that is, to simulate as much as possible the randomness of the real world, making it almost “real randomness.”

[0004] Random numbers play an important role in privacy technology and cryptography. The importance of random numbers is not only reflected in the establishment of secure communication channels, but also in the confirmation of communications. If multiple people attempt to communicate with each other through a channel of limited bandwidth, a random number can be utilized to determine the reasonable order in which the channel carries the messages.

[0005] A blockchain is a successful use case in which multiple parties try to reach consensus on a certain update of a global perspective. Updates are usually completed in one round, that is, within a periodic discrete time interval.

[0006] On a single node, some physical characteristics can be used to generate random numbers, such as electronic thermal motion, or a user's arbitrary mouse movements. However, in blockchain smart contracts sandbox, it is not easy to obtain a unique random number that cannot be anticipated, calculated, or determined. The main reason is that the sandbox application is isolated from the outside, and can only access the data inside the sandbox or in the blockchain, but cannot see data in the physical machine or outside world. Although the transaction data on the chain has a certain randomness when many users access the blockchain in same period and while it is hard to forecast the human behavior, this is not always the case, especially during low load periods. Also as every user of a blockchain can view the data stored in the blockchain, even data marked as private in a smart contract, is still viewable by external applications.

[0007] When a formula to generate the random number disclosed, anyone can use the same data with same formula to surmise the random number, therefore it can no longer be random. Lottery games that use random numbers must ensure that the random number source is never manipulated, because even a slight deviation will completely change the winning result. Since the winners can receive substantial instant rewards, the impact of tampering with the lottery results is substantial as well. We must also ensure that the generation of random numbers cannot be controlled by the participating nodes of any blockchain. Therefore, the use of a single source random number seed in a blockchain contract is not credible because no one can guarantee that the party providing the random number seed has not generated a random number by falsifying the result.

[0008] Effective and fair random numbers in smart contracts are the basis of many blockchain-based services, such as data encryption, online gaming, and gambling. In order to achieve non-domination, the randomness protocol needs to ensure the following two aspects:

[0009] i) random functions always generate some random numbers; and

[0010] ii) random numbers generated by random functions are not manipulated.

[0011] Known blockchain random number generation methods include Block hash, Bitcoin beacon and Oraclize.

[0012] In block hash, a hash of a block or transaction is used as a random source. Since the hash is deterministic, everyone will get the same result. Once added to the blockchain, a block may remain there forever, so every user can verify the correctness of the generated numbers. Consider an example of a lottery service using this method. Players first purchase tickets by placing their number before a certain time, for example, 7:00 PM every night. After 7:00 PM, the ticket-purchasing phase is closed and the agreement moves to the next stage, which is to determine the winning ticket number. This ticket is calculated based on the hash of the first block accessible to everyone on the Bitcoin blockchain after 8:00 PM. We can see that at 7:00 PM, no one can predict the hash of the block at 8:00 PM, which makes the service look reasonable.

[0013] However, this hash could be manipulated by the miners of the guardian blockchain. When the lottery reward is small, the miner has little incentive to tamper with the block, but as long as the amount is greater than the block reward plus the transaction fee, the miner may begin to influence the block hash to generate the number they want. Therefore, this method is not secure for applications based on high-interval randomness. This approach is also inappropriate for scenarios that require instant generation of random numbers to decide whether to end the game.

[0014] In Bitcoin beacon, the Bitcoin blockchain is used to generate random numbers. Timestamps and transactions in Bitcoin contain a sustainable source of high entropy. Entropy measures the “chaos” of random sources. The more “chaos” the source has,—i.e., the higher the entropy, the harder it is to predict the number generated. In addition, the SHA256 hash function and the Proof-of-Work (PoW) algorithm are used to determine the random function. PoW is computationally intensive and non-deterministic, leading to unpredictability of random number generator (RNG) results. This approach suffers from the same problem as the aforementioned approach because it does not properly address the risk of an attack, in which miners, perhaps economically-motivated, deliberately discard blocks they do not like. In the blockchain, the miners help protect the blockchain by running a proof-of-work algorithm and probabilistically receive rewards in the form of Bitcoins. Therefore, any attack on a random beacon will attack the Bitcoin itself. Therefore, this method can only be guaranteed within a specific range of monetary costs. In the case of a lottery, where the reward is large, the miner can be bribed to ignore the specific block, thereby impairing randomness. Another problem is that ordinary people (non-miners) cannot participate in the generation of these random numbers, which means that this is not a suitably fair solution.

[0015] Oraclize is a data provider that provides data for smart contracts and blockchain applications. Many real-world situations require data to be obtained from outside the blockchain, but the nature of smart contracts does not help solve this problem. Oraclize can help achieve this goal. As an intermediary, Oraclize collects data from external sources (such as Wolfram Alpha, IPFS, etc.) and then passes the data to the required application. Regarding random numbers, Oraclize extracts data from random.org into the blockchain. At the heart of the solution is a centralized data service. It believes that through the so-called authenticity proof, everyone can verify that the extracted numbers are real and have not been tampered with. Obviously, in this model, people not only trust Oraclize, but also trust the data provider, for example, random.org in the aforementioned case. However, relying on trusted parties contradicts one of the core principles behind blockchain technology, as centralized services can be destroyed at any time. This makes Oraclize inefficient for applications that require high security and have no trust between the parties on the blockchain.

[0016] Accordingly, there is a need for improved methods to mitigate the problems of the aforementioned methods while achieving verifiable and non-tamperable random number generation.

[0017] In one embodiment, the present invention provides a method for generating fair and effective random numbers for smart contracts, which can effectively avoid the problems of the aforementioned methods while achieving verifiable and non-tamperable random number generation.

[0018] In accordance with one embodiment of the present invention, there is provided, a method for generating random numbers for a smart contract on a blockchain among a plurality of users. The method includes: having each user generate a random seed locally; having each user generate a signature by signing the random seed with a private key having a corresponding public key; having each user submit the signature to the smart contract separately; verifying, using the smart contract, the signature of each user, with the corresponding public key of each user; storing the signature to a current block of the blockchain via the smart contract; having each user wait at least a predefined period and then submit the random seed generated by each user; verifying via the smart contract, each the random seed submitted by each user, by ensuring a match with the corresponding signature; and after all the random seeds from each user are received, calculating via the smart contract, a random number with a seed obtained from the seeds of each user and a hash of the current block. When getting the hash of the current block, all of the seeds have been already generated so that it is not possible to manipulate the seeds or block content anymore, thereby preventing miners from changing the current block.

[0022] As noted above, the present invention proposes a method for generating fair and effective random numbers for smart contracts, which can effectively avoid the problems of the aforementioned methods while achieving verifiable and non-tamperable random number generation.

[0023] A description of various embodiments of the present invention is provided below. In this disclosure, the use of the word “a” or “an” when used herein in conjunction with the term “comprising” may mean “one”, but it is also consistent with the meaning of “one or more”, “at least one” and “one or more than one.” Any element expressed in the singular form also encompasses its plural form. Any element expressed in the plural form also encompasses its singular form. The term “plurality” as used herein means more than one, for example, two or more, three or more, four or more, and the like. Directional terms such as “top”, “bottom”, “upwards”, “downwards”, “vertically” and “laterally” are used for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment.

[0024] The terms “comprising”, “having”, “including”, and “containing”, and grammatical variations thereof, are inclusive or open-ended and do not exclude additional, un-recited elements and/or method steps. The term “consisting essentially of” when used herein in connection with a composition, use or method, denotes that additional elements, method steps or both additional elements and method steps may be present, but that these additions do not materially affect the manner in which the recited composition, method, or use functions. The term “consisting of” when used herein in connection with a composition, use, or method, excludes the presence of additional elements and/or method steps.

[0025] A “blockchain” is a tamper-evident, shared digital ledger that records transactions in a public or private peer-to-peer network of computing devices. The ledger is maintained as a growing sequential chain of cryptographic hash-linked blocks.

[0026] A “node” is a device on a blockchain network. The device is typically be a computer having a processor interconnected to a processor readable medium including memory, having processor readable instructions thereon.

[0027] In addition, the terms “first”, “second”, “third” and the like are used for descriptive purposes only and cannot be interpreted as indicating or implying relative importance.

[0028] In the description of the invention, it should also be noted that the terms “mounted”, “linked” and “connected” should be interpreted in a broad sense unless explicitly defined and limited otherwise. For example, it could be fixed connection, or assembled connection, or integrally connected; either hard-wired or soft-wired; it may be directly connected or indirectly connected through an intermediary. For technical professionals, the specific meanings of the above terms in the invention may be understood in context.

[0029] In the drawings illustrating embodiments of the present invention, the same or similar reference labels correspond to the same or similar parts. In the description of the invention, it should be noted that the meaning of “a plurality of” means two or more unless otherwise specified; The directions or positions of the terms “up”, “down”, “left”, “right”, “inside”, “outside”, “front end”, “back end”, “head”, “tail”, the orientation or positional relationship shown in the drawings is merely for the convenience of describing the invention and simplifying the description rather than indicating or implying that the indicated device or element must have a particular orientation and be constructed and operated in a particular orientation, and therefore cannot be used as a limitation of the invention.

[0030] The concept behind the exemplary method embodies the principles that “miners are not trustworthy” and the number of miners in the blockchain is limited. With sufficient motivation, miners can reach a consensus to manipulate the block. Therefore, the goal is to create a verifiable fair RNG (random number generator). Under this condition, as long as at least one of the parties to the smart contract is credible and the person does not misuse the confidential information, a trusted blockchain random number can be generated. After the last disclosure of the random number, we can also use the verification signature submitted by the parties to confirm that the random number calculation process is credible.

[0031] In accordance with an aspect of the present invention, suppose the random generation contract has N participant users, the whole process may be defined using the following steps:

[0032] Each user generates a random seed locally, and signs this random seed with their local private key.

[0033] Each user submits the signature to the RNG smart contract separately.

[0034] The contract verifies the signature submitted with user's public key, ensuring it is generated by the correct user. Then the contract stores the signatures to the block.

[0035] Each user waits at least one block period and submits the random seed. This is to make sure the random seed will not appear in same block as its signature.

[0036] The contract will verify the random seed submitted, ensuring it is matches the signature.

[0037] After all the random seeds are received, the contract calculates the random number with Seed (USER A, USER B . . . . USER N) and the Block Hash of current block. As when getting the hash code of current block, all random number seeds have been already generated thus it is not possible to manipulate the random number seeds or block content anymore. This could prevent miners from changing the block in the blockchain.

[0038] An exemplary set of steps in one embodiment is described with reference to FIG. 1 below.

[0039] In STEP 101: BANKER notifies the smart contract to start a new round of random number generation.

[0040] In STEP 102: USER A gets the current Block ID from contract.

[0041] In STEP 103: USER A generates a local random seed by local software or hardware devices.

[0042] In STEP 104: USER A signs the random seed and Block ID with USER A's private key. An encryption program such as Pretty Good Privacy (PGP) that uses one or more of: the random seed and an identifier of the current block (Block ID) as an input may be used so that for example: Signature=PGP (Random Seed, Block ID).

[0043] In STEP 105: USER A calls the RNG smart contract, and submits the signature to the smart contract.

[0044] In STEP 106: Smart contract verifies the signature with USER A's public key, and stores the signature to the chain's block.

[0045] In STEP 107: USER A waits a period of time greater than one block period. This is to ensure the signature storage is at least one block ahead of the random seed.

[0046] In STEP 108: USER A submits the random seed and Block ID it used to generate the signature to the RNG smart contract.

[0047] In STEP 109: Smart contract verifies the random seed, ensuring it matches the signature which was submitted previously.

[0048] In STEP 110: Smart contract calculates the temporary random number using the following formula: RAND(0)=HASH(RandomSeed (USER A)),

[0049] In STEP 111: USER N generates a local random seed by local software or hardware devices.

[0050] In STEP 112: USER N signs the random seed and Block ID with USER N's private key: Signature=PGP (Random Seed, Block ID).

[0051] In STEP 113: USER N call the RNG smart contract, and submits the signature to the smart contract.

[0052] In STEP 114: Smart contract verifies the signature with USER N's public key, and stores the signature to chain's block.

[0053] In STEP 115: USER N waits a period of time greater than one block period. This is to ensure the signature storage is at least one block ahead of random seed.

[0054] In STEP 116: USER N submits the random seed and Block ID it used to generate the signature to the RNG smart contract.

[0055] In STEP 117: the smart contract verifies the random seed, ensuring it matches the signature which was submitted previously. To prevent a package replication attack, we also need to verify the block ID, ensuring it is within 5 blocks from the current block.

[0056] In STEP 118: the smart contract calculates the temporary random number using following formula: RAND(N)=HASH(RAND (N−1) XOR RandomSeed (USER A)), in which RAND(N−1) is the temporary random number generated in the previous steps. If there are more users who need to submit random seeds, continue loop to STEP 111. In other embodiments Randomseed (USER N) may be used instead.

[0057] In STEP 119: if all participants have submitted their random seeds, the contract will get Hash value of the current block, and re-calculate the random number with following formula: RAND(N+1)=HASH(RAND(N) XOR BLOCKHASH), and discloses RAND(N+1) as the final result.

[0058] 1.1. Scenario 1: User Verification of the Blockchain Random Number Generation Process

[0059] Any user on the blockchain can obtain the random number seed and the signature contributed by each user in the RNG contract through the data on the blockchain. They can obtain the hash value of the last block. By using the formula, RAND(N+1) it can be calculated, and the random number calculated by the smart contract can be compared and verified.

[0060] FIG. 2 depicts USER A verifying the random number generated by RNG contract.

[0061] 1.2. Scenario 2: Preventing Miners from Jointly Tampering with Blockchain Records

[0062] A miner attempting to discard the random number seed block containing a user contribution will be discovered. As the user has submitted the random number seed signature in the previous block, the random number seed re-submitted by the user must be consistent with the last submitted signature to pass the verification. In addition, the random number of each step is calculated and saved in real time. If the final verification result is inconsistent with the calculation result of the random number seed at each step, it means that at least one or more users records may have been discarded or tampered with, and the malfeasance will be discovered in time.

[0063] 1.3. Scenario 3: Preventing a USER B from Submitting a Fake Random Number Seed by Replaying USER A's Request

[0064] When users submit their own random number seeds, they need to submit the signed result first, then submit the random number seed and the block ID after the signature is calculated. Our blockchain performance assumption is that smart contracts can perform all calculations within a six block cycle of the user's submission of information. Therefore, the difference between the current block ID obtained by the smart contract and the user-submitted random number seed generation block ID is required to be less than 6 blocks. If this value is exceeded, it means the user submitted a request a long time ago, and the request is likely to be a replay attack, therefore it is an invalid request.

[0065] 1.4. Scenario 4: Prevent a User from Finding a Random Number that Meets their Intentions by Accident

[0066] The last user who contributes a random number seed can theoretically obtain the seed and signature of all other users, and try to find the random number that meets their intentions by accident. After the last user has contributed his own random number, the smart contract will also grab the HASH value of the current block to participate in the random number operation. Since the user does not exit the block when calculating the random number (the user must submit the signature first and then submit the random number seed), the user cannot predict the hash value of the current block, and thus cannot find the desired random number seed by accident

[0067] The program was validated in accordance with a proposed blockchain betting game. This is an auction bidding game where everyone can bid in a round of games, with the restriction that each round must be greater than the previous round. The game ends after a random N rounds or N hours.

[0068] This game requires each user's bid to generate a real-time random number to determine whether the game can end. According to the existing blockchain random number rule, the random number of the lottery must be generated after all the user bets are completed or calculated using the block information following the current block. In light of this, the random number generated in advance may transpire without randomness. Therefore, in this game it will be difficult to generate random numbers that meet the requirements of the game.

[0069] This method can effectively generate random numbers that meet the requirements of the game rules. As the game starts, the initiator contributes a random number seed.

[0070] Each round of players bids according to the following rules: first, obtain the local random number seed, and then employ the user's private key to place the signature together with the current round of bidding. The client needs to call the contract twice, once to report the current round of bidding and signature. Then, after a delay of one block, the contract is again called to report the random number seed.

[0071] After obtaining the reported random number seed in the contract, contract verification is performed to ensure that the seed is generated by the user and paired with the offer.

[0072] The smart contract uses the formula RAND(N)=HASH(RAND(N−1) XOR BLOCKHASH) to calculate the random number of the current round, and to judge whether the random number meets the game-ending condition. If the current game-ending condition is met, the game ends and the winner is selected.

[0073] If the game-ending condition is not met, the game proceeds to step 2 for the next round of offers.

[0074] This Random Number Generator is ideal for use in secure bank transactions as it can help prevent 51% attacks. In this type of attack, a corrupt miner attempts to reverse transactions to realize a benefit, for example, the ability to spend the same cryptocurrency twice or to cast doubt on the integrity of the blockchain. In this RNG, after the random number seeds are received, the contract calculates the random number with Seed (USER A, USER B . . . USER N) and the block hash of the current block. It is not possible to manipulate the block content any longer as the random number seeds have already been generated nor is it possible to ask each participant to send the random number seed again. The seed is revealed after the transaction is completed thereby verifying that the transaction is correct. Attempts to modify the content will result in the failure of the transaction.

[0075] A standard defense against a 51% attack is to wait N blocks to release the object of the transaction. This RNG requires a waiting period of at least one block but no more than six blocks, thereby ensuring the integrity of the transaction. Blocks that do not demonstrate the requisite random number seed consistency will not pass verification causing the transaction to fail. Transactions that do not occur within the required time frame also fail. Block tampering can be assumed when the final verification result is inconsistent with the calculation result of the random number seed at each step. As blockchain democracy dictates that the longest blockchain is the correct blockchain, a malevolent actor would require unequalled hashing power to stay ahead of the legitimate blockchain.

[0076] Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.