Random number asynchronous generation method and device

Abstract

The invention discloses a random number asynchronous generation method and device. In an initialization stage, a random number collection contract is deployed on a block chain and VDF algorithm parameters are initialized, and in a commitment collection stage, random number commitments submitted by all generator nodes are collected; the generator node calculates a random number commitment, and submits the random number commitment after commitment of a starting block height and before displaying of an ending block height; the technical problem that the method is not suitable for a scene with massive nodes is solved. The display collection stage is used for collecting the display submitted by each generator node for the random number commitment; in the result aggregation stage, the initiator node aggregates the result of the contract; the initiator node decrypts a result displayed by the block chain to obtain a random number plaintext, the block height difference between the block height submitted and displayed by each generator node and the block height after display is obtained, VDF aggregation calculation is carried out according to the random number plaintext of each generator node, the block height difference and the basic calculation times, and a final random number is aggregated. The technical problem that the aggregation result is easy to predict is solved.

Description

Technical Field

[0001] This application relates to the field of random number generation technology, and in particular to a method and apparatus for asynchronous random number generation. Background Technology

[0002] Distributed Random Number Generation (CR): A typical example is Randao, which is currently the mainstream approach for on-chain random number generation algorithms. Its basic idea is to divide the main process into a Commit phase and a Reveal phase. In the Commit phase, multiple nodes submit enough hashes within a specified time; in the Reveal phase, a seed is generated based on these hashes using a certain aggregation algorithm. To prevent nodes from maliciously failing to respond after committing, an economic model is needed. This approach leverages the irreversible nature of hashes, effectively preventing cheating behavior such as "betting on a single hash" and ensuring the unbiasedness of random number generation.

[0003] The on-chain random number generation algorithm based on distributed CR has a simple and reliable computation process, but it has the following problems: 1. The aggregation results are easily predictable: When the results are displayed and aggregated during the Reveal phase, the block-producing nodes of the chain or the executors of Reveal can calculate the results and selectively submit only the Reveal aggregation results that are favorable to their side, discarding the unfavorable Commit results.

[0004] 2. Unsuitable for scenarios with a massive number of nodes: The Commit and Reveal phases are strictly synchronized. The aggregation phase can only proceed after sufficient results have been collected. In scenarios with a massive number of nodes, the number of nodes participating in the process cannot be increased indefinitely. Waiting for nodes to submit results during the Commit phase introduces significant delays. To ensure efficiency, the process must limit the number or willingness of participating nodes, making it difficult to effectively utilize the enhanced randomness of a massive number of nodes and posing a risk of process centralization. Summary of the Invention

[0005] This application provides a method and apparatus for asynchronous random number generation, which solves the problem that the aggregation results of existing random number generation methods are easily predictable and unsuitable for scenarios with a large number of nodes.

[0006] Firstly, this application provides an asynchronous random number generation method, the method comprising: During the initialization phase, a random number collection contract is deployed on the blockchain and the parameters of the verifiable delay function (VDF) algorithm are initialized. During the commitment collection phase, random number commitments submitted by each generator node are collected; wherein, the generator node calculates the random number commitment and submits the random number commitment after committing the start block height and before displaying the end block height; The presentation collection phase involves collecting and presenting the random number commitments submitted by each generator node. During the result aggregation phase, the initiator node aggregates the contract results. Specifically, the initiator node decrypts the results displayed on the blockchain to obtain the plaintext of the random number, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the plaintext of the random number of each generator node, the block height difference, and the basic number of calculations, and aggregates them into the final random number.

[0007] The above technical solution has the following advantages or beneficial effects: The asynchronous random number generation method provided in this application includes four stages: initialization stage, commitment collection stage, display collection stage, and result aggregation stage. In the initialization stage, a random number collection contract is deployed on the blockchain, and the parameters of the verifiable delay function (VDF) algorithm are initialized. In the commitment collection stage, random number commitments submitted by each generator node are collected. Furthermore, the generator nodes calculate the random number commitments and submit them after the start block height of the commitment and before the end block height of the display stage. In other words, the timing of commitment submission in this application can be later than the start of the display collection stage; that is, this application does not require the collection of a sufficient number of commitments before entering the collection and display stage. This achieves an asynchronous random number generation method, solving the technical problem that synchronous random number generation methods in related technologies are unsuitable for scenarios with a large number of nodes. The presentation collection phase collects presentations of random number commitments submitted by each generator node. The result aggregation phase involves the initiator node aggregating the contract results. Specifically, the initiator node decrypts the blockchain presentation results to obtain the random number plaintext, obtains the block height difference between the block height submitted by each generator node and the final block height, and performs VDF aggregation calculations based on the random number plaintext of each generator node, the block height difference, and the basic computation count to generate the final random number. In this application, the initiator node performs VDF aggregation calculations on the results during the result aggregation phase to generate the final random number, thereby enhancing the unpredictability of the random number and solving the technical problem of easily predictable aggregation results in related synchronous random number generation methods.

[0008] Secondly, this application provides an asynchronous random number generation apparatus, the apparatus comprising: The initialization module is used during the initialization phase to deploy a random number collection contract on the blockchain and initialize the parameters of the verifiable delay function (VDF) algorithm. The commitment collection module is used in the commitment collection phase to collect the random number commitments submitted by each generator node; wherein, the generator node calculates the random number commitment and submits the random number commitment after the commitment start block height and before the display end block height; The collection module is used to display the collection phase, showcasing the random number commitments submitted by each generator node. The result aggregation module is used in the result aggregation stage, where the initiator node aggregates the contract results. Specifically, the initiator node decrypts the results displayed on the blockchain to obtain the plaintext of the random number, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the plaintext of the random number of each generator node, the block height difference, and the basic number of calculations, and aggregates them into the final random number.

[0009] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, used to execute a program stored in memory, implements the method described.

[0010] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0011] Fifthly, this application provides a computer program product comprising an executable program that is executed by a processor to implement the method described. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A schematic diagram of the random number collection contract provided for this application; Figure 2 The overall architecture diagram of the asynchronous random number generation system provided in this application; Figure 3 A schematic diagram of the asynchronous random number generation process provided in this application; Figure 4 A sample diagram illustrating the commitment demonstration process provided for this application; Figure 5 A schematic diagram of the asynchronous random number generation device provided in this application; Figure 6 A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0014] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0015] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0016] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0017] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0018] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0019] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0020] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0021] This application proposes a reliable on-chain random number generation mechanism with low interaction overhead in the case of massive nodes, which supports data express chain products and plays a key role in the development of this technology.

[0022] The background technical solutions involved in this application are described below: Verifiable delay function VDF: Verifiable Delay Functions (VDFs) are a class of mathematical functions that have emerged in recent years. Their computation requires at least a known time T, and even with CPU parallel computing, this time cannot be significantly reduced. However, once calculated, they can be quickly verified; that is, the verification time must be significantly less than the computation time. VDFs are tools for adding stable latency in distributed computing, providing a reliable "proof of time elapsed." A VDF function must satisfy the following conditions: Time consumption: The computation is time-consuming and difficult to significantly reduce through parallel computing; Rapid verification: The verification time for proving the calculation results needs to be significantly, at least logarithmically, less than the calculation time; Uniqueness: the same input corresponds to a unique output (but the proof of the result does not require uniqueness). Due to seriality, the probability of an attacker calculating the result of VDF in less than T time is negligible.

[0023] VDF generally consists of three processes: Setup, Eval calculation, and Verification. The initialization phase accepts security parameters. And time parameters (actual time elapsed) The parameters ek used for computation and the verification parameters vk can be determined. The computation phase accepts the computation parameters ek and the input x, and after a sufficiently long computation time, generates the output y and the proof. (Right now The verification phase accepts vk, x, y, and It can quickly verify and output whether it passes or fails (i.e., accept / reject = ...). The most common VDF formula in the industry (i.e., the calculation stage Eval in the diagram) is generally a repeated square formula as follows, where N is the modulus parameter in the public parameters. T is the time parameter The following expression means: Squaring the input x, squaring the result again, and repeating this process T times (total time taken). The final result is modulo N. The repetition of the square cannot be parallelized, and the result is only known in the last calculation, thus satisfying the time-consuming and unique requirements of the VDF algorithm. Generally, the larger the value of T, the higher the difficulty of the VDF problem, and the longer the average computation time.

[0024] ; To make the computation easily verifiable in order to meet the requirements of VDF, a proof is needed. Proof that the conditions are met. There are various forms, common ones include the integer N-multiplicative group based on Euler's totient function, Boneh interactive verification, and the Wislowski verification protocol, etc., which will not be specified in this paper. Proof The result, along with y, x, and vk, will be sent to the verifier for verification. Generally, the time spent verifying the result should be much less than the time spent calculating Eval, and can be considered negligible in comparison. Below is a set of comparative data for the proof Verify based on the repeated square Eval + the multiplicative group of integers N:

[0025] On-chain random number generator: Currently, there are three main types of on-chain random number generation mechanisms: VRF (Verifiable Random Function), threshold signature mechanism, and distributed CR (Commit-Reveal) scheme.

[0026] VRF: Typical examples include Algorand / Cardano. VRF outputs random numbers based on arbitrary inputs and outputs them, verifying the correctness of the random numbers and the source node through a non-interactive zero-knowledge proof process. However, VRF cannot prevent flooding attacks and Sybil attacks (too many transactions or too many malicious nodes can provide a generation advantage), so it is only suitable for chains based on weighted nodes.

[0027] Threshold signatures, such as Dfinity. Addressing the problems of ordinary VRF (Virtual Randomization Framework), Dfinity requires selecting N committee members to collect t valid signatures using a threshold signature algorithm, with a consensus algorithm determining the total signature. During signature generation, a VRF is used to generate random numbers.

[0028] Distributed Random Number Generation (CR): A typical example is Randao, which is currently the mainstream approach for on-chain random number generation algorithms. Its basic idea is to divide the main process into a Commit phase and a Reveal phase. In the Commit phase, multiple nodes submit enough hashes within a specified time; in the Reveal phase, a seed is generated based on these hashes using a certain aggregation algorithm. To prevent nodes from maliciously ignoring their submissions, an economic model (requiring nodes to provide a deposit) is used. This approach leverages the irreversible nature of hashes, effectively preventing cheating behavior such as "betting on a single hash" and ensuring the unbiasedness of random number generation.

[0029] Overall, VRF is too computationally intensive and suffers from flooding and Sybil attacks. Threshold signature algorithms also suffer from excessive computational complexity. This application primarily focuses on improving distributed signature processing (CR).

[0030] The related technologies, based on distributed random number generation (CR) on-chain random number generation algorithms, have a simple and reliable computation process, but they also have the following problems: Aggregation results are easily predictable: During the Reveal phase, when results are displayed and aggregated, the block-producing nodes or Reveal executors can calculate the results and selectively submit only Reveal aggregation results that are favorable to their side, discarding unfavorable Commit results. Unsuitable for scenarios with a large number of nodes: The Commit and Reveal phases are strictly synchronized; sufficient results must be collected before entering the aggregation phase. In scenarios with a large number of nodes, the number of nodes that can participate in the process cannot be increased indefinitely (waiting for nodes to submit results during the Commit phase introduces significant delays). To ensure efficiency, the process must limit the number or willingness of participating nodes (number, deposit), making it difficult to effectively utilize the enhanced randomness advantage of a large number of nodes, and posing a risk of process centralization.

[0031] Related technologies introduce the VDF algorithm into the aggregation process, which necessitates the computation of non-parallelizable VDF formulas to ensure unpredictable results. However, since the VDF algorithm itself consumes a significant amount of computation time, its unsuitability for scenarios with a large number of nodes becomes even more pronounced.

[0032] This application proposes a random number generation scheme based on a two-phase VDF algorithm with an on-chain asynchronous Commit-Reveal process, which can effectively adapt to scenarios with a large number of nodes. Each node submits the hash of the random number during Commit and displays the original random number during Reveal. The scheme does not set a globally unified end point for the Commit period; each node that has committed can asynchronously choose its Reveal timing, thereby reducing the overhead of the synchronization process. If a node chooses to commit after a Reveal by another node on the chain (i.e., a "betting on a single move" scenario may occur), this node needs to perform an additional VDF calculation (VDF reveal calculation) during Reveal. This calculation is more difficult than calculating the block time corresponding to the block height difference between the current Revealed block and the first Revealed block on the chain, and the result and proof are uploaded to the chain. The final generated random number is an aggregation of the results of the initiator performing a second VDF calculation (VDF aggregation calculation) on the random numbers submitted by all nodes. This application addresses the technical issues of scenarios unsuitable for massive numbers of nodes through an asynchronous Commit-Reveal process, and solves the technical problem of predictable aggregation results through two VDF calculations, without introducing new inter-node interaction steps, and reduces the risk of collusion among all participants.

[0033] Nodes need VDF computing power to submit a Commit (see-the-spot betting) after Reveal; otherwise, they cannot submit a Reveal, and the final Commit will be ignored, increasing the computing power requirements for nodes. However, this behavior itself is suspected of being cheating, hence it is a built-in requirement of this application. Nodes no longer need to rely on the economic model, which may lead to a large number of invalid Commits, increasing the blockchain storage burden. However, since this application is based on an asynchronous Commit-Reveal process, these Commits will not slow down the final aggregation of random numbers, nor will they affect the calculation of the final random number result. This application does not focus on how to restrict node Commit submissions; this application is compatible with existing economic models.

[0034] As mentioned above, this application proposes an asynchronous "Commit-Reveal" on-chain random number generation process adapted to scenarios with a large number of nodes, and enhances its unpredictability based on a two-phase VDF algorithm. The scenario involves a single blockchain. This invention does not limit the specific public / consortium blockchain type, but requires a fixed block interval. All nodes mentioned below are nodes with write transaction permissions to the blockchain (i.e., block-producing nodes). Figure 1 The schematic diagram of the random number collection contract provided in this application includes the following roles in the scenario: 1. Random Number Collection Contract. A smart contract needs to be deployed on the blockchain to implement the main functions of the entire random number collection process; it also needs to verify the VDF results and proofs submitted by nodes. Since this process does not require high computational resources, the computing power of the smart contract alone is sufficient.

[0035] Specifically, the random number collection contract includes the following smart contract functions: Start collecting begin(): Initiates a new round of random number collection; The `commit()` function commits the hash of a locally generated random number to the node. The `reveal()` function displays the plaintext of the random number submitted by the node, which is then compared to the previously promised value.

[0036] The contract also needs to store the following: Initialization parameter table: Used for initialization parameters of the entire system; VDF Results Table: Maintain a table that records the key results of this round of random number collection, such as the VDF input, results, proof, and verification results.

[0037] 2. Initiator Node. This is a node in the blockchain responsible for calling the random number collection contract begin() to initiate a random number collection request; it is also responsible for performing a second round of VDF calculation on the collected random numbers and aggregating the calculation results.

[0038] 3. Generator Nodes. These are nodes in the blockchain responsible for generating random numbers locally and calling the random number collection contract to commit() and reveal(). Generators also need VDF computing power to handle active or passive commitments made after other generators have revealed their results (i.e., placing bets based on single-number presentations).

[0039] Figure 2 The overall architecture diagram of the asynchronous random number generation system provided in this application is shown. This application comprises four phases: Initialization phase: This phase includes a one-time initialization step for computational parameters and the initiator starting a round of collection. Commitment collection phase: The initiator initiates the random number collection process through the random number collection contract, and each generator begins submitting commitments. Demonstration collection phase: Each generator begins submitting demonstrations; generators that have not previously submitted commitments can also submit commitments in this phase, but must simultaneously submit the results and proofs of the first round of VDF demonstration calculations. Result aggregation phase: The random number collection contract notifies the initiator that aggregation calculations can be performed; the initiator performs a second round of VDF aggregation calculations on the results.

[0040] Figure 3 The schematic diagram of the asynchronous random number generation process provided in this application includes the following steps: S101: Initialization phase, deploy the random number collection contract on the blockchain and initialize the parameters of the verifiable delay function (VDF) algorithm; S102: Commitment collection phase, collecting random number commitments submitted by each generator node; wherein, the generator node calculates the random number commitment and submits the random number commitment after committing the start block height and before displaying the end block height; S103: Display collection phase, collecting and displaying the random number commitments submitted by each generator node; S104: Result aggregation phase, the initiator node aggregates the contract results; wherein, the initiator node decrypts the results displayed on the blockchain to obtain the plaintext of the random number, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the plaintext of the random number of each generator node, the block height difference and the basic number of calculations, and aggregates into the final random number.

[0041] The asynchronous random number generation method provided in this application is applied to electronic devices, which can be nodes on a blockchain.

[0042] During the initialization phase, the deployment of a random number collection contract on the blockchain and the initialization of the verifiable delay function (VDF) algorithm parameters include: Each generator node and initiator node generates a public-private key pair locally; selects the VDF formula, proof algorithm, and its calculation parameters; sets the basic number of calculations according to the blockchain's block production frequency, wherein the duration of VDF calculations based on the basic number of calculations is less than the block production frequency; sets a random number aggregation algorithm; selects a hash algorithm; and confirms the starting block height of the commitment phase and the starting and ending block heights of the presentation phase.

[0043] The main purpose of the initialization phase is to deploy the random number verification contract on the verification chain and initialize the VDF algorithm parameters.

[0044] Each node generates a public / private key pair pk / sk locally and uses the public key to publicly announce the chain. If a chain already exists, this step is omitted.

[0045] Each node confirms the following VDF calculation parameters: Choose the VDF formula, proof algorithm, and computational parameters to be used. Assume that a completely flat VDF algorithm is chosen, and Boneh's proof is used. Determine the modulus parameter N in some way (such as the hash of the genesis block of the transaction chain).

[0046] Based on the blockchain's block production frequency t, set a base computation count T of a sufficiently large consecutive square number. baseThis ensures that the time required for most blockchain nodes to solve a VDF (Vertical Array Derivative) Eval calculation is slightly less than t. Assuming an average block time of 10 seconds, for most current general-purpose hardware machines, T... base = When the average calculation time is about 8 seconds for 10,000 times, then set T base = 10000. As overall hardware capabilities improve, the computation time should decrease accordingly, and each node should adjust this T through consensus updates as needed. base This T base This is also the number of consecutive squares corresponding to the block production time of a block, as will be assumed later in the text.

[0047] This section describes how to aggregate multiple random numbers from different generators and generate the final result. For simplicity, the following section assumes that the results are simply added together and the integer part is removed to obtain the final random number.

[0048] Identify a hash algorithm. Let's assume it's SHA256.

[0049] Each node deploys a random number collection contract on the chain and writes the above information into the initialization parameter table.

[0050] Each of the above steps only needs to be performed once.

[0051] When a new round of random number generation requests arrives, the initiator initializes a round of requests according to the following steps: When the generator calls the `begin()` function of the random number collection contract, it needs to confirm the starting block height for the commitment phase and the starting and ending block heights for the reveal phase in this round of collection. After the generator successfully calls the `begin()` function, a complete record of this round of random number collection will be added to the VDF result table. The detailed format of the VDF result table is shown in the table below. For example, if only block height data is available at this time, the starting block height for Commit is 32, and the starting to ending block heights for Reveal are 40 to 60:

[0052] During the commitment collection phase, the generator node calculates the random number commitment, including: The generator node generates random numbers and salt values ​​locally; the random number commitment is calculated according to the following formula: ; In the formula, For random number commitment, For hash algorithms, To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. Salt value, Concatenate strings.

[0053] The main purpose of the commitment collection phase is to collect the random number commitments submitted by each generator node. It is initiated when the block height of the blockchain advances to the commitment start block height (32 in this example).

[0054] Each generator node i that intends to participate in random number generation generates a random number s locally. i and salinity nonce i Then, the commitment C for this round is calculated using the following formula. i Where, || represents string concatenation; Enc is the asymmetric encryption algorithm used by each node when establishing the chain, and is consistent with the public-private key pair used in creating the chain; pk is the public key disclosed by the initiator of this round of collection; and hash is the hash algorithm confirmed by each node.

[0055] ; When generator i sees that the random number collection contract has displayed the promised starting block height, it needs to call the contract's commit() function after displaying the promised starting block height and before displaying the ending block height, thus committing C. i If the block height at the time of submission does not meet the requirements, the request will be rejected by the contract. Example: Assume there are nodes a and d, where C... a At block height 37, C d All blocks with a block height of 49 are valid. (For example, the starting block height of Commit is 32, and the starting to ending block height of Reveal is 40 to 60).

[0056] Due to the asynchronous nature of this application, the timing of submitting commitments can be later than the start of the collection phase. That is, this invention does not require the collection of a sufficient number of commitments before entering the collection and display phase.

[0057] During the collection phase, the collection of commitments to random numbers submitted by each generator node includes: If a commitment is submitted The block height is before the starting block height of the presentation phase, when the producer node commits. and As a demonstration of R's commitment to random numbers i ; If a commitment is submitted The block height is after the initial block height of the presentation phase, at which point the producer node commits. , And VDF displays the calculation results y i , x i T i ; To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. For the salinity, y i The result of VDF calculation. To prove, x i T is the input to the VDF algorithm. i To calculate the number of times.

[0058] Specifically, the block height difference between the block displayed by producer node i and the first block displayed on the blockchain is determined; the block height difference is calculated and T is used to... base The product of; T i The value is greater than the product.

[0059] After collecting the presentations of random number commitments submitted by each generator node, the method further includes: Verify hash(Enc) pk (s i )||nonce i Does T equal Ci? Verify T i Is the value greater than the block height difference between the block displayed by producer node i and the first block displayed on the blockchain, and T? base The product of; verify the VDF calculation results y. i and Is it x? i via T i The solution to this calculation; If all the above verifications pass, the current block will be added to the blockchain; otherwise, the current block will be rejected from being added to the blockchain, and the verification items that the generator node failed will be returned.

[0060] The main purpose of the presentation collection phase is to collect the presentations of random number commitments submitted by each generator node i. The presentation phase begins when the block height of the blockchain advances to the starting block height (40 in this example).

[0061] Each of those who have submitted commitment C i The node i submits and displays R i At that time, based on the previously submitted C i There are two cases for high-order blocks: a) If commitment C is submitted i The block height is before the starting block height of the presentation phase: Node i only needs to commit Enc pk (s i ) and nonce i As R i Example: Suppose node 'a' from the previous step is the first commit displayed on the chain, with a block height of 43.

