METHOD FOR GENERATING SECURE RANDOMNESS ON BLOCKCHAIN

Abstract

A method for generating a random number is used for a plurality of blocks in a blockchain. The method comprises the steps of: selecting a committee comprising a subset of nodes from the blockchain; executing a distributed key generation to generate a share key and a public key at each of the nodes, wherein the public key further comprises a set of verification keys; broadcasting a share signature from each of the nodes; executing a threshold signature at each of the nodes when a new block is generated; and executing a random number which is a hash value of the threshold signature which is combined from a plurality of partial signature generated from the nodes.

Claims

1. A method for generating a random number for a plurality of blocks in a blockchain, comprising: selecting a committee comprising a subset of nodes from the blockchain; executing a distributed key generation to generate a share key and a public key at each of the nodes, wherein the public key further comprises a set of verification keys; broadcasting a share signature from each of the nodes; executing a threshold signature at each of the nodes when a new block is generated; and executing a random number which is a hash value of the threshold signature which is combined from a plurality of partial signature generated from the nodes.

2. The method of claim 1, wherein the share signature is given by taking the share key and a value h into a function sharesign(share key, h), where h is a hash value of the block.

3. The method of claim 2, wherein threshold signature is given by taking the value h, the public key and the share signature into a function Combine(h, public key, share signature).

4. The method of claim 1, wherein the step of executing the distributed key generation further comprises: providing a plurality of validators including an i-th validator, a j-th validator and a k-th validator; having each of the validators register an ID that is associated with each of the validators; and broadcasting an ID message from each of the validators.

5. The method of claim 4, wherein the step of executing the distributed key generation further comprises: generating a plurality of secret key shares (SK.sub.i,0, SK.sub.i,1, . . . , SK.sub.i,n) of order t from the each of validators if the one of validator see the number of the ID messages is more than 2t+1 and less than 3t+1, wherein the value t is a number of Byzantine Agreement, and the number of the plurality of secret key shares is the same as the number of the registered ID; sending each of the secret key shares to the corresponding validator via a secure channel (i.e. the SK.sub.i,j is sent to the j-th validator from the i-th validator); and broadcasting a master public key (MPK.sub.i=MPK.sub.i, 0, MPK.sub.i, 1, . . . , MPK.sub.i,t) of order t associated with the secret key shares from each of the validators.

6. The method of claim 5, wherein the step of executing the distributed key generation further comprises: having each of validators calculate a public key share (PK.sub.0,i, PK.sub.1,i, . . . , PK.sub.n,i) using the corresponding master public key; and broadcasting a complaint (i.e. if the i-th validator verifies the secret key share (SK.sub.j,i) is not associated with the public key share of the j-th validator (PK.sub.j,i) the i-th validator broadcasts a complaint of the j-th validator (CMP.sub.i,j)) from each of the validators if each of the validators verifies the secret key share is not associated with the public key share of another validator.

7. The method of claim 6, wherein the step of executing the distributed key generation further comprises: broadcasting a nack complaint of the j-th validator (NCMP.sub.i,j) from the i-th validator if the i-th validator does not receive the secret key share (SK.sub.j,i); and broadcasting the secret key share (SK.sub.j,i) from the j-th validator if the j-th validator see the nack complaint of the i-th validator (NCMP.sub.i,j).

8. The method of claim 7, wherein the step of executing the distributed key generation further comprises: broadcasting the secret key (SK.sub.j,i) from the k-th validator if the k-th validator receive the secret key (SK.sub.j,i) and the value i is not equal to the value k; having the k-th validator execute a verification that the secret key (SK.sub.j,i) is associated with the public key share of the j-th validator (PK.sub.j,i) if the k-th validator sees the secret key (SK.sub.j,i) and the value i is not equal to the value k; and broadcasting a complaint of j (CMP.sub.k,j) from the k-th validator if the verification fails; and broadcasting a nack complaint of the j-th validator (NCMP.sub.k,j) from the k-th validator if the k-th validator sees the nack complaint of the j-th validator (NCMP.sub.i,j), the value j is not equal to the value k, and the k-th validator does not receive the secret key (SK.sub.j,i).

9. The method of claim 8, wherein the step of executing the distributed key generation further comprises: broadcasting a distributed key generation final (DKGFinal) message from each of the validators; marking the j-th validator as a disqualified validator if a number of the nack complaint are sent to the j-th validator is more than the value t; and marking the j-th validator as the disqualified validator if the existing complaint (CMP.sub.i,j) is sent to the j-th validator.

10. The method of claim 9, wherein the step of executing the distributed key generation further comprises: having each of the validators determine a combined secret key (CSK); having each of the validators sign the DKGFinal message and broadcast the partial signature (PSig); and having each of the validators determine a combined public key (CPK) of the j-th validator.

11. The method of claim 10, wherein the step of executing the distributed key generation further comprises: having the i-th validator verify the partial signature (PSig) with the combined public key (CPK) if the i-th validator is not the disqualified validator; collecting the valid partial signature (PSig); recovering the threshold signature, when the number of the valid partial signature (PSig) is more than the value t; and verifying the threshold signature to determine a group public key.

12. A distributed system executed in a blockchain comprising: a plurality of nodes; and a committee; wherein the plurality of nodes are configured to: select a subset of nodes from the blockchain as the committee; wherein the committee is configured to: execute a distributed key generation to generate a share key and a public key at each of the nodes; broadcasting a share signature from each of the nodes in the committee; execute a threshold signature at each of the nodes in the committee when a new block is generated; and execute a random number which is a hash value of the threshold signature which is combined from a plurality of partial signature generated from the nodes in the committee.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to sufficiently understand the essence, advantages and the preferred embodiments of the present invention, the following detailed description will be more clearly understood by referring to the accompanying drawings.

[0019] FIG. 1 is a block diagram of a distributed system in which some exemplary embodiments of the disclosed subject matter may be implemented.

[0020] FIG. 2 is a flow diagram of a process in accordance with some exemplary embodiments of the disclosed subject matter.

[0021] FIG. 3 is a block diagram of a distributed system in which some exemplary embodiments of the disclosed subject matter may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

[0022] The following description shows the preferred embodiments of the present invention. The present invention is described below by referring to the embodiments and the figures. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the principles disclosed herein. Furthermore, that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims.

[0023] FIG. 1 is a diagram that shows a plurality of nodes 108-122 (e.g., individual personal computing devices, server computing devices, or other devices that have sufficient processor and storage abilities to participate in the system) connected to an internet 102 and connected to each other via the internet 102. The distributed system 100 in which transactions and records are organized in blocks includes the plurality of nodes 108-122. A committee is selected from the plurality of nodes 108-122 by using a Fisher-Yates shuffle algorithm with the previous block hash as the randomness. Let n be the number of nodes or parties within a committee and the number of adversaries within the committee be less than t. It is suggestable to set the threshold as +>t/n>. A malicious parity can be controlled and perfectly coordinated by a single node, the adversary. The committee will run a distributed key generation (DKG) to generate a share key and a public key at each of the nodes in the committee for threshold signature, wherein the public key further comprises a set of verification keys. Then, each node in the committee broadcasts a share-signature on a confirmed block height h. After a block is generated, the committee signs a threshold signature on the block. Then, the hash of the threshold signature serves as the random number of the block. The committee is re-selected for each epoch. As will be understood by those skilled in the art, the present invention is applicable to all distributed computing environments and is not intended to be limited in any way by the exemplary distributed system of FIG. 1, which has been simplified for presentation purposes.

[0024] FIG. 2 is a flowchart diagramming a process 200, in accordance with some exemplary embodiments of the disclosed subject matter. Those skilled in the art will appreciate that the method illustrated by the flowchart of FIG. 2 is merely exemplary and that alternate variations may be employed, all in accordance with the present technique.

