CN113254526A - Block chain consensus method, device and system - Google Patents

Block chain consensus method, device and system Download PDF

Info

Publication number
CN113254526A
CN113254526A CN202110228046.9A CN202110228046A CN113254526A CN 113254526 A CN113254526 A CN 113254526A CN 202110228046 A CN202110228046 A CN 202110228046A CN 113254526 A CN113254526 A CN 113254526A
Authority
CN
China
Prior art keywords
node
random number
message
preparation message
replica
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.)
Granted
Application number
CN202110228046.9A
Other languages
Chinese (zh)
Other versions
CN113254526B (en
Inventor
金键
谢家贵
郭健
李志平
张波
马旭锋
魏星
朱斯语
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Academy of Information and Communications Technology CAICT
Original Assignee
China Academy of Information and Communications Technology CAICT
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Academy of Information and Communications Technology CAICT filed Critical China Academy of Information and Communications Technology CAICT
Priority to CN202110228046.9A priority Critical patent/CN113254526B/en
Publication of CN113254526A publication Critical patent/CN113254526A/en
Application granted granted Critical
Publication of CN113254526B publication Critical patent/CN113254526B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Economics (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The embodiment of the application provides a block chain consensus method, a block chain consensus device and a block chain consensus system. The method is applied to the replica node in the blockchain system and comprises the following steps: broadcasting a first pre-preparation message in a blockchain system, and receiving a second pre-preparation message broadcast by other replica nodes, wherein the pre-preparation message broadcast by any replica node comprises a candidate block generated by the replica node and a random number; determining a target random number from random numbers respectively included in the first pre-preparation message and the second pre-preparation message, and determining a copy node generating the target random number in the system as a main node of the current view; and if the blockchain system is determined to be in consensus on the candidate blocks generated by the main node, writing the candidate blocks generated by the main node into the local blockchain. In this way, the probability that the master node in the view is predicted can be reduced, thereby reducing the risk of being attacked.

Description

Block chain consensus method, device and system
Technical Field
The present application relates to the field of blockchain technologies, and in particular, to a method, an apparatus, and a system for blockchain consensus.
Background
The Practical PBFT (physical Byzantine Fault Tolerance) algorithm can ensure the correctness of the system (for example, avoid forking) under the condition that the number of malicious nodes in the system is less than one third. When the practical Byzantine fault-tolerant algorithm is applied to a block chain network or a system, each block generated in the system is subjected to a round of consensus, each round of consensus corresponds to a view (view), each view comprises a primary node (primary) and a plurality of secondary nodes (backup), and the primary node and the plurality of secondary nodes are used for consensus on a certain block on the view. Starting from the first block, numbering each round of consensus, wherein the numbering is a view number.
The master node may also be referred to as a block initiator and the slave nodes may also be referred to as block verifiers. In the block-chain system, before beginning the byzantine consensus, a set of block verifiers needs to be specified first, sorted and assigned serial numbers to the block verifiers in the set, and then presented to all participants in the system. After determining the block verifier set, a block initiator needs to be selected from the block verifier set, and a block is generated by the block initiator and broadcasted in the system for subsequent consensus process.
However, in the existing practical byzantine fault-tolerant algorithm, the block initiator (i.e. the master node) selected in each round of consensus is easily predicted, and the risk of attack is very high.
Disclosure of Invention
The embodiment of the application provides a block chain consensus method, a block chain consensus device and a block chain consensus system, which are used for solving the problem that when a PBFT algorithm is applied to a block chain system, a main node of one round of consensus is easily predicted by an attacker to cause a high attacked risk.
According to a first aspect of the embodiments of the present application, there is provided a blockchain consensus method applied to a replica node in a blockchain system, the method including:
broadcasting a first pre-preparation message in the blockchain system, and receiving a second pre-preparation message broadcast by other replica nodes in the blockchain system, wherein the pre-preparation message broadcast by any replica node in the blockchain system comprises a candidate block generated by the replica node and a random number;
determining a target random number from random numbers respectively included in the first pre-preparation message and the second pre-preparation message, and determining a copy node generating the target random number in the blockchain system as a main node of a current view;
and if the blockchain system is determined to be in consensus on the candidate blocks generated by the main node, writing the candidate blocks generated by the main node into a local blockchain.
According to a second aspect of the embodiments of the present application, there is provided a blockchain consensus apparatus applied to a replica node in a blockchain system, the apparatus including:
a transceiver module, configured to broadcast a first pre-preparation message in the blockchain system, and receive a second pre-preparation message broadcast by other replica nodes in the blockchain system, where the pre-preparation message broadcast by any replica node in the blockchain system includes a candidate block generated by the replica node and a random number;
a master node selection module, configured to determine a target random number from random numbers included in the first pre-preparation message and the second pre-preparation message, and determine a replica node, which generates the target random number, in the blockchain system as a master node of a current view;
a consensus module for writing the candidate tiles generated by the master node into a local blockchain if it is determined that the blockchain system agrees on the candidate tiles generated by the master node.
According to a third aspect of the embodiments of the present application, there is provided a blockchain system, including a plurality of replica nodes, where at least 2f +1 replica nodes in the blockchain system perform consensus processing by the method provided in the first aspect of the embodiments of the present application, where f denotes the number of byzantine nodes in each replica node of the blockchain system, and f is an integer greater than 0.
According to a fourth aspect of embodiments herein, there is provided a computer-readable storage medium having stored thereon machine-executable instructions which, when executed, implement the method provided by the first aspect of embodiments herein.
In the scheme provided by the embodiment of the application, the replica node in the blockchain system generates the candidate block and the random number after a round of consensus starts, and the candidate block and the random number are carried in the pre-preparation message and broadcasted, so that other replica nodes can elect the master node based on the random number in the received pre-preparation message, and further perform a subsequent consensus process on the candidate block generated by the master node. Therefore, the method for safely and randomly electing the main node is provided, and the main node identified in one round is selected based on the random numbers generated by the copy nodes, so that compared with the main node determining method in the existing PBFT algorithm, the method reduces the prediction probability of the main node in the view for an attacker, and further reduces the risk of the attack.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
FIG. 1 is a diagram illustrating a consensus process of a practical Byzantine fault-tolerant algorithm in the related art;
fig. 2 is a block chain system according to an embodiment of the present disclosure;
fig. 3 is a flowchart illustrating a block chain consensus method according to an embodiment of the present disclosure;
fig. 4 is a schematic flowchart of a block chain consensus method according to an embodiment of the present disclosure;
fig. 5 is a schematic flowchart of a block chain consensus method according to an embodiment of the present disclosure;
FIG. 6 is a schematic diagram of a sub-step of step S140 shown in FIG. 3;
FIG. 7 is a schematic diagram of a sub-step of the step S142 shown in FIG. 6;
FIG. 8 is a schematic diagram of a sub-step of the step S142-2 shown in FIG. 7;
FIG. 9 is a schematic diagram illustrating another substep of step S140 shown in FIG. 3;
FIG. 10 is a schematic diagram of a sub-step of step S144 shown in FIG. 6;
fig. 11 is a schematic structural diagram of a dictionary tree according to an embodiment of the present application;
FIG. 12 is a schematic diagram illustrating the sub-steps of step S160 shown in FIG. 3;
fig. 13 is a schematic diagram illustrating a consensus process of the blockchain system according to an embodiment of the present disclosure;
fig. 14 is a block diagram of a block chain consensus apparatus according to an embodiment of the present disclosure;
fig. 15 is a schematic frame diagram of a replica node according to an embodiment of the present application.
Detailed Description
After the problem of the general of Byzantine was addressed, a number of algorithms were proposed to solve the problem. The algorithm is called Byzantine Fault Tolerance (BFT) in general, and the PBFT algorithm is a widely applied algorithm.
In one example, the byzantine system includes node 0, node 1, node 2, and node 3, where node 3 is a byzantine node (i.e., a malicious or failed node) and nodes 0, 1, 2 are non-byzantine nodes. Each node in the byzantine system may be referred to as a duplicate node for providing duplicate copy services. Each round of consensus in the Byzantine system corresponds to one view, and each view comprises a master node and a plurality of slave nodes. One round of consensus comprises 5 phases total request, pre-prepare, commit, reply. A round of the consensus process of the above system is described below with reference to fig. 1.
1. Before a round of consensus starts, all nodes in the system are slave nodes, after the round of consensus starts, one of the slave nodes is selected as a master node, and the selection rule is as follows: the current view number (view number) and the number of the replica nodes (backup number) are used for performing modulo operation, and the obtained result is used as the index of the slave node, in other words, the slave node with the index is determined as the master node of the current round of consensus (current view). Wherein the view sequence number is incremented with the consensus round. It should be noted that fig. 1 shows a case where node 0 is a master node, and nodes 1, 2, and 3 are all slave nodes. It is also worth noting that when the master node fails or the slave node suspects that the master node is in problem, a view change (view change) will be triggered, thereby reselecting the master node and entering a new view.
2. The master node 0 receives a request sent by a client (client) and broadcasts a pre-prepare message according to the request.
3. Receiving the pre-prepare message transmitted from the master node 0 from the nodes 1, 2 and 3, wherein the non-byzantine nodes 1 and 2 broadcast the pre-prepare message after verifying the correctness of the pre-prepare message, and then enter a prepared state, and wait and collect a nominal number of the pre-messages.
4. After receiving the nominal number of prepare messages, the non-byzantine nodes 0, 1 and 2 broadcast a commit message and then enter a committed state.
5. After receiving the nominal number of commit messages, the non-Byzantine nodes 0, 1 and 2 determine that the cost round consensus is achieved, and return reply to the client.
It is worth noting that when applying the above PBFT algorithm in a blockchain system, the client role can be deleted, in which case the blockchain node acts as both a replica node and a client. Accordingly, the request phase and the reply phase of the above 5 phases may be omitted, and a packed block finger may be used instead. In other words, the master node may generate the block-packing command periodically after each round of consensus, thereby automatically starting a round of consensus.
In the process of implementing the present application, the inventor finds that the primary node of each round of consensus is determined in a fixed calculation manner based on the number of replica nodes and the sequence number of the current view before the round of consensus starts, the number of secondary nodes is a constant, the sequence number of the view is an integer which is sequentially increased from zero, and the increment of each increment cannot be larger than a certain constant, and is usually 1. In this case, an attacker can very easily predict the sequence number of the current view in advance according to the sequence number of the previous view and predict the master node of the current view in advance, so that the attacker frequently and pertinently attacks the master node, which causes the consensus to be in a view change timeout state all the time, and further causes system paralysis or severe performance reduction.
In view of the foregoing problems, embodiments of the present application provide a method, an apparatus, and a system for recognizing a blockchain, in which a replica node in a blockchain system generates a candidate block and a random number, and broadcasts the candidate block and the random number through a pre-prepared message. In this way, each replica node in the blockchain system can elect the master node based on the random number in the received pre-preparation message. Because the prediction of the random number generated by each copy node is difficult, and the master node is elected based on the random numbers provided by the copy nodes, the predicted difficulty of the master node can be increased, so that compared with a master node determination mode in the existing PBFT algorithm, the scheme reduces the probability that the master node is predicted in the view, and further reduces the risk of an attacker.
It should be noted that the defects of the above methods are the results of the inventor after practice and detailed research, and therefore, the discovery process of the above problems and the solution proposed by the present application to the above problems in the following description should be the contribution of the inventor to the present application in the invention process.
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
Fig. 2 is a block chain system 10 according to an embodiment of the present disclosure, which includes a plurality of replica nodes, such as replica nodes 100, 101, 102, and 103. The number of replica nodes in the blockchain system 10 is 3f +1, where f represents the number of byzantine nodes in the blockchain system 10, i.e., the number of malicious or failed nodes. In other words, at least 2f +1 non-byebye-clandon nodes exist in the blockchain system 10, and these nodes can perform each round of consensus processing according to the blockchain consensus method provided in the embodiment of the present application. The replica nodes in the blockchain system 10 are all peer nodes, and communication between each two nodes is possible. It can be understood that the replica node mentioned in the embodiment of the present application may be, for example, a terminal device (e.g., a tablet computer, a notebook computer, a personal computer) or a server, where the server may be, for example, an independent physical server, a server cluster formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as cloud computing and big data. The embodiments of the present application do not limit this.
Alternatively, in this embodiment, the blockchain system 10 may be, for example, a supply chain financial system, such as a blockchain network established between a bank, an upstream tap enterprise, and a medium-sized or small-sized enterprise. In this scenario, the medium-sized and small-sized enterprises may provide a mortgage or a certificate with repayment capability to the bank through the block chain, where the certificate may be, for example, manifest information, contract information, and the like of the medium-sized and small-sized enterprises and the upstream and downstream enterprises. When providing the certification, the medium and small enterprises need to provide the authenticity certification for the upstream and downstream enterprises. Based on this, the bank can evaluate whether to loan the medium and small enterprises by using the certification provided by the block chain. In addition, the blockchain system 10 provided by the embodiment can also be used in the scenario that the number of participants is limited, such as cross-border trade payment and settlement, anti-counterfeiting traceability, and the like.
Fig. 3 is a flowchart illustrating a blockchain consensus method according to an embodiment of the present disclosure, which can be applied to any replica node in the blockchain system 10 shown in fig. 2. For ease of understanding, the present embodiment will use the replica node 100 as an example to describe the steps included in the method. Referring to fig. 3, the method may specifically include the following steps.
S120, broadcasting a first pre-preparation message in the blockchain system, and receiving a second pre-preparation message broadcast by other replica nodes, wherein the pre-preparation message broadcast by any replica node comprises a candidate block generated by the replica node and a random number.
The first pre-preparation message is a pre-preparation message broadcasted by the replica node, and the second pre-preparation message is a pre-preparation message received by the replica node. Taking replica node 100 as an example, replica node 100 itself generates and broadcasts out one pre-prepare message pre-prepare0, receives two pre-prepare messages (e.g., pre-prepare1 and pre-prepare2), then pre-prepare0 is the first pre-prepare message for replica node 100, and pre-prepare1 and pre-prepare2 are the second pre-prepare message for replica node 100. It will be appreciated that if the pre-preparation message pre-preparation 0 broadcast by replica node 100 is received by any other replica node (e.g., 101, 102, or 103), the pre-preparation message pre-preparation 0 is the second pre-preparation message for any other replica node.
In which, the replica node 100 in the blockchain system 10 may automatically generate a request for triggering the start of a new round of consensus at a certain timing after completing a round of consensus. In this embodiment, after a round of consensus starts, the replica node 100 directly broadcasts the pre-preparation message. Specifically, the replica node 100 may perform block packing on the transaction information obtained by the node to generate a candidate block; in addition, a random number is generated, and the candidate block and the random number are carried in a pre-preparation message and broadcast to other replica nodes. It is understood that the present embodiment is explained by taking the example that the replica node 100 is a non-byzantine node. When the replica node 100 is a byzantine node, the replica node 100 may not perform the consensus method provided by the embodiment of the present application, but perform other operations to prevent the blockchain system 10 from achieving the current round of consensus or achieving a wrong consensus.
Similarly, other replica nodes in the blockchain system 10 can also be processed according to step S120. In this way, each replica node in the blockchain system 10 can receive the second prepare messages sent by a plurality of other replica nodes, and each received second prepare message carries a random number.
S140, determining a target random number from random numbers included in the first pre-preparation message and the second pre-preparation message, and determining a copy node generating the target random number in the blockchain system as a master node of the current view.
After receiving the plurality of second preliminary messages, the replica node 100 may determine the random number in each second preliminary message and the random number in the first preliminary message generated by the node as candidate random numbers, and select, based on a preset condition, a random number that meets the preset condition from the candidate random numbers as a target random number. Illustratively, the target random number here may be one of the candidate random numbers having the smallest value. After determining the target random number, the sender of the pre-prepared message in which the target random number is located may be determined to be the master node. It is to be understood that the target random number may be a random number in the first pre-prepared message, in which case the replica node 100 is the master node. The target random number may also be the random number in the second pre-preparation message, such that the master node is a replica node other than replica node 100.
S160, if it is determined that the blockchain system agrees with the candidate block generated by the master node, writing the candidate block generated by the master node into a local blockchain.
In this embodiment, other replica nodes in the blockchain system 10 can be selected as the primary node according to S140. After determining the master node of the current view, each replica node may perform a subsequent consensus process on the candidate blobs generated by the master node determined by the node, and determine whether the blockchain system 10 agrees on the candidate blobs generated by the master node based on the subsequent consensus process.
In this embodiment, taking replica node 100 as an example, if replica node 100 determines that the blockchain system 10 has a consensus on a candidate block generated by the master node, the candidate block may be appended to the local blockchain. Correspondingly, the candidate block will become the newest block of the local blockchain.
Through the blockchain consensus method shown in fig. 3, the replica node in the blockchain system can broadcast the random number carried in the pre-preparation message, so that other replica nodes can select the master node based on the random number generated by the replica node and the random number in the received pre-preparation message, and the random number has a certain prediction difficulty due to its randomness, and accordingly, the master node selected based on the random number also has a certain prediction difficulty. In other words, the scheme provided by the embodiment reduces the probability that the master node in a round of consensus is predicted, thereby reducing the risk of being attacked.
Further, referring to the above-mentioned consensus process of the PBFT algorithm shown in fig. 1, the PBFT algorithm is performed by the master node after the master node elects, and then the block is packed. However, there is a time difference from the generation of the master node to the packing of the blocks, which gives the attacker an opportunity to attack. The scheme of the embodiment of the application is that after each backup node respectively packages the blocks, the master node is elected, when the master node is elected, the blocks packaged by the master node in the current view are also determined at the same time, namely, the master node determination and the acquisition of the blocks packaged by the master node are basically realized at the same time, and basically, no time difference exists between the blocks, namely, no opportunity of an attacker to attack in the time difference exists, so that the risk of the master node being attacked is further reduced.
Referring to fig. 3 and 4 together, a detailed implementation process of the steps shown in fig. 3 will be described in conjunction with fig. 4.
The inventors have further investigated that random number generation algorithms in the real number range are usually fixed in their value range, e.g. 1-100. In this case, given a selection condition, such as when the selection condition is a minimum value, then the minimum value of 1 can be explicitly selected from within the range of values. Accordingly, to become the master node, the replica node may directly declare that its random number is 1 without actually generating a random number. In addition, the master node election process should be fair to each replica node in the blockchain system 100, in other words, the probability that each replica node in the blockchain system 10 is elected as the master node should be substantially the same. Based on this, in the embodiment of the present application, the replica node may process the relevant information of the node through a hash algorithm, so as to obtain a random number of the node for participating in the election of the master node. Optionally, in an example of the embodiment of the present application, before performing the step S120, the method provided in the embodiment of the present application may further include the step shown in fig. 4.
And S111, generating a candidate block of the node.
S112, the hash value of the latest block of the local block chain and the sequence number of the current view are obtained.
And S113, performing Hash processing on the hash value of the latest block of the local block chain and the sequence number of the current view to obtain the random number of the node.
S114, generating a preliminary preparation message including the candidate block of the node and the random number of the node, and determining the preliminary preparation message as the first preliminary preparation message.
The above flow is described by taking the replica node 100 as an example. The replica node 100 may perform block packing according to the transaction information obtained by the node. The latest block here refers to a block that the replica node 100 has written to the local blockchain in the previous round of consensus, which is usually a block generated by the master node in the previous round of consensus, and which has obtained the consensus of the replica node in the blockchain system 10. The current view refers to a view corresponding to the current round of consensus.
After obtaining the hash value of the latest block of the local block chain and the sequence number of the current view, the replica node 100 may perform hash processing on the hash value and the sequence number through a preset hash function, where a result output by the preset hash function is a random number of the replica node 100. Then, the replica node 100 may assemble the generated candidate blocks and the random number into a pre-preparation message, which is the first pre-preparation message that the replica node 100 needs to broadcast.
It is noted that other replica nodes in the blockchain system 10 can generate and broadcast respective first prepare messages according to the flow shown in fig. 4.
For example, the process of generating the random number in the above flow may be represented as random — hash (seed), where random represents the random number, hash represents a preset hash function used, and seed represents the latest block hash value of the local block chain obtained by the replica node and the sequence number of the current view. In this case, since the used seed is different and the output random number is different, the random number can be verified by the seed. Moreover, the values of the hash function are uniformly distributed in the value range, so that through the flow shown in fig. 4, it can be ensured that the random numbers provided by the respective replica nodes can be verified, and the probability that the respective replica nodes are elected as the master node can be ensured to be substantially the same.
The inventor further studies in the practical process to find that seed needs to be disclosed in order to realize verification of random numbers. However, once a seed is disclosed, any replica node can use this seed to generate the same random number, resulting in an inability to determine the first generator of a random number.
Based on this, in the embodiment of the present application, the pre-preparation message broadcast by any replica node of the blockchain system 10 may further include a zero-knowledge proof of the random number of the pre-preparation message. In other words, the first pre-preparation message and the second pre-preparation message in S120 each further include a zero knowledge proof. Therefore, only part of information for generating the random number can be selected to be disclosed, and the verification of the random number can be realized.
Correspondingly, please refer to fig. 5, which schematically illustrates another example of the embodiment of the present application, before performing S120, the method provided by the embodiment of the present application may further include the step illustrated in fig. 5. The detailed description is as follows.
And S111, generating a candidate block of the node.
S112, the hash value of the latest block of the local block chain and the sequence number of the current view are obtained.
The detailed implementation process of steps S111 and S112 may refer to the above related description.
And S115, acquiring a private key in the asymmetric key pair of the node.
S116, the private key and the hash value are processed by a Verifiable Random Function (VRF), so as to obtain a random number of the node and a zero knowledge proof for the random number.
In this embodiment, the verifiable random function may produce a unique output for a particular key and input x, while the input may be verified. The verifiable random function mainly consists of three polynomial time algorithms, namely a function generator G, a function evaluator F and a function verifier V.
Where G is a probabilistic algorithm that receives as input a security parameter k (i.e., a string) and outputs two binary strings, i.e., the above-mentioned asymmetric key pair, including the public key PK and the private key SK. In the embodiment of the present application, the algorithm G may be, for example, an elliptic curve algorithm.
The function evaluator F is a deterministic algorithm, F ═ F (F)1,F2) The above-mentioned private keys SK and x are used as inputs of F, and two binary strings, which are respectively a random number value and a zero knowledge proof, can be output. Specifically, value ═ F1(x,SK)，proof＝F2(x, SK). In this embodiment, x may be, for example, the hash value described in S112, and taking the replica node 100 as an example, the replica node 100 may use its own private key and the hash value of the latest chunk of the local chunk chain as inputs of F, so as to obtain the random number value and the zero knowledge proof.
And S117, destroying the private key of the node.
Because the generation process of the random number and the zero knowledge proof utilizes the private key of the copy node, the private key of the node can be destroyed after the random number and the zero knowledge proof are obtained. In this way, it is possible to prevent an attacker from attacking the master node with a time gap during which the master node election is over, but the consensus has not yet reached the preparation (prepare) phase, and repackaging the blocks with the master node's private key. In this way, the private key used by each copy node in this embodiment is actually a temporary private key, which further improves data security.
S118, a pre-preparation message including the candidate block of the node, the random number of the node, and the zero-recognition certificate of the random number is generated, and the pre-preparation message is determined as the first pre-preparation message.
After obtaining the random number and the zero knowledge proof, the random number, the zero knowledge proof, and the candidate block may be assembled into a pre-preparation message and determined as the first pre-preparation message. Thus, the random number and its zero knowledge certificate are broadcast in the first pre-prepared message, and other replica nodes can verify the random number with its zero knowledge certificate. Based on this, the step of determining a target random number from the random numbers respectively included in the first pre-preparation message and the received second pre-preparation message in step S140 shown in fig. 3 may be implemented by steps S142 and S144 shown in fig. 6.
S142, verifying the random number in the second pre-preparation message according to the zero knowledge proof in the second pre-preparation message.
Wherein, the step S142 can be realized by the sub-steps shown in fig. 7.
S142-1, obtaining the public key in the asymmetric key pair of the node.
In this embodiment, taking the replica node 100 as an example, the replica node 100 may broadcast the public key and the node identifier of itself after obtaining the asymmetric key of the node, so that other replica nodes know. Other replica nodes in the similar regional blockchain system 10 may also be known to disclose public keys to other replica nodes in a similar manner.
S142-2, verifying the random number in the second pre-preparation message based on the public key and zero knowledge proof in the second pre-preparation message.
Specifically, step S142-2 may include the flow shown in fig. 8.
S801, recovering a random number from the zero knowledge proof included in the second pre-preparation message.
S802, if the recovered random number is the same as the random number included in the second pre-preparation message, inputting the serial number of the current view, the hash value of the latest chunk obtained from other replica nodes broadcasting the second pre-preparation message, and the random number and zero knowledge proof in the second pre-preparation message into the function verifier.
S803, if the output result of the function verifier is true, determining that the random number in the second pre-preparation message is verified.
In this embodiment, the verification of the random number may be implemented by a function verifier V that can verify a random function. The function verifier V is also probabilistic, taking as input the public key PK, the above input x, the random number value, and the zero proof of knowledge proof, and outputs TRUE indicating that the verification passed or FALSE indicating that the verification failed.
Taking the replica node 100 as an example of the currently executed body of the method provided by this embodiment, if the replica node 100 receives the second pre-preparation message pre-preparation 1 sent by the replica node 101, the replica node 100 may obtain a zero knowledge proof from the received pre-preparation message pre-preparation 1, and may recover a random number from the zero knowledge proof by using the function VRF _ P2H, and if the recovered random number is equal to the random number carried in pre-preparation 1, may further obtain the hash value of the latest chunk of its local chunk chain from the replica node 101, and may use the obtained zero knowledge proof, the hash value, the random number in pre-preparation 1, and the zero knowledge proof as inputs of the function verifier, and then determine whether the random number verification passes based on the obtained output. Specifically, if the output is TRUE, it indicates that the random number is verified. If the output is FALSE, the random number verification fails.
S144, determining the target random number from the verified random numbers and the random numbers included in the first pre-preparation message.
In this embodiment, the random number that passes the verification and the random number included in the first preliminary preparation message may be used as candidate random numbers, and one of the candidate random numbers that meets the predetermined condition may be determined as the target random number. For example, the smallest one of them is determined as the target random number.
Referring to the above example in which the replica node 100 verifies the random number in the second pre-preparation message pre-preparation 1, after the verification of the random number is completed, the replica node 100 may select one of the random number generated by itself and all the random numbers passing the verification as the target random number, and specifically may select one with the smallest value as the target random number. And the sender of the prepared message where the target random number is located is the master node. In this case, the replica node 100 may choose to perform a subsequent consensus process on the candidate tiles in the prepare message sent by the master node.
In this embodiment, optionally, the pre-preparation message sent by any replica node may also carry signature information, where the signature information is obtained by signing a random number and a zero knowledge certificate generated by the replica node based on a private key in an asymmetric key pair of the replica node. Accordingly, as shown in fig. 9, before executing S142, the method provided in this embodiment may further include the following steps:
and S141, verifying the signature information in the second pre-prepared message based on the public key in the asymmetric key pair of the node, and if the signature information in the second pre-prepared message passes verification, triggering to execute S142.
Wherein the verification of the signature information in the second pre-prepared message may be performed by a signature verification algorithm. For convenience of description, the random number and the zero knowledge proof in the second pre-prepared message are collectively described as the first message, in which case, the second message may be obtained according to the public key in the asymmetric key pair of the present node and the signature information in the second pre-prepared message, and whether the first message and the second message are the same or not may be compared. And if the first message is the same as the second message, determining that the signature information in the second pre-prepared message is verified.
Optionally, in this embodiment, since the random number is a hash value, which is a string of hexadecimal characters with a fixed length of 32 bits, when the size of the random number is compared by using a conventional sorting algorithm, there are many disadvantages, for example, when two strings are large, the strings need to be traversed, and compared byte by byte, the performance is poor; for example, the optimal time complexity of the conventional algorithm such as heap sorting is o (logn), and the time complexity is relatively large. Based on this, in the embodiment of the present application, a dictionary tree is used to determine the minimum random number. In detail, step S144 may be implemented by the flow shown in fig. 10. The specific description is as follows.
S144-1, respectively storing the random number that passes the verification and the random number included in the first preliminary preparation message into a dictionary tree, where each leaf node in the dictionary tree corresponds to one random number stored in the dictionary tree, and each leaf node uses the random number corresponding to the leaf node as a key and uses an index of a copy node that generates the random number corresponding to the leaf node as a value to form a key-value pair.
S144-2, searching the smallest random number by traversing the dictionary tree, and taking the searched smallest random number as a target random number.
A dictionary tree, also known as a Trie or prefix tree, is a multi-way tree structure for fast retrieval. In this embodiment, the random numbers that pass the verification are all stored in the dictionary tree. As shown in fig. 11, each random number in the dictionary tree is a path from a root node to a leaf node, each edge in the path corresponds to a hexadecimal character, characters corresponding to each edge in the path are sequentially connected to form a random number, and the leaf node corresponding to a random number may store an index of a copy node that generates the random number. In this embodiment, the depth of the dictionary tree for storing random numbers is 32. The minimum random number is searched through the dictionary tree, only 32 times of query are needed when the minimum random number is determined each time, the time complexity is O (1), and the efficiency is greatly improved.
When any duplicate node determines that the blockchain system 10 agrees with the candidate block generated by the master node through the subsequent agreement process, the candidate block generated by the master node may be added to the local blockchain, and the next round of agreement is entered at a fixed time.
Referring to fig. 12, a detailed implementation flow of step S160 is shown, and the replica node 100 is taken as an example for description.
S161, if the candidate block generated by the master node passes the verification of the own node, broadcasting a first preparation message to each of the other replica nodes.
It is worth noting here that the first prepare message may be broadcast directly when the replica node 100 is the selected master node. The first prepare message may include, for example, the current view sequence number, the sequence number of the tile, the digest of the candidate tile, and the identity of the replica node (e.g., 100).
And S162, receiving a second preparation message broadcast by the other replica nodes.
S163, if the received second preparation messages reach the preset number, and it is determined that the first preparation messages are consistent with the received second preparation messages of the preset number, broadcasting a first confirmation message to each of the other replica nodes.
As described above, each replica node in the blockchain system 10 can select a master node according to the processing flow of the replica node 100, so that the subsequent consensus process can be performed on the candidate blockchains generated by the master node. Thus, each replica node in the blockchain system 10 may broadcast a first prepare message to the outside upon determining the master node and determining that the candidate blockchain generated by the master node verifies. Accordingly, the replica node 100 may also receive the second prepare message broadcast by the other replica nodes.
In this embodiment, the predetermined number may be 2f, and in the block chain system 10, it may be 2, for example. In detail, when the target node (replica node 100) receives 2 second preparation messages, and the 2 second preparation messages are identical to the first preparation message broadcast by the replica node 100 itself, a first confirmation message may be generated and broadcast.
And S164, receiving the second confirmation message broadcasted by the other replica nodes.
And S165, when the number of the received second confirmation messages reaches a preset number and the first confirmation message is determined to be consistent with the preset number of the received second confirmation messages, determining that the candidate blocks generated by the main node are identified by the block chain system.
In detail, each replica node in the blockchain system 10 may broadcast a first acknowledgement message outwards, and correspondingly, the replica node 100 may receive second acknowledgement messages broadcast by other replica nodes. And, when 2 second acknowledgement messages are received and the 2 second acknowledgement messages coincide with the first acknowledgement message generated by the replica node 100 itself, it may be determined that consensus is achieved on the candidate tiles generated by the master node.
By the blockchain consensus method and the blockchain system provided by the embodiment, the probability that the main node is predicted in the view can be reduced, so that the risk that the main node is attacked by an attacker is reduced.
Referring to fig. 13, fig. 13 is a schematic diagram illustrating a consensus process of applying the blockchain consensus method provided by the embodiment of the present application to the blockchain system 10. In conjunction with the consensus process diagram, the duplicate node 103 in the blockchain system 10 is a byzantine node for example.
1. Replica node 100 generates a pre-prepare message pre-preparation 0 and broadcasts pre-preparation 0 in the blockchain system 10.
The duplicate node 100 generates a temporary asymmetric key pair comprising a temporary public key PK-0 and a temporary private key SK-0 through an elliptic curve algorithm, acquires a hash value of a latest block of a local block chain, inputs the temporary private key SK-0 and the hash value into a verifiable random function, and obtains a random number V-0 and a zero knowledge Proof of Proof-0. The replica node 100 further signs the random number V-0 and the zero knowledge Proof of 0 by using the temporary private key SK-0 to obtain signature information Sig-0, and then destroys the temporary private key SK-0. The replica node 100 packages the obtained transaction information into a candidate block-0, assembles the candidate block-0, signature information Sig-0 (the temporary public key PK-0 is included in the data structure definition of Sig-0), a random number V-0, and a zero knowledge Proof-0 into a pre-prepare message pre-prepare0, and broadcasts pre-prepare0 in the blockchain system 10.
Where pre-prepare0 is the first pre-prepare message for replica node 100.
2. Replica node 101 generates a pre-prepare message pre-prepare1 and broadcasts a pre-prepare1 in the block chain system 10, pre-prepare1 including a candidate block-1 generated by replica node 101, a random number V-1, and a zero knowledge Proof of random number V-1 Proof random number V-1.
Where pre-prepare1 is the first pre-prepare message for replica node 101.
3. The replica node 102 generates a pre-prepare message pre-prepare2 and broadcasts a pre-prepare2 in the block chain system 10, the pre-prepare2 including the candidate block-2 generated by the replica node 102, the random number V-2, and the zero knowledge Proof of random number V-2.
Where pre-prepare2 is the first pre-prepare message for replica node 102.
The replica node 103 will not broadcast the prepare message since it is a byzantine node.
Wherein, the detailed implementation flow of S2 and S3 is similar to S1, and there is no strict restriction on the execution order among S1, S2 and S3.
4. The replica node 100 receives the pre-prepare messages pre-preparation 1, pre-preparation 2, verifying the random number V-1 in pre-preparation 1 and the random number V-2 in pre-preparation 2, respectively.
Where pre-prepare1, pre-prepare2 are the second pre-prepare messages for replica node 100.
The replica node 100 firstly verifies the signature information Sig-1 in the pre-prefix 1 by using the temporary public key PK-1 of the replica node 101, if the verification is passed, a random number V-1 'can be recovered by using the zero knowledge Proof-1, if V-1' and V-1 are consistent, the hash value of the latest block in the local block chain can be obtained from the replica node 101, and the hash value, the random number V-1, the zero knowledge Proof-1 and the temporary public key PK-1 are input into a function verifier capable of verifying a random function, so that a verification result can be obtained, and if the verification result is TRUE, the verification of the random number V-1 is passed. Similarly, the verification process of each other counterpart node for any random number is similar to the above-mentioned flow, and is not described herein again.
If replica node 100 determines that both random number V-1 in pre-preamble 1 and random number V-2 in pre-preamble 2 are verified, then its own random number and verified random numbers V-1, V-2 may be stored in a dictionary tree, and the smallest random number, e.g., V-0, is determined by traversing the dictionary tree, then V-0 is the target random number, and accordingly replica node 100 determines that it is the master node for the current view.
5. Replica node 101 receives the pre-prepare messages pre-prepare0, pre-prepare 2. Where pre-prepare0, pre-prepare2 are the second pre-prepare message for replica node 101.
Similarly, replica node 101 stores the self-generated random number V-1 and the verified random numbers V-0 and V-2 in the trie, and determines that the smallest random number is V-0 by traversing the trie, and determines that replica node 100 generating the target random number V-0 is the master node of the current view.
6. Replica node 102 receives the pre-prepare messages pre-prepare0, pre-prepare 1. Where pre-prepare0, pre-prepare1 is the second pre-prepare message for replica node 102.
Similarly, replica node 102 will also determine replica node 100 as the master node for the current view.
7. The replica node 103 receives the pre-prepare messages pre-prepare0, pre-prepare1, pre-prepare 2. pre-prefix 0, pre-prefix 1, pre-prefix 2 are second pre-prepare messages for replica node 103.
Replica node 103 is a byzantine node that does not determine replica node 100 as the master node.
8. The replica node 100, acting as the master node, generates a prepare message prepare0 based directly on the candidate block-0 and broadcasts a prepare0 in the block chain system 10. Where prepare0 is the first prepare message for replica node 100 and the second prepare message for the other replica nodes.
9. The replica node 101 verifies the candidate tile-0 generated by the master node 100, and generates a preparation message preparation 1 when the verification passes, and broadcasts a preparation 1 in the tile chain system 10. Where prepare1 is the first prepare message for replica node 101 and the second prepare message for the other replica nodes.
10. Replica node 102 verifies the candidate block-0 generated by master node 100 and generates and broadcasts a prepare message preparation 2 when the verification passes. Where prepare2 is the first prepare message for replica node 102 and the second prepare message for the other replica nodes.
The replica node 103 is a byzantine node and does not broadcast the preparation message.
11. The replica node 100 (master node) receives the preparation messages preparation 1, preparation 2, compares them with the preparation message preparation 0 generated by itself, determines that the three are a match, thus generates an acknowledgement message commit0, and broadcasts commit0 in the blockchain system 10. Where commit0 is the first acknowledgement message for replica node 100 and the second acknowledgement message for the other replica nodes.
12. The replica node 101 receives the preparation messages prepare0 and prepare2, compares the messages prepare0 and prepare2 with the preparation message prepare1 generated by the replica node, determines that the messages prepare1 and prepare1 are matched, and broadcasts the commit 1. commit1 is a first acknowledgement message for replica node 101 and a second acknowledgement message for other replica nodes.
13. The replica node 102 receives the preparation messages prepare0 and prepare1, compares the messages prepare0 and prepare1 with the preparation message prepare2 generated by the replica node itself, determines that the messages prepare2 and prepare2, and broadcasts the commit 2. commit2 is a first acknowledgement message for replica node 102 and a second acknowledgement message for other replica nodes.
14. The replica node 100 (master node) receives the confirmation messages commit1 and commit2, compares them with the commit0 generated by itself, confirms that the three match, determines that the node in the block chain system 10 agrees with the candidate block-0, and adds the block-0 to the local block chain.
15. The replica node 101 receives the confirmation messages commit0 and commit2, compares them with the commit1 generated by itself, confirms that they match, determines that the node in the block chain system 10 agrees with the candidate block-0, and adds block-0 to the local block chain.
16. The replica node 102 receives the confirmation messages commit0, commit1, compares them with the commit2 generated by itself, confirms that they match, determines that the node in the block chain system 10 agrees with the candidate block-0, and adds block-0 to the local block chain.
Duplicate node 103 does not agree on block-0 due to the byzantine node.
17. And finishing the consensus of the round.
By the block chain consensus method and the block chain system, the probability that the main node in each round of consensus is predicted can be reduced, and therefore the risk that the main node is attacked is reduced.
Referring to fig. 14, a blockchain consensus apparatus 1400 provided by an embodiment of the present application is shown, where the blockchain consensus apparatus 1400 can be applied to a replica node, such as 100, 101, 102, or 103, in the blockchain system 10 shown in fig. 2. The block chain consensus apparatus 1400 may comprise a transceiver module 1410, a master node selection module 1420, and a consensus module 1430.
The transceiver module 1410 is configured to broadcast a first pre-preparation message in the blockchain system, and receive a second pre-preparation message broadcast by other replica nodes in the blockchain system, where the pre-preparation message broadcast by any replica node in the blockchain system includes a candidate block generated by the replica node and a random number.
The master node selecting module 1420 is configured to determine a target random number from random numbers included in the first pre-preparation message and the second pre-preparation message, and determine a replica node in the blockchain system that generates the target random number as a master node of the current view.
The consensus module 1430 is configured to write the candidate block generated by the master node to a local blockchain if it is determined that the blockchain system agrees on the candidate block generated by the master node.
Optionally, the blockchain consensus device 1400 may further include a message generation module.
The message generation module is used for generating a candidate block of the node; performing hash processing on the hash value of the latest block of the local block chain and the sequence number of the current view to obtain a random number of the node; and generating a pre-preparation message including the candidate block of the node and the random number of the node, and determining the pre-preparation message as the first pre-preparation message.
Optionally, the pre-prepare message broadcast by any replica node in the blockchain system 10 also includes a zero-knowledge proof of the random number in the pre-prepare message. In this case, the message generation module may be further configured to:
prior to broadcasting the first pre-preparation message in the blockchain system, the method further comprises: generating a candidate block of the cost node; obtaining the hash value of the latest block of the local block chain and the sequence number of the current view; acquiring a private key in an asymmetric key pair of the node; processing the private key and the hash value through a verifiable random function to obtain a random number of the node and a zero knowledge proof aiming at the random number; generating a pre-preparation message comprising the candidate block of the node, the random number of the node and a zero knowledge proof of the random number, and determining the pre-preparation message as the first pre-preparation message.
Optionally, the master node selecting module 1420 is specifically configured to verify the random number in the second pre-preparation message according to a zero knowledge proof in the second pre-preparation message; determining the target random number from the verified random number and the random number included in the first pre-preparation message.
Optionally, the master node selecting module 1420 is further configured to obtain a public key in the asymmetric key pair of the node; verifying the random number in the second pre-preparation message based on the public key and a proof of knowledge of zero in the second pre-preparation message.
Optionally, the verifiable random function comprises a function verifier. In this case, the master node selection module 1420, based on the public key and the proof of knowledge of zero in the second pre-preparation message, may verify the nonce in the second pre-preparation message in such a way that: recovering a random number from a zero knowledge proof included in the second pre-preparation message; if the recovered random number is the same as the random number included in the second pre-preparation message, inputting the serial number of the current view, the hash value of the latest block obtained from other replica nodes broadcasting the second pre-preparation message, and the random number and zero knowledge in the second pre-preparation message into the function verifier; and if the output result of the function verifier is true, determining that the random number in the second pre-preparation message passes verification.
Optionally, the pre-preparation message broadcast by any replica node in the blockchain system further includes signature information, and the signature information is obtained by signing the random number and the zero-knowledge proof generated by the replica node based on a private key in an asymmetric key pair of the replica node. The blockchain consensus device 1400 may also include a verification module.
The verification module is used for verifying signature information in the second pre-preparation message based on a public key in an asymmetric key pair of a node before verifying a random number in the second pre-preparation message according to zero knowledge proof in the second pre-preparation message; and if the signature information in the second pre-preparation message passes the verification, triggering and executing the step of verifying the random number in the second pre-preparation message according to the zero knowledge proof in the second pre-preparation message.
Optionally, the random number and zero knowledge in the second pre-preparation message prove to be the first message. In this case, the master node selection module 1420 verifies the signature information in the second pre-preparation message based on the public key in the asymmetric key pair of the own node in a manner that: obtaining a second message according to a public key in the asymmetric key pair of the node and signature information in the second pre-prepared message; comparing whether the first message and the second message are the same; and if the first message is the same as the second message, determining that the signature information in the second pre-prepared message is verified.
Optionally, the master node selecting module 1420 may be further configured to destroy the private key of the node after obtaining the random number of the node and the zero knowledge proof for the random number.
Optionally, the master node selecting module 1420 may determine the target nonce from the nonce passed through the verification and the nonce included in the first pre-preparation message by: determining a smallest random number as the target random number from among the verified random numbers and the random numbers included in the first pre-preparation message.
Optionally, the manner of determining, by the master node selection module 1420, the smallest random number as the target random number from the random numbers that are verified and the random numbers included in the first pre-preparation message may be: respectively storing the random numbers which pass the verification and the random numbers included in the first pre-preparation message into a dictionary tree, wherein each leaf node in the dictionary tree corresponds to the random numbers stored in the dictionary tree one by one, and each leaf node takes the random number corresponding to the node as a key and takes the index of the copy node which generates the random number corresponding to the node as a value to form a key value pair; and searching the smallest random number by traversing the dictionary tree, and taking the searched smallest random number as the target random number.
Optionally, the consensus module 1430 may be further configured to broadcast a first prepare message to each of the other replica nodes if the candidate block generated by the master node passes the verification of the node; receiving a second preparation message broadcast by the other replica nodes; broadcasting a first confirmation message to each of the other replica nodes in a case where the received second preparation messages reach a preset number and it is determined that the first preparation message is identical to the received second preparation messages of the preset number; receiving a second confirmation message broadcast by the other replica nodes; determining that the blockchain system agrees with candidate blocks generated by the master node if the received second acknowledgement messages reach a preset number and the first acknowledgement message is determined to be consistent with the received preset number of second acknowledgement messages.
Referring to fig. 15, a replica node 100 is taken as an example to illustrate a hardware architecture of a replica node according to an embodiment of the present application. The replica node 100 can include the blockchain consensus device 1400, the processor 110, and the computer-readable storage medium 120 described above.
The processor 110 and the computer-readable storage medium 120 may communicate over a system bus 130. The software functional modules included in the blockchain consensus device 1400 may be stored in the form of machine executable instructions in the machine-readable storage medium 120. The processor 110 may implement the block chain consensus method provided by the embodiments of the present application by calling and reading machine executable instructions in the computer readable storage medium 120.
It should be noted that the architecture shown in fig. 15 is merely exemplary. The replica node provided in the embodiment of the present application may further include more or fewer components than those shown in fig. 15, for example, may further include a communication unit, or has a matching value completely different from that shown in fig. 15, which is not limited in this embodiment. Further, the components shown in fig. 15 may be implemented by hardware, software, or a combination thereof.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more machine-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having machine-executable instructions embodied therein.
The present application has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by machine executable instructions. These machine-executable instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These machine-executable instructions may also be stored in a machine-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the machine-readable storage medium produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks (e.g., the automatic control apparatus 800 described above).
These machine-executable instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In the description of the present application, it is to be understood that the terms "first", "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including the preferred embodiment and all changes and modifications that fall within the scope of the present application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (15)

1. A blockchain consensus method applied to a replica node in a blockchain system, the method comprising:
broadcasting a first pre-preparation message in the blockchain system, and receiving a second pre-preparation message broadcast by other replica nodes in the blockchain system, wherein the pre-preparation message broadcast by any replica node in the blockchain system comprises a candidate block generated by the replica node and a random number;
determining a target random number from random numbers respectively included in the first pre-preparation message and the second pre-preparation message, and determining a copy node generating the target random number in the blockchain system as a main node of a current view;
and if the blockchain system is determined to be in consensus on the candidate blocks generated by the main node, writing the candidate blocks generated by the main node into a local blockchain.
2. The method of claim 1, wherein prior to broadcasting the first pre-preparation message in the blockchain system, the method further comprises:
generating a candidate block of the cost node;
performing hash processing on the hash value of the latest block of the local block chain and the sequence number of the current view to obtain a random number of the node;
generating a preliminary preparation message including the candidate block of the own node and the random number of the own node, and determining the preliminary preparation message as the first preliminary preparation message.
3. The method of claim 1, wherein the pre-prepare message broadcast by any replica node in the blockchain system further includes a zero knowledge proof of a random number in the pre-prepare message;
prior to broadcasting the first pre-preparation message in the blockchain system, the method further comprises:
generating a candidate block of the cost node;
obtaining the hash value of the latest block of the local block chain and the sequence number of the current view;
acquiring a private key in an asymmetric key pair of the node;
processing the private key and the hash value through a verifiable random function to obtain a random number of the node and a zero knowledge proof aiming at the random number;
and generating a pre-preparation message comprising the candidate block of the node, the random number of the node and zero knowledge proof of the random number, and determining the pre-preparation message as the first pre-preparation message.
4. The method of claim 3, wherein determining a target nonce from the nonces included in each of the first pre-preparation message and the received second pre-preparation message comprises:
verifying the random number in the second pre-preparation message according to zero knowledge proof in the second pre-preparation message;
determining the target random number from the verified random number and the random number included in the first pre-preparation message.
5. The method of claim 4, wherein verifying the random number in the second pre-preparation message based on a zero knowledge proof in the second pre-preparation message comprises:
acquiring a public key in the asymmetric key pair of the node;
verifying the random number in the second pre-preparation message based on the public key and a proof of knowledge of zero in the second pre-preparation message.
6. The method of claim 5, wherein the verifiable random function comprises a function verifier; the verifying the random number in the second pre-preparation message based on the public key and zero knowledge proof in the second pre-preparation message comprises:
recovering a random number from a zero knowledge proof included in the second pre-preparation message;
if the recovered random number is the same as the random number included in the second pre-preparation message, inputting the serial number of the current view, the hash value of the latest block obtained from other replica nodes broadcasting the second pre-preparation message, the random number in the second pre-preparation message and zero knowledge proof into the function verifier;
and if the output result of the function verifier is true, determining that the random number in the second pre-preparation message passes verification.
7. The method according to any one of claims 3-6, wherein the pre-preparation message broadcast by any replica node in the blockchain system further includes signature information, the signature information being obtained by signing the random number and zero knowledge proof generated by the replica node based on a private key of an asymmetric key pair of the replica node;
before verifying the random number in the second pre-preparation message based on zero knowledge proof in the second pre-preparation message, the method further comprises:
verifying signature information in the second pre-prepared message based on a public key in the asymmetric key pair of the node;
and if the signature information in the second pre-preparation message passes the verification, triggering and executing the step of verifying the random number in the second pre-preparation message according to the zero knowledge proof in the second pre-preparation message.
8. The method of claim 7, wherein the random number and zero knowledge in the second pre-preparation message prove to be the first message; the verifying the signature information in the second pre-prepared message based on the public key in the asymmetric key pair of the node comprises:
obtaining a second message according to a public key in the asymmetric key pair of the node and signature information in the second pre-prepared message;
comparing whether the first message and the second message are the same;
and if the first message is the same as the second message, determining that the signature information in the second pre-prepared message is verified.
9. The method according to any one of claims 4-6, further comprising:
and destroying the private key of the node after obtaining the random number of the node and the zero knowledge proof aiming at the random number.
10. The method according to any one of claims 3 to 6, wherein the determining the target random number from the random number that passes the verification and the random number included in the first pre-preparation message comprises:
determining a smallest random number as the target random number from among the verified random numbers and the random numbers included in the first pre-preparation message.
11. The method according to claim 10, wherein the determining, as the target random number, a smallest random number from among the random numbers that have passed the verification and the random numbers included in the first pre-preparation message, comprises:
respectively storing the random numbers which pass the verification and the random numbers included in the first pre-preparation message into a dictionary tree, wherein each leaf node in the dictionary tree corresponds to the random numbers stored in the dictionary tree one by one, and each leaf node takes the random number corresponding to the node as a key and takes the index of the copy node which generates the random number corresponding to the node as a value to form a key value pair;
and searching the smallest random number by traversing the dictionary tree, and taking the searched smallest random number as the target random number.
12. The method of any of claims 1-6, wherein after determining a replica node in the blockchain system that generated the target random number as a master node for a current view, the method further comprises:
if the candidate block generated by the main node passes the verification of the node, broadcasting a first preparation message to each other replica node;
receiving a second preparation message broadcast by the other replica nodes;
if the received second preparation messages reach a preset number and the first preparation messages are determined to be consistent with the received second preparation messages with the preset number, broadcasting first confirmation messages to the other replica nodes;
receiving a second confirmation message broadcast by the other replica nodes;
and if the number of the received second confirmation messages reaches a preset number and the first confirmation message is determined to be consistent with the number of the received second confirmation messages, determining that the block chain system agrees with the candidate blocks generated by the main node.
13. A blockchain consensus apparatus applied to a replica node in a blockchain system, the apparatus comprising:
a transceiver module, configured to broadcast a first pre-preparation message in the blockchain system, and receive a second pre-preparation message broadcast by other replica nodes in the blockchain system, where the pre-preparation message broadcast by any replica node in the blockchain system includes a candidate block generated by the replica node and a random number;
a master node selection module, configured to determine a target random number from random numbers included in the first pre-preparation message and the second pre-preparation message, and determine a replica node, which generates the target random number, in the blockchain system as a master node of a current view;
a consensus module for writing the candidate tiles generated by the master node into a local blockchain if it is determined that the blockchain system agrees on the candidate tiles generated by the master node.
14. A blockchain system comprising a plurality of replica nodes, at least 2f +1 replica nodes in the blockchain system being consensus processed by any of claims 1-12, f representing the number of byzantine nodes in each replica node of the blockchain system, f being an integer greater than 0.
15. A computer-readable storage medium having stored thereon machine-executable instructions which, when executed, implement the method of any one of claims 1-12.
CN202110228046.9A 2021-03-02 2021-03-02 Block chain consensus method, device and system Active CN113254526B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110228046.9A CN113254526B (en) 2021-03-02 2021-03-02 Block chain consensus method, device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110228046.9A CN113254526B (en) 2021-03-02 2021-03-02 Block chain consensus method, device and system

Publications (2)

Publication Number Publication Date
CN113254526A true CN113254526A (en) 2021-08-13
CN113254526B CN113254526B (en) 2024-07-05

Family

ID=77180960

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110228046.9A Active CN113254526B (en) 2021-03-02 2021-03-02 Block chain consensus method, device and system

Country Status (1)

Country Link
CN (1) CN113254526B (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113850600A (en) * 2021-12-01 2021-12-28 深圳前海微众银行股份有限公司 Transaction consensus method, device, equipment and storage medium based on block chain
CN117614611A (en) * 2024-01-24 2024-02-27 苏州元脑智能科技有限公司 Block chain consensus method, system and storage medium

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109472593A (en) * 2018-10-10 2019-03-15 远光软件股份有限公司 A kind of settlement method based on block chain technology, device and block chain network
CN109559223A (en) * 2018-10-10 2019-04-02 远光软件股份有限公司 A kind of method of commerce based on block chain technology, device and block chain network
CN109639837A (en) * 2019-01-31 2019-04-16 东南大学 Block chain DPoS common recognition method based on faith mechanism
CN109964446A (en) * 2018-06-08 2019-07-02 北京大学深圳研究生院 A kind of common recognition method based on ballot
CN111327414A (en) * 2020-01-20 2020-06-23 布比（北京）网络技术有限公司 Block chain consensus method and system, computer storage medium and electronic device
CN111951108A (en) * 2020-08-10 2020-11-17 神话科技传媒(深圳)有限公司上海分公司 Chain structure design method with intelligent contract block chain with complete picture
CN112132579A (en) * 2020-09-30 2020-12-25 深圳前海微众银行股份有限公司 Block chain consensus node updating method and device
CN112367174A (en) * 2020-11-06 2021-02-12 深圳前海微众银行股份有限公司 Block chain consensus method and device based on attribute values

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110875893B (en) * 2018-08-29 2022-03-08 深圳启元信息服务有限公司 Consensus verification method, check node and block chain system

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109964446A (en) * 2018-06-08 2019-07-02 北京大学深圳研究生院 A kind of common recognition method based on ballot
WO2019232789A1 (en) * 2018-06-08 2019-12-12 北京大学深圳研究生院 Voting-based consensus method
CN109472593A (en) * 2018-10-10 2019-03-15 远光软件股份有限公司 A kind of settlement method based on block chain technology, device and block chain network
CN109559223A (en) * 2018-10-10 2019-04-02 远光软件股份有限公司 A kind of method of commerce based on block chain technology, device and block chain network
CN109639837A (en) * 2019-01-31 2019-04-16 东南大学 Block chain DPoS common recognition method based on faith mechanism
CN111327414A (en) * 2020-01-20 2020-06-23 布比（北京）网络技术有限公司 Block chain consensus method and system, computer storage medium and electronic device
CN111951108A (en) * 2020-08-10 2020-11-17 神话科技传媒(深圳)有限公司上海分公司 Chain structure design method with intelligent contract block chain with complete picture
CN112132579A (en) * 2020-09-30 2020-12-25 深圳前海微众银行股份有限公司 Block chain consensus node updating method and device
CN112367174A (en) * 2020-11-06 2021-02-12 深圳前海微众银行股份有限公司 Block chain consensus method and device based on attribute values

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FELIPE BRAVO-MARQUEZ等: "proof of learning： a blockchain consensus mechanism based on machine learning competitions", 2019 IEEE INTERNATIONAL CONFERENCE ON DECENTRALIZED APPLICATIONS AND INFRASTRUCTURES, pages 119 - 124 *
刘敖迪;杜学绘;王娜;李少卓;: "区块链技术及其在信息安全领域的研究进展", 软件学报, vol. 29, no. 07, pages 2092 - 2115 *
曹傧;林亮;李云;刘永相;熊炜;高峰;: "区块链研究综述", 重庆邮电大学学报(自然科学版), vol. 32, no. 01, pages 1 - 14 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113850600A (en) * 2021-12-01 2021-12-28 深圳前海微众银行股份有限公司 Transaction consensus method, device, equipment and storage medium based on block chain
CN117614611A (en) * 2024-01-24 2024-02-27 苏州元脑智能科技有限公司 Block chain consensus method, system and storage medium
CN117614611B (en) * 2024-01-24 2024-04-12 苏州元脑智能科技有限公司 Block chain consensus method, system and storage medium

Also Published As

Publication number Publication date
CN113254526B (en) 2024-07-05

Similar Documents

Publication Publication Date Title
KR102237219B1 (en) Achieving consensus among network nodes in a distributed system
US11128522B2 (en) Changing a master node in a blockchain system
CN110351133B (en) Method and device for main node switching processing in block chain system
CN111066046B (en) Replay attack resistant authentication protocol
KR102134549B1 (en) Change of primary node in distributed system
US11283634B2 (en) System and method for detecting replay attack
RU2718411C1 (en) Performing a recovery process for a network node in a distributed system
CN108492103B (en) Joint block chain consensus method
EP3545665B1 (en) System and method for detecting replay attack
EP3693886A1 (en) Optimizations for verification of interactions system and method
US20200128043A1 (en) System and method for detecting replay attack
US10735464B2 (en) System and method for detecting replay attack
CN111418183B (en) Asynchronous processing of blockchain blocks
JP2022508247A (en) High-performance distributed recording system with reliability-based consensus
EP3659319B1 (en) Improved anti-replay device based on memory space interchange
CN110612700A (en) Authentication based on recovered public key
Jalalzai et al. Window based BFT blockchain consensus
CN113254526B (en) Block chain consensus method, device and system
CN113064764B (en) Method and apparatus for executing blocks in a blockchain system
CN113326332B (en) Snapshot synchronization method and device of blockchain
CN112039837B (en) Electronic evidence preservation method based on block chain and secret sharing
CN113810185A (en) Anti-trapdoor leakage on-chain data restoration system and method
CN113922953B (en) Data processing method and device
Hong et al. BeOAC: Blockchain-enabled offline audit scheme in cross-chain interaction
CN115439110A (en) Multi-signature chain crossing method and system based on Raft consensus

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
GR01 Patent grant
GR01 Patent grant