[0062] b) If a commitment C is submitted iAfter the initial block height during the presentation phase, node i also needs to submit the VDF presentation calculation result y. i , x i T i The difficulty level here is T. i The difficulty of calculating the block generation time is that it is higher than the block height of the block that contains the current node and the block height difference between the block height of the first block that contains the current node and the block generation time of the first block that contains the current node.

[0063] In case b), this VDF displays the input parameters for computation, x i = C i ;and T i Then we need to take a value greater than: the block height difference between the block shown here and the first block shown on the chain, multiplied by T. base The value of . It is particularly important to note that in this case, since the node does not know which block its display result will be on the chain when it commits, the node must ensure R. i Successfully uploading to the blockchain requires more computations; calculating the VDF and submitting it to the blockchain for consensus also takes time. Therefore, nodes must gamble on the necessity of displaying their commitments despite the delay. For example, suppose node d submits a commitment to display R. d At that time, the block height was 51 (the next block height is 52), but node d predicted R. d The on-chain process may not be completed by the 52nd block, so node d can choose to calculate the estimated number of times for two more blocks, such as 54; then, at the time of submission, the VDF display result of the calculation needs to be calculated, T. i = (54-43) T base It is greater than (52-43). T base .

[0064] The logic behind this approach is that if a bet is placed based on a single display, it is assumed that the generator i has already made a commitment in its own favor based on all other displayed results. To eliminate the risk of malicious behavior by this generator, this invention requires node i to provide a proof of time elapsed, covering the time from the earliest display seen by node i to the block height of node i's own display.

