CN114389815A - Method for electing nodes in a blockchain network and related product - Google Patents
Method for electing nodes in a blockchain network and related product Download PDFInfo
- Publication number
- CN114389815A CN114389815A CN202111511719.8A CN202111511719A CN114389815A CN 114389815 A CN114389815 A CN 114389815A CN 202111511719 A CN202111511719 A CN 202111511719A CN 114389815 A CN114389815 A CN 114389815A
- Authority
- CN
- China
- Prior art keywords
- block
- node
- proposal
- nodes
- proof
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 61
- 238000004590 computer program Methods 0.000 claims abstract description 5
- 230000006870 function Effects 0.000 claims description 37
- 238000012795 verification Methods 0.000 claims description 22
- 238000012545 processing Methods 0.000 claims description 9
- 230000004044 response Effects 0.000 claims description 7
- 238000004422 calculation algorithm Methods 0.000 abstract description 9
- 230000008569 process Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- OLBCVFGFOZPWHH-UHFFFAOYSA-N propofol Chemical compound CC(C)C1=CC=CC(C(C)C)=C1O OLBCVFGFOZPWHH-UHFFFAOYSA-N 0.000 description 3
- 229960004134 propofol Drugs 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
Abstract
The present invention relates to a method, apparatus, blockchain system and computer program product for electing nodes in a blockchain network, wherein the blockchain network comprises a plurality of consensus nodes, wherein the plurality of consensus nodes comprises a proposal node responsible for blockchain proposal and other nodes, wherein the method comprises performing the following operations at the other nodes: receiving ith block proposal information sent by a proposal node of an ith block, wherein the ith block proposal information comprises a certification set of an (i + 1) th block; extracting a certification set of the i +1 block from the ith block proposal information; and determining a proposed node of an i +1 th block based on the attestation set of the i +1 th block and the attribute information of the plurality of consensus nodes, wherein i is an integer greater than zero, and the i +1 th block is a next neighboring block of the i-th block. By the technical scheme of the invention, the safety of the block chain consensus algorithm can be effectively improved.
Description
Technical Field
The present invention relates generally to the field of blockchain technology. More particularly, the present invention relates to a method, apparatus, blockchain system and computer program product for electing nodes in a blockchain network.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Thus, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The blockchain system is a decentralized distributed accounting system, and the blockchain consensus algorithm is a core part in the blockchain system. Generally, the blockchain consensus algorithm can be divided into a plurality of types according to a dominating strategy, wherein a more common type is an election-type consensus algorithm. The election type consensus algorithm mainly refers to the selection of accounting nodes of the current round in each round of consensus process, and the election process specifically relates to the fact that each node judges nodes of the next round (namely proposal nodes) in advance according to the current round information and the weight values of the nodes. Therefore, the election mode has strong regularity for node election, so that malicious nodes can easily predict and attack nodes elected in the next round, and certain potential safety hazards exist.
Disclosure of Invention
To solve at least the technical problems described in the background section above, the present invention proposes a scheme for electing nodes in a blockchain network. By using the scheme of the invention, the consensus node in the block chain network can calculate the proposal node of the next block based on the proof set in the current block proposal information, thereby realizing the random election of the proposal node. Therefore, the scheme of the invention can effectively improve the safety of the block chain consensus algorithm. In view of this, the present invention provides solutions in the following aspects.
A first aspect of the present invention provides a method for electing a node in a blockchain network, wherein the blockchain network comprises a plurality of consensus nodes, wherein the plurality of consensus nodes comprises a proposal node responsible for blockchain proposals and other nodes, the method comprising performing the following at the other nodes: receiving ith block proposal information sent by a proposal node of an ith block, wherein the ith block proposal information comprises a certification set of an (i + 1) th block; extracting a certification set of the i +1 block from the ith block proposal information; and determining a proposed node of an i +1 th block based on the attestation set of the i +1 th block and the attribute information of the plurality of consensus nodes, wherein i is an integer greater than zero, and the i +1 th block is a next neighboring block of the i-th block.
In one embodiment, further comprising: generating a certification of the (i + 2) th block; and sending the certification of the (i + 2) th block to a proposal node of the (i + 1) th block, wherein the (i + 2) th block is a next adjacent block of the (i + 1) th block.
In one embodiment, wherein each consensus node is configured with a key, wherein generating the proof of the (i + 2) th block comprises: acquiring a height value of the (i + 2) th block; and processing a private key in a local secret key and the height value of the (i + 2) th block by using a verifiable random function to obtain the certification of the (i + 2) th block.
In one embodiment, wherein extracting the attestation set for the (i + 1) th block from the ith block proposal information comprises: carrying out validity verification on the source of the ith block proposal information; and responding to the verification of the validity of the source of the ith block proposal information, and executing the operation of extracting the certification set of the (i + 1) th block.
In one embodiment, the determining the proposed node of the (i + 1) th block comprises: processing the proof set of the (i + 1) th block and the attribute information of the plurality of consensus nodes by using a predetermined function to determine a proposed node of the (i + 1) th block based on a processing result.
In one embodiment, wherein the method further comprises: when i is 1, determining a proposed node of the 1 st block according to the created block information of the plurality of common nodes; generating a proof of block 2; and sending the proof of the 2 nd block to the proposal node of the 1 st block.
A second aspect of the present invention provides a method for electing a node in a blockchain network, wherein the blockchain network comprises a plurality of consensus nodes, wherein the plurality of consensus nodes comprises a proposal node responsible for blockchain proposal and other nodes, the method comprising performing the following at the proposal node responsible for blockchain proposal: receiving the certification of the (i + 1) th block sent by the other nodes; determining a set of credentials for the i +1 th block based on the received credentials for all i +1 th blocks; generating ith block proposal information containing the proof set of the (i + 1) th block; broadcasting the ith block proposal information to the other nodes to enable the other nodes to determine a proposal node of an (i + 1) th block based on the ith block proposal information, wherein i is an integer greater than zero, and the (i + 1) th block is a next adjacent block of the ith block.
In one embodiment, wherein determining the attestation set for the (i + 1) th block comprises: carrying out validity verification on the received proofs of all the (i + 1) th blocks; collecting the proof of the (i + 1) th block passing the validity verification into the proof set of the (i + 1) th block.
In one embodiment, wherein the attestation of each (i + 1) th chunk is determined based on a private key of the sending node and a height value of the (i + 1) th chunk, including attestation content encrypted with the private key, wherein legally verifying the received attestation of all (i + 1) th chunks comprises: acquiring a public key of a certified sending node of each (i + 1) th block; and verifying the public key of the sending node, the certification content encrypted by the private key and the height value of the (i + 1) th block by using a verifiable random function so as to verify the validity of the certification of each (i + 1) th block.
A third aspect of the invention provides an apparatus comprising: a processor; and a memory storing computer instructions for electing a node in a blockchain network, which when executed by the processor, cause the apparatus to perform the method of the foregoing first aspect and in the following embodiments or to perform the method of the foregoing second aspect and in the following embodiments.
A fourth aspect of the present invention provides a computer program product comprising program instructions for electing a node in a blockchain network, which when executed by a processor, cause the method of the first aspect and in the following embodiments to be carried out or the method of the second aspect and in the following embodiments to be carried out.
A fifth aspect of the present invention provides a blockchain system, comprising: a plurality of consensus nodes, wherein the plurality of consensus nodes comprises a proposal node responsible for block proposal and other nodes, the proposal node being configured to broadcast current block proposal information to the other nodes according to the method described in the second aspect above and in the embodiments below, the other nodes being configured to perform the method according to the first aspect above and in the embodiments below to determine a proposal node for a next block based on the current block proposal information.
By using the scheme provided by the invention, the consensus node in the block chain can calculate the proposal node of the next block according to the proof set in the current block proposal information. Specifically, the certification set in the current block proposal information includes the certification of the next block by a plurality of consensus nodes, and each consensus node cannot predict the certification of the next block by nodes other than itself. In particular, the introduction of verifiable random functions in the generation of the proof makes the generation of the proof more secure and the generated proof more random and confidential. Based on the method, the proposal nodes calculated by the proof set have randomness, so that the prediction of malicious nodes on the proposal nodes can be effectively avoided, and the safety of the block chain consensus algorithm is improved.
Drawings
The above and other objects, features and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or corresponding parts and in which:
FIG. 1 is an architecture diagram illustrating a blockchain network according to an embodiment of the present invention;
FIG. 2 is a flow diagram illustrating a method for electing a node in a blockchain network according to an embodiment of the present invention;
FIG. 3 is a flow diagram illustrating another method for electing nodes in a blockchain network according to an embodiment of the present invention; and
fig. 4 is a structural diagram illustrating a consensus node according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without making creative efforts based on the embodiments of the present invention, belong to the protection scope of the present invention.
It should be understood that the terms "first", "second", "third" and "fourth", etc. in the claims, the description and the drawings of the present invention are used for distinguishing different objects and are not used for describing a particular order. The terms "comprises" and "comprising," when used in the specification and claims of this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and claims of this application, the singular form of "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the specification and claims of this specification refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.
As used in this specification and claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".
The following detailed description of embodiments of the invention refers to the accompanying drawings.
In order to better understand the solution of the present invention, a block chain network will be briefly described below with reference to fig. 1.
Fig. 1 is an architecture diagram 100 illustrating a blockchain network in accordance with an embodiment of the present invention. The blockchain network may include a plurality of consensus nodes, where a consensus node may be understood as a node in the blockchain network that may share blockchain data and may participate in the blockchain consensus process.
As shown in fig. 1, the blockchain network may include A, B, C, D four consensus nodes and be formed by a network of nodes A, B, C, D. It is to be understood that the block chain network is illustrated with four common nodes for illustrative purposes only, and the number of common nodes in the block chain network is not limited. In one embodiment, each time there is a "block out" request, a proposal node needs to be elected from the consensus nodes of the blockchain network to propose the block. For the election of the proposed node, the background technology of the invention refers to that the node is elected by using the round information and the node weight information, so that the node is easily predicted and attacked by a malicious node. In order to solve this technical problem, the present invention proposes a technical solution as shown in fig. 2.
Fig. 2 is a flow diagram illustrating a method 200 for electing a node in a blockchain network according to an embodiment of the present invention. The blockchain network may include a plurality of consensus nodes, where the plurality of consensus nodes may include other nodes and a proposal node responsible for blockchain proposal, and each other node may perform the steps shown in fig. 2. It is understood that the blockchain network and the consensus node herein may have the same general properties as the blockchain network and the consensus node described above in connection with fig. 1, and further performance optimization and improvement is obtained by the solution of the present invention.
For each of the aforementioned other nodes, at step S201, the ith block proposal information sent by the proposal node of the ith block may be received. In some implementation scenarios, the aforementioned ith chunk proposal information may include a certification set of the (i + 1) th chunk. In this scenario, the attestation set for the (i + 1) th chunk may include attestation of the (i + 1) th chunk by each of the aforementioned other nodes, and the generation process of each attestation may involve the height value of the chunk and the private key of the node. Here, i is an integer greater than zero, and the aforementioned i +1 th block is a next adjacent block to the i-th block.
In one embodiment, each of the aforementioned common nodes is configured with a key, and the certification of the (i + 1) th block by each of the other nodes can be obtained by processing a private key in the local key and the height value of the (i + 1) th block by using a verifiable random function. For example, the proof may be obtained by proof of vrf. createproof (keypair. privatekey, block. height). Key pair. A Verifiable Random Function (VRF) is an encryption scheme that maps an input to a Verifiable pseudo-Random output, and the result is a Random number, and has the advantages of verifiability, uniqueness, randomness, and the like. Based on this, the certificates in the certificate set have the advantages of verifiability, uniqueness, randomness and the like. It is to be understood that the present disclosure of a collection of instructions and the description thereof is illustrative only and is not limiting upon the scope of the present invention.
Next, at step S202, a certification set of i +1 tiles may be extracted from the aforementioned ith tile proposal information. In some implementation scenarios, the source of the i-th block proposal information may be legally verified, and the extraction operation of the certification set is performed after the legality verification is passed, so as to effectively avoid the interference information from the malicious node. In this scenario, the validity verification of the source of the ith block proposal information may be implemented by using a predetermined function. Specifically, when i is equal to 1, the function proposer seekbeygenesis (genetics, [ a, B, C, D ]) may be used to verify the source of the 1 st block proposal information. When i is greater than or equal to 2, the function ProposeSeek (ProofSet < i >, [ A, B, C, D ]) can be used to verify the source of the i-th block proposal information. Where proffset < i > denotes the proof set of the ith tile and A, B, C, D denotes the respective consensus nodes in the tile chain, the predetermined function is illustrated here with four consensus nodes for illustrative purposes only and without limiting the number of consensus nodes in the tile chain network. It is to be understood that the description herein of the validity verification of the source of the proposal information is merely an exemplary illustration and the inventive arrangements are not so limited.
Next, at step S203, a proposed node of the (i + 1) th block may be determined based on the aforementioned attestation set of the (i + 1) th block and attribute information of the plurality of consensus nodes. In one embodiment, the proposed node of the (i + 1) th block may be determined using a function promoserseek (promoset < i +1>, [ a, B, C, D ]). Where proffset < i +1> is the attestation set for the i +1 th tile, and A, B, C, D represents each consensus node in the tile chain, whose attribute information may include, but is not limited to, network address information. The determination process of the proposed node is exemplarily illustrated by taking four consensus nodes as an example, and the number of the consensus nodes in the blockchain network is not limited. Further, the various functions referred to above and in the following discussion are exemplary only and not intended to be limiting, and those skilled in the art may also appreciate that other suitable functions or algorithms may be used to perform operations such as generating a proof or determining a proposed node in accordance with the teachings of the present invention and still fall within the scope of the present invention.
In one embodiment, the determination of the proposed node for block 1 may specifically relate to creation block information of each consensus node in the blockchain network. In this scenario, during the initial operation phase of each consensus node in the blockchain network, the created block information of each consensus node is consistent, and the proposed node of the 1 st block can be determined by using the function proposer seek bygenes (genetics, [ a, B, C, D ]). A specific calculation process may involve performing a hash operation on the created blocks of the respective consensus nodes to obtain a hash value. Then, the node number is modulo-operated by the hash value to obtain the proposed node of the 1 st block.
In one embodiment, each time a proposal node for a block is determined, a proof of a next neighboring block to the block may be generated and sent to the block. For example, after determining the proposal node of block 1, the certification of block 2 may be generated and sent to the proposal node of block 1 during the whole life cycle of the blockchain network. And after determining the proposal node of block 2, may generate the certification of block 3 and send the certification of block 3 to the proposal node of block 2, and so on.
Fig. 3 is a flow diagram illustrating another method 300 for electing nodes in a blockchain network in accordance with an embodiment of the present invention. The blockchain network may include a plurality of consensus nodes, wherein the plurality of consensus nodes may include other nodes and a proposal node responsible for the blockchain proposal, and the proposal node may perform the steps shown in fig. 3. It will be appreciated that the blockchain network and consensus node herein may have the same general attributes as the blockchain network and consensus node described above in connection with fig. 1, and may be the blockchain network and consensus node described above in connection with fig. 2.
At step S301, a certification of the i +1 th block sent by other nodes may be received. In one embodiment, as described above, the proof of the (i + 1) th block may be determined by the other nodes using verifiable random functions to process the local private key and the height value of the (i + 1) th block. Next, at step S302, a certification set for the (i + 1) th chunk may be determined based on the received certifications of all the (i + 1) th chunks. In one embodiment, the certification of each i +1 th block includes the certification content encrypted by the private key, the public key of each of the other nodes, the certification content, and the height value of the i +1 th block may be verified by a verifiable random function (e.g., the function vrf. verifyprofo) to achieve validity verification of each certification in the certification set, and the certification of the i +1 th block passing the validity verification is collected into the certification set of the i +1 th block. The size of the proof set needs to be larger than a threshold, for example, may be larger than or equal to half the number of nodes in the blockchain network. It should be understood that the description of the instruction set is only an exemplary illustration and not a limitation of the technical solution of the present invention.
Next, in step S303, the ith chunk proposal information including the certification set of the (i + 1) th chunk may be generated. In one embodiment, the proposal node of the ith block may generate the proposal information of the ith block after the validity verification of the proof set of the (i + 1) th block passes. The ith chunk proposal information may include related information of the ith chunk and a certification set of the (i + 1) th chunk, where i is an integer greater than zero, and the (i + 1) th chunk is a next neighboring chunk of the ith chunk. Next, in step S304, the ith block proposal information may be broadcasted to the other nodes. Based on this, the other node can determine the proposed node of the (i + 1) th block based on the above-mentioned i-th block proposal information. The determination process for the proposal node can specifically refer to the determination process for the proposal node of the 1 st block and the proposal node of the ith block (i ≧ 2) described in FIG. 2.
In order to better understand the technical solution of the present invention, the technical solution of the present invention will be further described below by taking the consensus node A, B, C and D in fig. 1 as an example.
An initialization starting stage: a, B, C and D four common nodes in the blockchain network are set to be in an initial operation state. In some implementations, each consensus node is configured with a collection of public and private key pairs (KeyPair) and instantiates a VRF object. Where VRF objects can support the generation of proofs and validation of legitimacy. For example, the proof may be generated by a function proof of vrf.createproof (keypair.privatekey, block.height), where keypair.privatekey represents the private key and block.height represents the block height value. The validity of the certification can be verified through a function vrf, proof of, public key, proof of, Data, block, height, where public key represents a public key corresponding to keypair. When vrf. verfiypproof returns true, it indicates that it is valid.
When a common node in a block chain network is just started, it is necessary to determine which common node is responsible for proposal of block 1 (i.e., block.height ═ 1). Since the information of the created block of each consensus node is consistent in the initial state of the system, the proposed node of block 1 can be derived using the information of the created block. In one embodiment, the derivation may be performed using the function ProposesekByGenesis. Specifically, hash operation may be performed on the created block, and then the node number is modulo-operated by using the obtained hash value, so as to obtain the proposed node of the block 1.
Assume that it is determined that node a is the proposed node of block 1 through the above calculation, i.e., a ═ propolseseekbeygenes (genetics, [ a, B, C, D ]). Then, nodes B, C and D may respectively create a proof for tile 2:
proof_b<2>＝B.VRF.CreateProof(B.KeyPair.PrivateKey,2)；
proof_c<2>＝C.VRF.CreateProof(C.KeyPair.PrivateKey,2)；
proof_d<2>＝D.VRF.CreateProof(D.KeyPair.PrivateKey,2)。
nodes B, C and D then send the respective created credentials to node A. After node A receives the proofs proof _ b <2>, proof _ c <2> and proof _ D <2> for chunk 2, it sends a response back to nodes B, C and D, respectively. And the startup phase of the system is completed when nodes B, C and D in turn receive responses back from node a.
And (3) an operation stage: node a, upon receiving the proof for block 2, needs to verify the validity of the proof using a function (e.g., vrf. verifyprofo) and, upon determining that the proof is valid, collects it into the proof set for block 2. In one embodiment, the validity verification process for the proof of Block 2 may include verification of proof _ b <2>, proof _ c <2>, and proof _ d <2>. For example, the legitimacy of proof _ b <2> is verified using a.vrf.verify proof of proof _ b <2>. public key, proof _ b.data,2), the legitimacy of proof _ c <2> is verified using a.vrf.verify of proof _ c <2>. public key, proof _ c.data,2), and the legitimacy of proof _ d <2> is verified using the function a.vrf.verify of proof _ d <2>. public key, proof _ d.data, 2).
Node a may not only obtain the proof set ProofSet <2> for block 2, but also need to be responsible for the proposal for block 1. Then, the Proposal Proposal _1 (where Proposal _1 includes ProofSet <2>) is broadcast to nodes B, C and D. Then, after receiving the Proposal, Proposal _1, nodes B, C and D may verify the validity of Proposal _1 using the function ProposesekByGenesis (genetics, [ A, B, C, D ]). Then, after the validity verification is completed, each consensus node generates a Vote Vote _1 for the Proposal Propusal _1, and sends the Vote Vote _1 to the Proposal node of block 2. In one embodiment, the specific process of generating the Vote Vote _1 for Proposal _1 may involve creating a proof of block 3, appending the proof of block 3 into the Vote, and computing the Proposal node for block 2.
The voting process will be further described below by taking the node B as an example. Specifically, the proof _ b <3> -b.vrf.createproof (b.keypay.privatekey, 3) may be created using the function proof _ b <3> -b.vrf.createproof (b.keypay.privatekey, 3). Next, a proof may be appended to Vote _ b _1 (e.g., Vote _ b _1.Assgin (proof _ b <3 >)). Next, the proposed node of block 2 can be calculated using the function C ═ promoseek (ProofSet <2>, [ a, B, C, D ]) (assuming that the proposed node of block 2 is C). Vote _ b _1 is then sent to node C. Similarly, node a and node D may transmit volume _ a _1 and volume _ D _1 to node C with reference to the voting process of node B.
When receiving Vote information such as Vote _ a _1, Vote _ b _1 and Vote _ d _1, the node C analyzes the proof of proof _ a <3>, proof _ b <3> and proof _ d <3> of the block 3 in the Vote information. The legitimacy of the proof needs to be verified using a function (e.g., vrf. verifyprofo) and collected into the proof set of block 3 when it is determined that the proof is valid. In one embodiment, the validity verification process for the proof of block 3 may include verification of proof _ a <3>, proof _ b <3>, and proof _ d <3>. For example, the legitimacy of proof _ a <3> can be verified using the function a.vrf.verify (proof _ a <3>. PublicKey, proof _ a.data,3), the legitimacy of proof _ b <3> can be verified using a.vrf.verify proof of (proof _ b <3>. PublicKey, proof _ b.data,3), and the legitimacy of proof _ d <3> can be verified using the function a.vrf.verify of (proof _ d <3>. PublicKey, proof _ d.data, 3).
Node C not only can obtain the proof set ProofSet <3> for block 3, but also needs to be responsible for the proposal for block 2. Then, Proposal Proposal _2 (where Proposal _2 includes ProofSet <3>) is broadcast to nodes A, B and D. Then, after receiving the proposed propofol _2, the nodes A, B and D may verify the validity of the propofol _2 using the function propofol seek (proffset <2>, [ a, B, C, D ]). Then, after the validity verification is completed, each consensus node will generate a Vote Vote _2 for the Proposal Propusal _2, and send the Vote Vote _2 to the Proposal node of block 3. In one embodiment, the specific process of generating the Vote Vote _2 for Proposal _2 may involve creating a proof of block 4, appending the proof of block 4 into the Vote, and computing the Proposal node for block 3.
The voting process will be further described below by taking node D as an example. Specifically, the proof _ d <4> -d.vrf.createproof (d.keypay.privatekey, 4) may be created using the function proof _ d <4> -d.vrf.createproof (d.keypay.privatekey, 4). Next, a proof may be appended to Vote _ d _2 (e.g., Vote _ d _2.Assgin (proof _ d <4 >)). Next, the proposed node of block 3 (assuming that the proposed node of block 3 is a) can be calculated by using the function a ═ properseek (ProofSet <3>, [ a, B, C, D ]). Then, Vote _ d _2 is sent to node A. Similarly, node B and node C may transmit volume _ B _2 and volume _ C _2 to node a with reference to the voting process of node D.
When receiving Vote information such as Vote _ b _2, Vote _ c _2 and Vote _ d _2, the node A analyzes the proof _ b <4>, proof _ c <4> and proof _ d <4> of the block 4 in the Vote information. The legitimacy of the proof needs to be verified using a function (e.g., vrf. verifyprofo) and collected into the proof set of block 4 when it is determined that the proof is valid. In one embodiment, the validity verification process for the proof of block 4 may include verification of proof _ b <4>, proof _ c <4>, and proof _ d <4>. For example, the legitimacy of proof _ b <4> can be verified using the function a.vrf.verify (proof _ b <4>. public key, proof _ a.data,4), the legitimacy of proof _ c <4> can be verified using a.vrf.verify proof of proof _ c <4>. public key, proof _ c.data,4), and the legitimacy of proof _ d <4> can be verified using the function a.vrf.verify (proof _ d <4>. public key, proof _ d.data, 4).
The above process continues to loop with the appearance of new tiles in the blockchain network. When the proposed nodes of the block are determined in a circulating mode each time, each consensus node cannot predict the certificate created by the node other than the consensus node, namely the certificate created by each consensus node is random relative to other nodes. Based on this, the proposed nodes calculated in real time by the proof set have randomness, so that the prediction of malicious nodes on the proposed nodes can be effectively avoided, and the safety of the block chain consensus algorithm is improved.
Fig. 4 is a schematic block diagram illustrating a consensus node 400 according to an embodiment of the present invention. The consensus node 400 may comprise a device 401 according to an embodiment of the present invention as well as its peripherals and external networks. As mentioned above, the consensus node (e.g. via the apparatus 401) implements operations such as generating block proposal information comprising a certification set of blocks or determining a proposal node of a block by using the block proposal information, so as to implement the scheme of the present invention as described above with reference to fig. 2 or fig. 3.
As shown in fig. 4, the device 401 may include a CPU4011, which may be a general-purpose CPU, a dedicated CPU, or an execution unit on which other information processing and programs run. Further, the device 401 may further include a mass storage 4012 and a read only memory ROM 4013, wherein the mass storage 4012 may be configured to store various kinds of data including block information, certification, proposal information, etc., and various programs required for a blockchain network, and the ROM 4013 may be configured to store a power-on self test for the device 401, initialization of various functional modules in the system, a driver of basic input/output of the system, and data required for booting an operating system.
Further, the device 401 may also include other hardware platforms or components, such as a TPU (Tensor Processing Unit) 4014, a GPU (Graphic Processing Unit) 4015, an FPGA (Field Programmable Gate Array) 4016, and an mlu (memory Logic Unit), memory Logic Unit) 4017, as shown. It is to be understood that although various hardware platforms or components are shown in the device 401, this is by way of example and not by way of limitation, and those skilled in the art may add or remove corresponding hardware as may be desired. For example, the device 401 may include only a CPU as a well-known hardware platform and another hardware platform as a test hardware platform of the present invention.
The device 401 of the present invention further comprises a communication interface 4018 such that it can be connected via the communication interface 4018 to a local area network/wireless local area network (LAN/WLAN)405, which in turn can be connected via the LAN/WLAN to a local server 406 or to the Internet ("Internet") 407 and remote servers 408 and 409. Alternatively or additionally, the inventive device 401 may also be connected directly to the internet or cellular network over the communication interface 4018 based on wireless communication technology, e.g., third generation ("3G"), fourth generation ("4G"), or 5 generation ("5G").
The peripheral devices of the apparatus 401 may include a display device 402, an input device 403, and a data transmission interface 404. In one embodiment, the display device 402 may, for example, include one or more speakers and/or one or more visual displays 4. Input devices 403 may include, for example, a keyboard, a mouse, a microphone, a gesture capture camera, or other input buttons or controls configured to receive input of data or user instructions. The data transfer interface 404 may include, for example, a serial interface, a parallel interface, or a universal serial bus interface ("USB"), a small computer system interface ("SCSI"), serial ATA, FireWire ("FireWire"), PCI Express, and a high-definition multimedia interface ("HDMI"), which are configured for data transfer and interaction with other devices or systems.
The above-mentioned CPU4011, mass memory 4012, read only memory ROM 4013, TPU 4014, GPU 4015, FPGA 4016, MLU 4017 and communication interface 4018 of the device 401 of the present invention can be connected to each other through a bus 4019, and data interaction with peripheral devices is realized through the bus. Through this bus 4019, the CPU4011 can control other hardware components in the device 401 and their peripherals, in one embodiment.
In operation, the processor CPU4011 of the apparatus 401 of the present invention can obtain the block proposal information of a proposal node or the block certification of other nodes through the input device 403 or the data transmission interface 404, and call computer program instructions or code stored in the memory 4012 to process the obtained information in order to determine the proposal node of the block.
From the above description of the modular design of the present invention, it can be seen that the system of the present invention can be flexibly arranged according to application scenarios or requirements without being limited to the architecture shown in the accompanying drawings. Further, it should also be understood that any module, unit, component, server, computer, or device performing operations of examples of the invention may include or otherwise access a computer-readable medium, such as a storage medium, computer storage medium, or data storage device (removable) and/or non-removable) such as a magnetic disk, optical disk, or magnetic tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. In this regard, the present invention also discloses a computer readable storage medium having stored thereon computer readable instructions for electing a node in a blockchain network, the computer readable instructions, when executed by one or more processors, performing the method and operations previously described in conjunction with the figures.
While various embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions will occur to those skilled in the art without departing from the spirit and scope of the present invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that the module compositions, equivalents, or alternatives falling within the scope of these claims be covered thereby.
Claims (12)
1.A method for electing nodes in a blockchain network, wherein the blockchain network includes a plurality of consensus nodes, wherein the plurality of consensus nodes includes a proposal node responsible for blockchain proposals and other nodes, the method comprising performing the following at the other nodes:
receiving ith block proposal information sent by a proposal node of an ith block, wherein the ith block proposal information comprises a certification set of an (i + 1) th block;
extracting a certification set of the i +1 block from the ith block proposal information; and
determining a proposed node of an i +1 th block based on the attestation set of the i +1 th block and the attribute information of the plurality of consensus nodes, wherein i is an integer greater than zero and the i +1 th block is a next neighboring block of the i-th block.
2. The method of claim 1, further comprising:
generating a certification of the (i + 2) th block; and
sending a certification of the (i + 2) th block to a proposal node of the (i + 1) th block, wherein the (i + 2) th block is a next adjacent block of the (i + 1) th block.
3. The method of claim 2, wherein each consensus node is configured with a key, wherein generating the attestation of the (i + 2) th chunk comprises:
acquiring a height value of the (i + 2) th block;
and processing a private key in a local secret key and the height value of the (i + 2) th block by using a verifiable random function to obtain the certification of the (i + 2) th block.
4. The method of claim 1, wherein extracting the attestation set for the (i + 1) th block from the ith block proposal information comprises:
carrying out validity verification on the source of the ith block proposal information; and
and in response to the verification of the validity of the source of the ith block proposal information, executing the operation of extracting the certification set of the (i + 1) th block.
5. The method of any of claims 1 to 4, wherein determining a proposal node for an i +1 th block comprises:
processing the proof set of the (i + 1) th block and the attribute information of the plurality of consensus nodes by using a predetermined function to determine a proposed node of the (i + 1) th block based on a processing result.
6. The method of claim 5, wherein the method further comprises:
when i is 1, determining a proposed node of the 1 st block according to the created block information of the plurality of common nodes;
generating a proof of block 2; and
sending the attestation of the 2 nd block to the proposal node of the 1 st block.
7. A method for electing nodes in a blockchain network, wherein the blockchain network includes a plurality of consensus nodes, wherein the plurality of consensus nodes includes a proposal node responsible for blockchain proposal and other nodes the method comprising performing the following at the proposal node responsible for blockchain proposal:
receiving the certification of the (i + 1) th block sent by the other nodes;
determining a set of credentials for the i +1 th block based on the received credentials for all i +1 th blocks;
generating ith block proposal information containing the proof set of the (i + 1) th block;
broadcasting the ith block proposal information to the other nodes to enable the other nodes to determine a proposal node of an (i + 1) th block based on the ith block proposal information, wherein i is an integer greater than zero, and the (i + 1) th block is a next adjacent block of the ith block.
8. The method of claim 7, wherein determining the attestation set for the (i + 1) th block comprises:
carrying out validity verification on the received proofs of all the (i + 1) th blocks;
collecting the proof of the (i + 1) th block passing the validity verification into the proof set of the (i + 1) th block.
9. The method of claim 8, wherein the attestation of each (i + 1) th chunk is determined based on a private key of a sending node and a height value of the (i + 1) th chunk, including attestation content encrypted with the private key, wherein legally verifying the received attestation of all (i + 1) th chunks comprises:
acquiring a public key of a certified sending node of each (i + 1) th block;
and verifying the public key of the sending node, the certification content encrypted by the private key and the height value of the (i + 1) th block by using a verifiable random function so as to verify the validity of the certification of each (i + 1) th block.
10. An apparatus, comprising:
a processor; and
a memory storing computer instructions for electing a node in a blockchain network, which when executed by the processor, cause the apparatus to perform the method of any of claims 1-6 or perform the method of any of claims 7-9.
11. A computer program product comprising program instructions for electing a node in a blockchain network, which when executed by a processor cause the method according to any one of claims 1 to 6 or the method according to any one of claims 7 to 9 to be carried out.
12. A blockchain system, comprising:
a plurality of consensus nodes, wherein the plurality of consensus nodes comprises a proposal node responsible for block proposal and other nodes, the proposal node being configured to perform the method according to any of claims 7-9 to broadcast current block proposal information to the other nodes, the other nodes being configured to perform the method according to any of claims 1-6 to determine a proposal node for a next block based on the current block proposal information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111511719.8A CN114389815A (en) | 2021-12-06 | 2021-12-06 | Method for electing nodes in a blockchain network and related product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111511719.8A CN114389815A (en) | 2021-12-06 | 2021-12-06 | Method for electing nodes in a blockchain network and related product |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114389815A true CN114389815A (en) | 2022-04-22 |
Family
ID=81196132
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111511719.8A Pending CN114389815A (en) | 2021-12-06 | 2021-12-06 | Method for electing nodes in a blockchain network and related product |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114389815A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN108717630A (en) * | 2018-05-19 | 2018-10-30 | 上海分布信息科技有限公司 | One kind going out block method and its realizes system |
| CN110995439A (en) * | 2019-11-20 | 2020-04-10 | 上海链颉科技有限公司 | Block chain consensus method, electronic device and storage medium |
| US11157899B1 (en) * | 2019-05-28 | 2021-10-26 | Hiro Systems Pbc | System and method for bootstrapping a separate proof of work chain |
-
2021
- 2021-12-06 CN CN202111511719.8A patent/CN114389815A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN108717630A (en) * | 2018-05-19 | 2018-10-30 | 上海分布信息科技有限公司 | One kind going out block method and its realizes system |
| US11157899B1 (en) * | 2019-05-28 | 2021-10-26 | Hiro Systems Pbc | System and method for bootstrapping a separate proof of work chain |
| CN110995439A (en) * | 2019-11-20 | 2020-04-10 | 上海链颉科技有限公司 | Block chain consensus method, electronic device and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 徐蜜雪;苑超;王永娟;付金华;李斌;: "拟态区块链――区块链安全解决方案", 软件学报, no. 06 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Ibtihal et al. | Homomorphic encryption as a service for outsourced images in mobile cloud computing environment | |
| JP6636183B2 (en) | Block generation method, apparatus and block chain network | |
| Li et al. | OPoR: Enabling proof of retrievability in cloud computing with resource-constrained devices | |
| CN110213059B (en) | Random number generation method, random number generation device and storage medium | |
| CN111898137A (en) | Private data processing method, equipment and system for federated learning | |
| CN108769230B (en) | Transaction data storage method, device, server and storage medium | |
| CN110198233B (en) | Block chain consensus method and system based on trusted execution environment and directed acyclic graph | |
| EP2947840B1 (en) | Certificateless multi-agent signature method and apparatus | |
| US11825000B2 (en) | Asymmetric device attestation using physically unclonable functions | |
| CN112118239B (en) | Block chain consensus method and device, electronic equipment and storage medium | |
| CN113301114B (en) | Block chain consensus node selection method and device, computer equipment and storage medium | |
| Chow et al. | Server-aided signatures verification secure against collusion attack | |
| CN112631550A (en) | Block chain random number generation method, device, equipment and computer storage medium | |
| CN113065140B (en) | Embedded safety protection system and method for chip control protection device | |
| CN110990790B (en) | Data processing method and equipment | |
| JP6780771B2 (en) | Verification information granting device, verification device, information management system, method and program | |
| Meng et al. | Fast secure and anonymous key agreement against bad randomness for cloud computing | |
| CN113939821A (en) | System and method for non-parallel mining on a workload justification blockchain network | |
| JP2007143163A (en) | User authentication system in communication network and method thereof | |
| CN114389815A (en) | Method for electing nodes in a blockchain network and related product | |
| CN111400270A (en) | Block chain-based file time service method and device | |
| Tian et al. | Efficient identity-based multi-copy data sharing auditing scheme with decentralized trust management | |
| Li et al. | A noninteractive multireplica provable data possession scheme based on smart contract | |
| CN112751675B (en) | Information monitoring method, system, equipment and storage medium based on block chain | |
| CN114329424A (en) | Authority determination method and device, computer equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |