METHOD FOR INFORMATION VERIFICATION IN DISTRIBUTED SYSTEMS

Abstract

A method for a node to issue a new block is used for a distributed system in which transactions and records are organized in block. The method comprises the steps of: determining a value R from a common reference string; computing a value s associated to a value of a status with a private key at a node, wherein the private key is a private signing key corresponding to the node, and the value s can only be computed by the node with the private key; computing a value r by taking the value s into a function H at the node, wherein the value r is unpredictable and unique to other nodes; and determining whether the node obtains a right to issue a new block by taking the values R and r into a function V.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to a method for a node being allowed to issue a new block in a distributed system in which transactions and records are organized in blocks, and particularly, to a new block committed to a blockchain in a blockchain network by using a common reference string and a verifiable random function.

2. Description of Related Art

Blockchains or blockchain is a distributed database that keeps a continuously growing list of data records. Each data record is protected against tampering and revisions. Blockchains are used with public ledgers of transactions, where the record is enforced cryptographically. Such a blockchain system is a replicated state machine that must be fault tolerant. When designing a blockchain system, there is usually a trade-off between decentralization, scalability and security, which is called the trilemma problem in blockchains. The blockchain trilemma is one of the biggest challenges for cryptocurrencies.

Blockchain systems are being challenged to demonstrate rigorous robustness and high performance in real-world situations. Many applications demand low transaction confirmation latency and high transaction throughput. However, most blockchain systems do not satisfy these criteria. For example, the confirmation latency of Ethereum (with traditional minute-level latency) is about 5 to 10 minutes and the throughput is limited to about 30 transactions per second. By contrast, some blockchain systems achieve high performance but sacrifice the robustness of the systems. For example, EOS achieves high performance, but it is operated with only 21 supernodes, and is vulnerable to DDoS attacks. PCT International Publication No. 2017/192837 discloses Algorand's techniques that are decentralized and have robust safety, which is incorporated herein by this reference, but Algorand's throughput is limited.

Thus, there is a need for a novel blockchain system which achieves high scalability while remaining decentralized and robust in the real-world environment. The application provides a method for a node allowed to issue a new block in a distributed system in which transactions and records are organized in blocks so as to achieve high decentralization and low latency.

SUMMARY OF THE INVENTION

The present application provides a method for a node being allowed to issue a new block is described herein. The method is executed in a distributed system including a plurality of blocks, comprises: determining a value R from a common reference string; computing a value s associated to a value of a status with a private key at a node; computing a value r by taking the value s into a function H at the node; and determining whether the node obtains a right to issue a new block by taking the values R and r into a function V. The private key may be a private signing key corresponding to the node. The value s may only be computed by the node with the private key. The value r may be unpredictable and unique to other nodes.

In another embodiment, the value r can be verified with a public key and the value s. The status may be defined to be a shard ID, a chain ID or a height of the block.

In another embodiment, the common reference string may be a public randomness generated by a deterministic algorithm for each epoch. The epoch may consist of a specific number of blocks.

In another embodiment, the common reference string is defined as: R_i=Hash(TSig(R_i−1)), where R_i is generated for the new block, and TSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks.

In another embodiment, the common reference string is defined as: R_i=(Sig_{authority}(R_i−1)), where R_i is generated for the new block.

In another embodiment, the function H may be a hash function. The function V is defined as: |R−Hash(Sig_sk (status))|, where R is the value R and Hash(Sig_sk(status) can be verified by a public key.

In another embodiment, the node obtains the right to issue the new block when a calculated value for the function V is the minimum at the node by comparing with other calculated values for the function at other nodes. The blocks may pertain to a single blockchain.

The present application further provides a method for a node being allowed to issue a new block. The method is executed in a distributed system including a plurality of blocks, comprises: determining a value R from a common reference string; computing a value s associated to a value of a status at a node; computing a value r by taking the value s into a function H at the node; and determining whether the node obtains a right to issue a new block by taking the values R and r into a function V. The value s can be verified by other nodes.

In another embodiment, the value r may be unpredictable and unique to other nodes. The value r can be verified with a public key and the value s.

In another embodiment, the status can be defined to be a shard ID, a chain ID or a height of the block.

In another embodiment, the common reference string may be a public randomness generated by a deterministic algorithm for each epoch. The epoch consists of a specific number of blocks.

In another embodiment, the common reference string is defined as: R_i=Hash(TSig(R_i−1)), where R_i is generated for the new block, and TSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks.

In another embodiment, the common reference string is defined as: R_i=(Sig_{authority}(R_i−1)), where R_i is generated for the new block.

In another embodiment, the function H is a hash function. The function V is defined as: |R−Hash(Sig_sk(status)), where R is the value R and Hash(Sig_sk(status) is verified by a public key.

In another embodiment, the node obtains the right to issue the new block when a calculated value for the function V is the minimum at the node by comparing with other calculated values for the function at other nodes. The blocks may pertain to a single blockchain.

The present application further provides a distributed system comprising: a plurality of first nodes determining a value R from a common reference string; and a plurality of second nodes computing a value s associated to a value of a status and computes a value r by taking the value s into a function H and allowing one of the second nodes to issue a new block by taking the values R and r into a function V; wherein the plurality of first nodes and the plurality of second nodes are connected to each other via an internet.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

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

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

FIG. 3 is a flow diagram of a process in accordance with some exemplary embodiments of the disclosed subject matter.

FIG. 4 is a timeline diagram of building a blockchain in accordance with some exemplary embodiments of the disclosed subject matter.

DETAILED DESCRIPTION OF THE INVENTION

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.

FIG. 1 is a diagram that shows a plurality of nodes 108-122 (e.g., devices, workstations, computers, or miners) 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 a plurality of nodes 108-122. In the distributed system 100, a user is uniquely identified by its public key (pk) and private key (sk) pair, where the private key is a private signing key corresponding to one of nodes 108-122. All users at the nodes 108-122 can transfer and receive the stakes from other users. The blockchain of the present application is maintained by a special set of users S_node where the members of S_node are called nodes. All users can also verify the correctness of the blockchain. There are two special sets of nodes of the present application: the CRS (common reference string) set S_CRS 104 and the notary set S_notary 106 (a node can be in two sets at the same time). The consensus of distributed system 100 is based on proof-of-participation; that is, each node has equal chance to propose a block. One of nodes 108-122 can pack a batch of transactions into a block. A node proposes a block if the block is a candidate that can be selected (i.e., a node is allowed to issue a block if the block is selected and become a block in the blockchain). The blocks may pertain to a single blockchain.

The members in S_CRS 104 are responsible for updating the CRS. The members in S_notary 106 have right to propose a block and are responsible for deciding whose block can be chosen for the single chain.

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 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.

Process 200 begins with step 202, in which the members in S_CRS generate a value R from a common reference string (CRS). An epoch consists of a specific number of blocks. The CRS is a public randomness generated by a deterministic algorithm for each epoch; no user in the system can predict the CRS of any future epoch. In an exemplary embodiment, the CRS of epoch i is updated by R_i=Hash(TSig (R_i−1)), where R_i is generated for the new block, Hash(⋅) is a hash function that maps arbitrarily long strings to binary strings of fixed length, and TSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks (i.e., the CRS nodes compute the randomness according to results from a previous epoch).

In another exemplary embodiment, the common reference string is defined as: R_i=(Sig_{authority}(R_i−1)) under Proof-of-Authority blockchain, where R_i is generated for the new block.

At Step 204, each node in S_notary computes a value s associated to a value of a status with the private key, and the status is the public predictable information of the block (e.g. shard ID, chain ID or block height). In an exemplary embodiment, each node in S_notary computes the signature with its private key sk as: s=Sig_sk(status), where Sig_sk(status) is a binary string and referred to as the digital signature of the status of the private key sk.

At next step 206, each node in S_notary computes a value r by taking value s into a function H, where the function H may be a Hash function. The value r can be verified with the public key and the value s by other nodes.

The value r may be unpredictable and unique to other nodes.

At step 208, the node in S_notary determines which node obtains a right to issue a new block by taking the value R and r into a function V. The function V is the verifiable random function (VRF), defined as: |R_i−Hash(Sig_sk(status))| where, the R_i is the value R and Hash(Sig_sk(status)) is verified by the public key. The node obtains the right to issue the new block when a calculated value for the function V is minimum at the node by comparing with other calculated values for the function at other nodes. To determine which node obtains the right to issue a block by computing:

l _q=arg min_j∈Uq|R_i−Hash(Sig_skj(status))|

Where, l_q is the node obtaining the right or the leader of node q, the U_q is the set of nodes whose signatures are valid, and Sig_skj(status) is the digital signature of the status of the private key sk at the node j.

The embodiment adopt a VRF to decide the node q to issue a block. This serves to minimize the communication cost so that a large population can join the protocol. The determination is independent of the round index so that the nodes are not required to propose their values at each round.

Consequently, except for the first round, the running time of each round reduces to 2λ, where λ is a time bound for the messages between any two correct nodes. The blocks may pertain to a single block chain.

The VRF has three benefits compared to the VRF in the prior art. The verifiable random function used in the prior art is Hash(Sig_skj(Q_i−1; x)), where Q_i−1 is the randomness from the previous block. It is troublesome whether an adversary can choose to propose a block depends on the randomness of that adversary's block. If the randomness has advantage for Byzantine nodes (e.g. the probability of proposing a block for next block), then the adversary proposes the block. Thus, the overall advantage of the adversary increases up to (1/3)/(1−1/3)=1/2. The main problem is that the proposer decides the block and the randomness at the same time. Therefore, this embodiment separates the permission of proposing a block and generating the randomness in order to avoid such bias attacks. Second, the configuration is more flexible to compute the function because each user can compute part of the VRF for any status at any time, say, Hash Sig_skj(x). At the beginning of each epoch, any user or node can get the CRS of the epoch and compute the probability of proposing a block in the epoch. However, The VRF of the prior art requires Q_i−1 to compute Q_i. Third, the configuration has better space consumption. This embodiment uses the same randomness for many blocks in one epoch. Thus, the space complexity is reduced by a constant.

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

Process 300 begins with step 302, in which the members in S_CRS generate a value R from a common reference string (CRS). An epoch consists of a specific number of blocks. The CRS is a public randomness generated by a deterministic algorithm for each epoch; no user in the system can predict the CRS of any future epoch. In an exemplary embodiment, the CRS of epoch i is updated by R_i=Hash(TSig(R_i−1)), where R_i is generated for the new block, and TSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks (i.e., the CRS nodes compute the randomness according to results from a previous epoch).

In another exemplary embodiment, the common reference string is defined as: R_i=(Sig_{authority}(R_i−1)) under Proof-of-Authority blockchain, where R_i is generated for the new block.

At step 304, each node in S_notary computes a value s associated to a value of a status, the status is the public predictable information of the block (e.g. shard ID, chain ID or block height), wherein the value s can be verified by other nodes. In an exemplary embodiment, one of node q in S_notary computes the value s, and other nodes can verify the value s with public key pk_q using zero-knowledge proofs (one party, usually called PROVER, to convince another party, called VERIFIER, that PROVER knows some facts without revealing to the VERIFIER any information about his knowledge).

At step 306, each node in S_notary computes a value r by taking value s into a function H, where the function H may be a Hash function. The value r can be verified with the public key and the value s by other nodes. The value r may be unpredictable and unique to other nodes.

At step 308 the node in S_notary determines which node obtains a right to issue a new block by taking the value R and r into a function V. The function V is the verifiable random function (VRF), defined as: |R_i−Hash(Sig(status))| where, the R_i is the value R and Hash(Sig(status)) is verified by the public key. The node obtains the right to issue the new block when a calculated value for the function V is minimum at the node by comparing with other calculated values for the function at other nodes. To determine which node obtains the right to issue a block by computing:

l _q=arg min_j∈Uq|R_i−Hash(Sig_j(status))|

Where, l_q is the node obtaining the right or the leader of node q, the U_q is the set of nodes whose signatures are valid, and Sig_skj(status) is the digital signature of the status at the node j. This embodiment serves to minimize the communication cost so that a large population can join the protocol. The determination is independent of the round index, so the nodes are not required to propose their values at each round. Consequently, except for the first round, the running time of each round reduces to 2λ, where λ is a time bound for the messages between any two correct nodes. The blocks may pertain to a single block chain.

FIG. 4 is a timeline diagram, in accordance with some exemplary embodiments of the disclosed subject matter. Those skilled in the art will appreciate the method illustrated by the flowchart of FIG. 4 is merely exemplary and that alternate variations may be employed, all in accordance with the present technique.

The timeline 400 shows the method for building a single chain of the present invention, the method providing: a single blockchain 402; a plurality of randomness R_i 404, R_i+1 406 and R_i+2 408 of a CRS chain 418; a plurality of epoch: epoch i−1 410, epoch i 412, epoch i+1 414 and epoch i+2 416; and a plurality of valid nodes set S_nodeⁱ⁻¹, S_nodeⁱ and S_nodeⁱ⁺¹.

Any user with enough deposit can register its own public key in the blockchain 402. The users who want to enter or leave S_node can announce the request. The request will be recorded in the blocks. The node is called valid if it owns enough deposit and has registered a valid public key. The set S_nodeⁱ⁺¹ can be updated by S_nodeⁱ and the blocks in the epoch i 412.

The members in S_CRS are responsible for updating the CRS chain 418. The members in S_notary have right to propose a block and are responsible for deciding whose block can be chosen for the single chain 402. The decision of whose block can be chosen is determined by the public predictable information status, R_i 404 and the private keys, the node in S_notary compute the value |R_i−Hash (Sig_skq(status))| locally.

The members in S_CRS and S_notary are re-elected for each epoch. Each epoch i correspond to the randomness R_i 404 of CRS chain 418. When S_CRS is re-elected, the members in S_CRS will update the CRS chain 418 for the next epoch. In an exemplary embodiment, the set S_CRSⁱ and the set S_notaryⁱ are the CRS set and the notary set of epoch i 412. The set S_CRSⁱ, the set S_notaryⁱ and the randomness R_i 404 are decided before the epoch i 412 starts. When the epoch i 412 starts, the members in S_CRSⁱ generate the randomness R_i+1 406 as: R_i+1=Hash(TSig(R_i)), where TSig(R_i) is the threshold signature signed by the nodes in S_CRSⁱ. After R_i+1406 is decided, the set S_CRSⁱ⁺¹ and the set S_notaryⁱ⁺¹ can be elected by Fisher-Yate shuffle with the randomness R_i+1406 from the set S_nodeⁱ. Finally, the members in S_CRSⁱ⁺¹ and S_notaryⁱ⁺¹ run the key generation algorithm of the threshold signature scheme, respectively.

According to the present invention, the method and system for a node to issue a new block for building an agreed single chain by using the common reference string (CRS) and verifiable random function (VRF). It minimizes the communication cost and reduces the time bound so that achieving high decentralization and low latency.

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.

Claims

1. A method for a node to issue a new block in a distributed system including a plurality of blocks, comprising: determining a value R from a common reference string;computing a value s associated to a value of a status with a private key at a node;computing a value r by taking the value s into a function H at the node; anddetermining whether the node obtains a right to issue a new block by taking the values R and r into a function V.

2. The method of claim 1, wherein the private key is a private signing key corresponding to the node.

3. The method of claim 2, wherein the value s can only be computed by the node with the private key.

4. The method of claim 2, wherein the value r is unpredictable and unique to other nodes.

5. The method of claim 1, wherein the value r can be verified with a public key and the value s.

6. The method of claim 1, wherein the status can be defined to be a shard ID of the block.

7. The method of claim 1, wherein the status can be defined to be a chain ID of the block.

8. The method of claim 1, wherein the status can be defined to be a height of the block.

9. The method of claim 1, wherein the common reference string is a public randomness generated by a deterministic algorithm for each epoch.

10. The method of claim 9, wherein the epoch consists of a specific number of blocks.

11. The method of claim 10, wherein the common reference string is defined as: Ri=Hash(TSig(Ri−1)), where Ri is generated for the new block, andTSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks.

12. The method of claim 10, wherein the common reference string is defined as: Ri=(Sig_{authority}(Ri−1)), where Ri is generated for the new block.

13. The method of claim 1, wherein the function H is a hash function.

14. The method of claim 13, wherein the function V is defined as: |Ri−Hash(Sigsk(status))|, where Ri is the value R andHash(Sigsk(status)) is verified by a public key.

15. The method of claim 14, wherein the node obtains the right to issue the new block when a calculated value for the function V is minimum at the node by comparing with other calculated values for the function at other nodes.

16. The method of claim 14, wherein the blocks pertain to a single block chain.

17. A method for a node to issue a new block in a distributed system including a plurality of blocks, comprising: determining a value R from a common reference string;computing a value s associated to a value of a status at a node, wherein the value s can be verified by other nodes;computing a value r by taking the value s into a function H at the node; and

18. The method of claim 17, wherein the value r is unpredictable and unique to other nodes.

19. The method of claim 17, the value r can be verified with a public key and the value s.

20. The method of claim 17, wherein the status can be defined to be a shard ID of the block.

21. The method of claim 17, wherein the status can be defined to be a chain ID of the block.

22. The method of claim 17, wherein the status can be defined to be a height of the block.

23. The method of claim 17, wherein the common reference string is a public randomness generated by a deterministic algorithm for each epoch.

24. The method of claim 23, wherein the epoch consists of a specific number of blocks.

25. The method of claim 24, wherein the common reference string is defined as: Ri=Hash(TSig(Ri−1)), where R is generated for the new block, andTSig(⋅) is a threshold signature function whose input is some set of share-signatures produced during previous blocks.

26. The method of claim 24, wherein the common reference string is defined as: Ri=(Sig_{authority}(Ri−1)), where Ri is generated for the new block.

27. The method of claim 1, wherein the function H is a hash function.

28. The method of claim 27, wherein the function V is defined as: |Ri−Hash(Sig(status))|, where R is the value R andHash(Sig(status)) is verified by a public key.

29. The method of claim 27, wherein the node obtains the right to issue the new block when a calculated value for the function V is minimum at the node by comparing with other calculated values for the function at other nodes.

30. The method of claim 29, wherein the blocks pertain to a single block chain.

31. A distributed system including a plurality of blocks comprising: a plurality of first nodes determining a value R from a common reference string; anda plurality of second nodes computing a value s associated to a value of a status and computing a value r by taking the value s into a function H, and allowing one of the second nodes to issue a new block by taking the values R and r into a function V;wherein the plurality of first nodes and the plurality of second nodes are connected to each other via an internet.