[0065] Generator i will R i As input parameters, the `reveal()` function of the random number collection contract is called to submit the data.

[0066] The random number collection contract is verified according to the following steps: Verify hash(Enc) pk (s i )||nonce i Is it equal to Ci?

[0067] Verify the number of calculations T for the VDF i Whether it is large enough, that is, whether it meets the above conditions.

[0068] Verify the VDF calculation results y i and Is it x? i via T i The solution for this calculation.

[0069] If the verification passes, the block is added to the chain in the current block; otherwise, the block is rejected and a failure message with the specific reason for the error is returned to node i.

[0070] Figure 4 The following is a schematic diagram illustrating the commitment demonstration process provided for this application, using nodes a and d as examples. The demonstration of node a is shown in R. a The on-chain value is 43, which is the first demonstration in this round and is valid. Node d's commitment is 49 > 43, therefore its submitted demonstration R... d The VDF must be included to display the calculation results; it can choose R itself. d The estimated block height on the blockchain was 54, but the actual height was 53, which is valid.

[0071] In the result aggregation stage, the aggregation into the final random number includes: The initiator node sums the VDF aggregation calculation results of each generator node, removes the integer part from the sum, and obtains the final random number.

[0072] The main purpose of the results aggregation phase is to aggregate the results of the initiator's contract. This phase begins after the presentation and collection phase has ended.