[0025] Process 200 begins with step 202, the committee is selected from the blockchain, and comprises a subset of nodes in the blockchain. In one exemplary embodiment, the committee may be selected from the plurality of nodes 108-122 by using a Fisher-Yates shuffle algorithm with the previous block hash as the randomness. In this embodiment, we need a committee of size n with the number of adversary less than t and a suggested setting for the threshold is +>t/n>.

[0026] At Step 204, each of the nodes in the committee executes a distributed key generation of threshold signature to generate a share key and a public key, wherein the public key further comprises a set of verification keys. At next step 206, each of the nodes in the committee broadcasts a share signature that is formed by taking the share key and a value h into a function sharesign(share key, h) using a probabilistic polynomial-time algorithm or the like, where h is a height of the block (i.e., previous block).

[0027] At next step 208, when a new block is generated, the each node in the committee executes a threshold signature that is formed by taking the value h, the public key and the share signature into a function Combine(h, public key, share signature) using a probabilistic polynomial-time algorithm or the like.

[0028] At next step 210, each of the nodes in the committee executes a number for the block is a hash value of the threshold signature which is combined from a plurality of partial signature generated from the nodes in the committee, wherein the number is randomness for the new block.

[0029] FIG. 3 is a diagram that shows a plurality of nodes 302. A committee is selected from some of the plurality of nodes 302. The committee is re-selected for each epoch. The committee can generate for an epoch for the blockchain. An epoch can be according to either a specific number of blocks or a fixed during of consensus time in the blockchain 304. The randomness 306 for blocks in an epoch may be generated by the same committee. The committee may compute the randomness into a function Hash(TSig(Block_hash)). The embodiment adopts an improved Verifiable Random Function (VRF) with Threshold Signature to generate the randomness for each block.

[0030] In another aspect, the overall procedure of Verifiable Random Function (VRF) with Threshold Signature protocol is summarized as below, that may provide better understanding of the present embodiment to those having ordinary skill in the art.

Randomness Form VRF on Blockchain

[0031] 1. KeyGen(1.sup.): each node i in committee executes KeyGen(1.sup.) of TSIG and get it own share-key SK.sub.i, and the public key is ({VK.sub.i}.sub.=1.sup.n,PK). [0032] 2. Prove(h,{SK.sub.i}.sub.iS,{VK.sub.i}.sub.i=1.sup.n,PK): each node i broadcasts its shared signature .sub.i=ShareSign(SK.sub.i, h) and executes TSign(h)=Combine(h, PK, {VKi}.sub.iS, {i}.sub.iS), where S is a subset of the committee and |S|=t. Then, the randomness for h is Hash(TSign(h)) and the proof (h)=TSign(h). [0033] 3. Veri(PK, h, y, ): output

VerifyTSign(h,PK,(h)))(y.sub.=.sup.?Hash((h))).

[0034] In one exemplary embodiment, the distributed key generation comprises the following steps:

[0035] Step a) of ID Registration, at T<0: A plurality of validators registers comprising an i-th validator, a j-th validator and a k-th validator is provided. Each of the validators registers its ID(DKGMasterPublicKey); and each of the validators broadcasts an ID message (DKGMasterPublicKeyReady message). If the one of validator sees that the number of the ID messages is more than 2t+1, the process goes the next step.

[0036] Step b) of Secret Key Exchange, at T=0: The each of validators generates a plurality of secret key shares (SK.sub.i,0, SK.sub.i,1, . . . , SK.sub.i,n) of order t, wherein the value t is a number of Byzantine Agreement, and the number of the plurality of secret key shares is the same as the number of the ID registrations. Each of the secret key shares is sent to the corresponding validator via a secure channel (i.e. the SK.sub.i, j is sent to the j-th validator from the i-th validator). Each of the validators broadcasts a master public key (MPK.sub.i=MPK.sub.i,0, MPK.sub.i,1 . . . MPK.sub.i,t) of order t associated the secret key shares.

[0037] Step c) of Complaint, at T=(0, ): The each of validators calculates a public key share (PK.sub.0,i, PK.sub.1,i, . . . , PK.sub.n,i) using the corresponding master public key, wherein the public key is define as: PK.sub.j,iF(MPK.sub.j,i). If each of the validators verifies the secret key share is not associated with the public key share of another validator, the each of the validators broadcasts a complaint (i.e. if the i-th validator verifies the secret key share (SK.sub.j,i) is not associated with the public key share of the j-th validator (PK.sub.j,i), the i-th validator broadcasts a complaint of the j-th validator (CMP.sub.i,j)).

[0038] Step d) of Nack Complaint, at T=: If the i-th validator did not receive the secret key share (SK.sub.j,i) the i-th validator broadcasts a nack complaint of the j-th validator (NCMP.sub.i,j).

[0039] Step e) of Anti Nack Complaint, at T=2: If the j-th validator sees the nack complaint of the i-th validator (NCMP.sub.i,j), the j-th validator broadcasts the secret key share (SK.sub.j,i).

[0040] Step f) of Rebroadcast Secret, at T=3: If the k-th validator receives the secret key (SK.sub.j,i) and the value i is not equal to the value k for the first time, the k-th validator broadcasts the secret key (SK.sub.j,i).

[0041] Step g) of Enforce complaint, at T=4: If the k-th validator sees the secret key (SK.sub.j,i) and the value i is not equal to the value k, the k-th validator executes a verification that the secret key (SK.sub.j,i) is associated with the public key share of the j-th validator (PK.sub.j,i); and if the verification fails, the k-th validator broadcasts a complaint of j (CMP.sub.k,j); and if the k-th validator sees the nack complaint of the j-th validator (NCMP.sub.i,j), the value j is not equal to the value k, and the k-th validator did not receive the secret key (SK.sub.j,i) the k-th validator broadcasts a nack complaint of the j-th validator (NCMP.sub.k,j).

[0042] Step h) of DKG Finalize, at T=5: Each of the validators broadcasts a distributed key generation final (DKGFinal) message.

[0043] Step i) of Sign with CSK, at T=6: Each of the validators waits until receiving more than 2t+1 final message. If a number of the nack complaint are sent to the j-th validator is more than the value t, the j-th validator is marked as a disqualified validator; and if the existing complaint (CMP.sub.i,j) is sent to the j-th validator, the j-th validator is marked as the disqualified validator. Each of the validators determines a combined secret key (CSK); each of the validators signs the DKGFinal message with the CSK and broadcasts a partial signature (PSin); and each of the validators determines a combined public key (CPK) of the j-th validator.

[0044] Step j) of TSIG at T=(6, ): If the i-th validator is not the disqualified validator, the i-th validator verifies the partial signature (PSin) with the combined public key (CPK); the valid partial signature (PSin) is collected, and if the number of the valid partial signature (PSin) are more than t, the threshold signature is recovered.

[0045] Step k) of Verity TSIG Determines the group public key: The threshold signature is verified to determine a group public key.

[0046] In another aspect, the overall procedure of Distributed Key Generation protocol is summarized as below, that may provide better understanding of the present embodiment to those having ordinary skill in the art.

Notations

[0047] : MAX (One gossip duration, transaction confirm latency)

[0048] Signature: BLS

[0049] Curve: CurveF p382-2

[0050] n: size of committee

[0051] t: number of Byzantine

DKG and TSIG Protocol

[0052] Phase 1 ID Registration T<0:

[0053] Each validator registers its ID (DKGMasterPublicKey.sub.i) with stake. After each validator i broadcasts a DKGMasterPublicKeyReady.sub.i message. Validator waits until seeing more than 2t+1 DKGGroupPublicKeyReady message than proceeds to Phase 2.

[0054] Phase 2 Secret Key Share Exchange, T=0:

[0055] Each validator i generates n (n=# of ID registered in phase 1) secret key shares (SK.sub.i,0, SK.sub.i,1, . . . , SK.sub.i,n) of order t and the secret key share is sent to the corresponding validator (SK.sub.i,j is sent to validator j) via a secure channel. Each validator i broadcasts the master public key (MPK.sub.i=MPK.sub.i,0, MPK.sub.i,1, . . . , MPK.sub.i,t) of order t associated with the secret key shares.

[0056] Phase 3 Complaint T=(0, ):

[0057] Each validator i calculates public key shares (PK.sub.0,i, PK.sub.i,1, . . . , PK.sub.n,i) using corresponding master public key (PK.sub.j,i=F(MPK.sub.j,i)). Each validator i verifies if the secret key share SK.sub.j,i is associated with the public key share of validator j, PK.sub.j,i. If the verification fails, i broadcast complaint of j, CMP.sub.i,j.

[0058] Phase 4 Nack Complaint T=:

[0059] If validator i did not receive SK.sub.j,i, broadcast nack complaint of j, NCMP.sub.i,j.

[0060] Phase 5 Anti Nack Complaint T=2:

[0061] If validator j sees NCMP.sub.i,j for any i, broadcast secret key share SKj,i.

[0062] Phase 6 Rebroadcast Secret T=3:

[0063] If validator k receive SK.sub.j,i for the first time for ik, broadcast it again.

[0064] Phase 7 Enforce Complaint T=4:

[0065] If validator k sees SK.sub.j,i for ik, verifies if the secret key share SK.sub.j,i is associated with the public key share of validator j, PK.sub.j,i. If the verification fails, k broadcast complaint of j, CMP.sub.k,j. If validator k sees NCMP.sub.i,j for jk and did not receive SK.sub.j,i, k broadcast nack complaint of j, NCMP.sub.k,j.

[0066] Phase 8 DKG Finalize T=5:

[0067] Each validator i broadcast a DKGFinal, message.

[0068] Phase 9 Sign with CSK T=6:

[0069] Validator waits until seeing more than 2t+1 final message. If there are more than t nack complaints to validator j ((i: for all validator i)), then j is marked as Disqualified. If there is one complaint, CMP.sub.i,j, to validator j, then j is marked as Disqualified. Each validator i determines the combined secret key, (k: validator k is not marked as Disqualified). Each validator i sign the message with CSK.sub.i and broadcast the partial signature, PSign.sub.i. Each validator i determines the combined public key of validator j, (k: validator k is not marked as Disqualified).

[0070] Phase 10 TSIG T=(6, ):

[0071] If validator i is not Disqualified, verify PSign.sub.i with CPK.sub.i. Collect more than t valid PSign.sub.i and recover TSIG.

[0072] Phase 11 Verify TSIG Determines the group public key, (k: validator k is not marked as Disqualified) Verify TSIG with GPK.

[0073] According to the present invention, the present application provides a method for generating a random number for a plurality of blocks in a blockchain. The random number provided by the application has unpredictable, unbiased, unique and verifiable characteristics.

[0074] By unpredictable, we mean that the random number should be indistinguishable from the string sampled from a uniform distribution when the transaction is sent (or the contract is deployed).

[0075] By unbiased, we mean that any single user cannot influence or change the random number even he or she deviates from the protocol arbitrarily (In our concrete construction, the number of users can be parametrized. Any portion of users below a pre-determined threshold cannot influence the random number. For example, the threshold can be . In this case, even half of the users collude, they still cannot bias). Without unbiasness, the block proposer may adjust the order of transactions to create a biased random number for his or her own profit. Thus, simply choosing the hash of the following blocks will not work.

[0076] By unique, we mean that there is only one random number can be generated given a specific block. Without uniqueness, the users may have multiple choices and may choose the best one for their own profit.

[0077] By verifiable, we mean that the authenticity of the random number can be verified by everyone, even the users who do not participate in the block generation.

[0078] Finally, the consensus of the random number is guaranteed by the blockchain, so every user can agree on the same random number of a given block. The random number is unpredictable, unbiased, unique and verifiable so that the random number is a secure randomness on the blockchain.

[0079] The foregoing embodiments of the invention have been presented for the purpose of illustration. Although the invention has been described by certain preceding examples, it is not to be construed as being limited by them. They are not intended to be exhaustive, or to limit the scope of the invention. Modifications, improvements and variations within the scope of the invention are possible in light of this disclosure.