[0073] The initiator displays R on the blockchain for all successful submissions. i The result is obtained by decrypting the plaintext random number s using your own private key. i .

[0074] The initiator retrieves the submissions from each generator i on-chain, including the display R. i The difference in block height, HDi, is the difference between the block heights of the current node and the end of the current display phase. For example, the HDa difference for node a is 60-43=17; HDd = 60-53=7.

[0075] The initiator performs a second round of VDF aggregation computation. For each generator i, s... i Use the VDF formula from 3.1.1, where x = s i T is the T corresponding to the height difference HDi of each block. base The number of calculations is multiplied by a factor of 1, i.e., T = HDi T base VDF aggregation computations for different generators i can be performed in parallel.

[0076] The logic of this step is: the earlier R is publicly displayed on the chain, the better. i The more likely it is to be maliciously exploited by the initiator, the more necessary it is to use VDF computation as a proof of time elapsed to protect it.

[0077] After the initiator completes the aggregation calculation of all VDF results, it aggregates them into a final random number r. For example, if n generators successfully submit their results y, and the integer part is removed, the following formula is used: ; Represents the integer part of R.

[0078] This application proposes an asynchronous commitment-demonstration based on-chain random number generation mechanism, suitable for scenarios with massive numbers of nodes, and uses the VDF algorithm to ensure the unpredictability and reliability of its results. The effect is as follows: The asynchronous process supports a massive number of nodes. This invention does not require strict separation between commitments and presentations, and does not require waiting for commitment collection time. It allows commitments to be submitted during the presentation phase, ensuring that even with a massive number of nodes, the results can still benefit from the randomness of multiple generators without sacrificing overall latency.

[0079] Strictly unpredictable outcomes. Each on-chain demonstration of R... i All submissions are protected by VDF time-elapsed proofs, employing a two-stage design. The risk protection for the first half of the duration (the time interval between the first on-chain demonstration and the actual demonstration) is handled by the generator i during the VDF demonstration computation process. The risk for the second half of the duration (the time interval between the demonstration on-chain and the end of the demonstration phase) is handled by the initiator through VDF aggregation computation. The first half increases the difficulty of malicious actions from the generator; the second half increases the difficulty of malicious actions from the initiator. Even with infinite VDF computing power, it is impossible for the initiator and generator alone to control the generation of the final random number.

[0080] Resisting attacks where the initiator and generator collude. Assume the initiator actually controls a generator i', and its VDF computing power is infinite. Since it's impossible to determine the actual power R can generate during computation and display,... i’ The height of the block on the chain (which will be used in the VDF aggregation calculation) is unknown, so the final aggregation result is still unpredictable. The initiator must simultaneously control the generator, have VDF computing power far exceeding that of other nodes on the chain, and control the block production of the entire blockchain in order to stably influence the final random number, which is almost impossible to happen simultaneously in the real world.

[0081] Figure 5 The schematic diagram of the asynchronous random number generation device provided in this application includes: Initialization module 11 is used for the initialization phase, which deploys a random number collection contract on the blockchain and initializes the parameters of the verifiable delay function (VDF) algorithm. The commitment collection module 12 is used in the commitment collection phase to collect the random number commitments submitted by each generator node; wherein, the generator node calculates the random number commitment and submits the random number commitment after the commitment start block height and before the display end block height; Display module 13 is used to display the collection phase, showing the random number commitments submitted by each generator node; The result aggregation module 14 is used in the result aggregation stage, where the initiator node aggregates the contract results. The initiator node decrypts the results displayed on the blockchain to obtain the random number plaintext, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the random number plaintext of each generator node, the block height difference, and the basic number of calculations, and aggregates them into the final random number.

[0082] Initialization module 11 is specifically used for each generator node and initiator node to generate public-private key pairs locally; select the VDF formula, proof algorithm, and their calculation parameters; set the basic number of calculations according to the block production frequency of the blockchain, wherein the duration of VDF calculation according to the basic number of calculations is less than the block production frequency; set the random number aggregation algorithm; select the hash algorithm; and confirm the starting block height of the commitment phase and the starting block height and ending block height of the presentation phase.

[0083] Commitment collection module 12 is specifically used by the generator node to generate random numbers and salt values ​​locally; the random number commitment is calculated according to the following formula: ; In the formula, For random number commitment, For hash algorithms, To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. Salt value, Concatenate strings.

[0084] Display module 13, specifically used for submitting commitments The block height is before the starting block height of the presentation phase, when the producer node commits. and As a demonstration of R's commitment to random numbers i ; If a commitment is submitted The block height is after the initial block height of the presentation phase, at which point the producer node commits. , And VDF displays the calculation results y i , x i T i ; To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. For the salinity, y i The result of VDF calculation. To prove, x i T is the input to the VDF algorithm. i To calculate the number of times.

[0085] The display collection module 13 is specifically used to determine the block height difference between the block displayed by the generator node i and the first block displayed on the blockchain; and to calculate the block height difference and T. base The product of; T i The value is greater than the product.

[0086] The collection module 13 is displayed and is also used to verify the hash (Enc). pk (s i )||nonce i Does T equal Ci? Verify T i Is the value greater than the block height difference between the block displayed by producer node i and the first block displayed on the blockchain, and T? base The product of; verify the VDF calculation results y. i and Is it x? i via T i The solution to this calculation; If all the above verifications pass, the current block will be added to the blockchain; otherwise, the current block will be rejected from being added to the blockchain, and the verification items that the generator node failed will be returned.

[0087] The result aggregation module 14 is specifically used to sum the VDF aggregation calculation results of each generator node by the initiator node, remove the integer part of the sum, and obtain the final random number.

[0088] This application also provides an electronic device, such as Figure 6 As shown, it includes: processor 21, communication interface 22, memory 23 and communication bus 24, wherein processor 21, communication interface 22 and memory 23 communicate with each other through communication bus 24; The memory 23 stores a computer program, which, when executed by the processor 21, causes the processor 21 to perform any of the above method steps.

[0089] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0090] Communication interface 22 is used for communication between the above-mentioned electronic device and other devices.

[0091] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0092] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0093] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0094] This application provides a computer program product, which includes an executable program that, when executed by a processor, implements the method described herein.

[0095] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0096] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for asynchronously generating random numbers, characterized in that, The method includes: During the initialization phase, a random number collection contract is deployed on the blockchain and the parameters of the verifiable delay function (VDF) algorithm are initialized. During the commitment collection phase, random number commitments submitted by each generator node are collected; wherein, the generator node calculates the random number commitment and submits the random number commitment after committing the start block height and before displaying the end block height; The presentation collection phase involves collecting and presenting the random number commitments submitted by each generator node. During the result aggregation phase, the initiator node aggregates the contract results. Specifically, the initiator node decrypts the results displayed on the blockchain to obtain the plaintext of the random number, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the plaintext of the random number of each generator node, the block height difference, and the basic number of calculations, and aggregates them into the final random number.

2. The method as described in claim 1, characterized in that, The steps of deploying a random number collection contract on the blockchain and initializing the verifiable delay function (VDF) algorithm parameters include: Each generator node and initiator node generates a public-private key pair locally; selects the VDF formula, proof algorithm, and its calculation parameters; sets the basic number of calculations according to the blockchain's block production frequency, wherein the duration of VDF calculations based on the basic number of calculations is less than the block production frequency; sets a random number aggregation algorithm; selects a hash algorithm; and confirms the starting block height of the commitment phase and the starting and ending block heights of the presentation phase.

3. The method as described in claim 1, characterized in that, The generator node's commitment to calculating random numbers includes: The generator node generates random numbers and salt values ​​locally; the random number commitment is calculated according to the following formula: ； In the formula, For random number commitment, For hash algorithms, To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. Salt value, Concatenate strings.

4. The method as described in claim 1, characterized in that, The presentation of the random number commitments submitted by each generator node includes: If a commitment is submitted The block height is before the starting block height of the presentation phase, when the producer node commits. and As a demonstration of R's commitment to random numbers i ; If a commitment is submitted The block height is after the initial block height of the presentation phase, at which point the producer node commits. , And VDF displays the calculation results y i , x i T i ; To be consistent with the asymmetric encryption algorithm used to generate public-private key pairs, For public key, It is a random number. For the salinity, y i The result of VDF calculation. To prove, x i T is the input to the VDF algorithm. i To calculate the number of times.

5. The method as described in claim 4, characterized in that, Determine the block height difference between the block displayed by producer node i and the first block displayed on the blockchain; calculate the block height difference and T. base The product of; T i The value is greater than the product.

6. The method as described in claim 5, characterized in that, After collecting the presentations of random number commitments submitted by each generator node, the method further includes: Verify hash(Enc) pk (s i )||nonce i Does T equal Ci? Verify T i Is the value greater than the block height difference between the block displayed by producer node i and the first block displayed on the blockchain, and T? base The product of; verify the VDF calculation results y. i and Is it x? i via T i The solution to this calculation; If all the above verifications pass, the current block will be added to the blockchain; otherwise, the current block will be rejected from being added to the blockchain, and the verification items that the generator node failed will be returned.

7. The method as described in claim 1, characterized in that, The aggregation into the final random number includes: The initiator node sums the VDF aggregation calculation results of each generator node, removes the integer part from the sum, and obtains the final random number.

8. An asynchronous random number generation device, characterized in that, The device includes: The initialization module is used during the initialization phase to deploy a random number collection contract on the blockchain and initialize the parameters of the verifiable delay function (VDF) algorithm. The commitment collection module is used in the commitment collection phase to collect the random number commitments submitted by each generator node; wherein, the generator node calculates the random number commitment and submits the random number commitment after the commitment start block height and before the display end block height; The collection module is used to display the collection phase, showcasing the random number commitments submitted by each generator node. The result aggregation module is used in the result aggregation stage, where the initiator node aggregates the contract results. Specifically, the initiator node decrypts the results displayed on the blockchain to obtain the plaintext of the random number, obtains the block height difference between the block height submitted for display by each generator node and the block height at the end of the display, performs VDF aggregation calculation based on the plaintext of the random number of each generator node, the block height difference, and the basic number of calculations, and aggregates them into the final random number.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images