CN111756548A - Node consensus mechanism optimization method, system, device and storage medium - Google Patents
Node consensus mechanism optimization method, system, device and storage medium Download PDFInfo
- Publication number
- CN111756548A CN111756548A CN202010562221.3A CN202010562221A CN111756548A CN 111756548 A CN111756548 A CN 111756548A CN 202010562221 A CN202010562221 A CN 202010562221A CN 111756548 A CN111756548 A CN 111756548A
- Authority
- CN
- China
- Prior art keywords
- node
- message
- agenda
- consensus
- block
- 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 68
- 230000007246 mechanism Effects 0.000 title claims abstract description 65
- 238000005457 optimization Methods 0.000 title claims abstract description 37
- 230000004044 response Effects 0.000 claims abstract description 91
- 238000012795 verification Methods 0.000 claims description 43
- 238000012790 confirmation Methods 0.000 claims description 15
- 238000004806 packaging method and process Methods 0.000 claims description 14
- 238000012545 processing Methods 0.000 claims description 6
- 230000001960 triggered effect Effects 0.000 abstract description 6
- 230000008569 process Effects 0.000 description 16
- 238000004891 communication Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 5
- 230000010076 replication Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 206010000117 Abnormal behaviour Diseases 0.000 description 2
- 241000282414 Homo sapiens Species 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 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
- 238000012552 review Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000010200 validation analysis Methods 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
- H04L9/3247—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 involving digital signatures
-
- 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
-
- 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/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a node consensus mechanism optimization method, a system, equipment and a storage medium, wherein the node consensus mechanism optimization method optimizes a consensus module block cutting mechanism on the premise of Byzantine fault tolerance, and increases a transaction number dimension block cutting rule on the basis of the original time dimension block cutting, so that when the transaction number reaches a configured threshold value, the block cutting can be triggered; when the target block achieves node consensus, the response of each node is sent to the client sending the request, so that the block output is finally completed, and the block output speed is lower than the threshold configured by the time dimension theoretically, so that the block output efficiency is improved.
Description
Technical Field
The present invention relates to the field of block chain technologies, and in particular, to a method, a system, a device, and a storage medium for optimizing a node consensus mechanism.
Background
With the birth of the blockchain, the possibility of human beings to reconstruct a true trusted value network is marked. The blockchain architecture is a distributed architecture. The deployment mode comprises three types, namely a public chain, a alliance chain and a private chain, and corresponds to a decentralized distributed system, a partial decentralized distributed system and a weak central distributed system. In a distributed system, a plurality of hosts form a network cluster through asynchronous communication. In such an asynchronous system, state replication between hosts is required to ensure that each host has consistent state consensus. However, in asynchronous systems, faulty hosts that cannot communicate may occur, and the performance of the hosts may degrade and the network may become congested, which may result in error messages propagating within the system. Therefore, fault tolerance protocol is defined in the asynchronous network with unreliable default to ensure that each host achieves safe and reliable status consensus.
The Byzantine fault-tolerant technology is a fault-tolerant technology in the field of distributed computing. The byzantine assumption is a modeling of the real world, and unpredictable behavior of computers and networks may occur due to hardware errors, network congestion or interruption, and malicious attacks. Byzantine fault tolerance techniques are designed to handle these abnormal behaviors and meet the specification requirements of the problem to be solved. However, the existing Byzantine fault-tolerant block output mechanism is cut into blocks according to the time dimension, so that the technical problem of low block output efficiency of the existing Byzantine fault-tolerant consensus mechanism is caused.
The above is only for the purpose of assisting understanding of the technical aspects of the present invention, and does not represent an admission that the above is prior art.
Disclosure of Invention
The invention mainly aims to provide a node consensus mechanism optimization method, and aims to solve the technical problem of low block output efficiency of the existing Byzantine fault-tolerant consensus mechanism.
In order to achieve the above object, the present invention provides a node consensus mechanism optimization method, which is applied to a byzantine fault-tolerant system, where the byzantine fault-tolerant system includes a client, an agenda node, and the node consensus mechanism optimization method includes:
when a transaction request sent by a client is received, acquiring a current transaction based on the transaction request;
generating a target block according to a preset block-out rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each conference member node, wherein the preset block-out rule is formulated based on preset waiting time and preset transaction quantity;
when detecting multiple rounds of message consensus of the target block based on the first message signature through each agent node, acquiring a target response result of each agent node to the target block, and determining that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
Optionally, the step of generating a target block according to a preset block rule and the current transaction includes:
judging whether the current preset system parameters meet the preset block output rule, wherein the preset block output rule is as follows: the transaction quantity of the current transaction exceeds the preset transaction quantity, or the current waiting time reaches the preset waiting time;
and if so, cutting and packaging the current transaction into a message body waiting for consensus to be used as the target block.
Optionally, before the step of detecting that the target block is identified by multiple rounds of messages signed by the respective agenda nodes based on the first message, the method further includes:
judging whether the related information of the target block passes the verification of each agenda node;
and if so, judging that the target block is identified by multiple rounds of messages of each agenda node.
Optionally, the step of obtaining the target response result of each of the agenda nodes to the target block includes:
writing the verified target blocks passing through each said agenda node into a local block file and a database;
and based on each of the agenda nodes, packaging a response message signature for the target blocks passing the verification of each of the agenda nodes, and taking the target blocks packaged with the response message signature as the target response result.
Optionally, the step of determining whether the information related to the target block has passed the verification of each of the agenda nodes includes:
in a first round of message consensus, judging whether the transaction in the target block and the first message signature are both correct or not based on each agenda node;
if yes, packaging a second message signature on the target block, receiving and verifying a first response message generated by each agenda node, and entering a second round of message consensus stage;
and when the first response message is detected to pass through a second round message consensus stage of each member node based on the second message signature, determining that the related information of the target block passes the verification of each member node.
Optionally, the second round of message consensus comprises a confirmation phase and a response phase, and before the step of detecting that the first response message passes through the second round of message consensus phase of each of the agenda nodes based on the second message signature, the method further comprises:
in the confirmation phase, determining whether the first response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the first response messages passing the verification is larger than or equal to a preset threshold value or not based on each agenda node;
if yes, the target block is packaged with a confirmation message signature based on each chairman node, and a confirmation response message generated by each chairman node is received and verified to enter the response stage;
in the response phase, determining whether the acknowledgement response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the confirmed response messages passing the verification is greater than or equal to the preset threshold value or not based on each agenda node;
and if so, determining that the first response message passes through a second round message consensus stage of each agenda node based on the second message signature.
Optionally, after the step of determining whether the information related to the target block passes the verification of each of the agenda nodes, the method further includes:
if not, the chairman node is replaced, and the replaced chairman node is used for generating the block.
In addition, to achieve the above object, the present invention further provides an optimized byzantine fault-tolerant system, including:
the system comprises a transaction acquisition module, a transaction processing module and a transaction processing module, wherein the transaction acquisition module is used for acquiring a current transaction based on a transaction request sent by a client when the transaction request is received;
the block sending module is used for generating a target block according to a preset block outlet rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each agenda node, wherein the preset block outlet rule is formulated based on preset waiting time and preset transaction quantity;
and the node consensus module is used for acquiring target response results of the agent nodes to the target block when detecting that the target block passes through multiple rounds of message consensus of the agent nodes based on the first message signature, so as to determine that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
In addition, to achieve the above object, the present invention further provides a node consensus mechanism optimizing device, including: the node consensus mechanism optimization method comprises a memory, a processor and a node consensus mechanism optimization program stored on the memory and operable on the processor, wherein the node consensus mechanism optimization program when executed by the processor implements the steps of the node consensus mechanism optimization method as described above.
In addition, to achieve the above object, the present invention further provides a computer-readable storage medium, having a node consensus optimization program stored thereon, where the node consensus optimization program, when executed by a processor, implements the steps of the node consensus optimization method as described above.
The invention provides a node consensus mechanism optimization method, a node consensus mechanism optimization system, a node consensus mechanism optimization device and a storage medium. The node consensus mechanism optimization method obtains the current transaction based on a transaction request when receiving the transaction request sent by a client; generating a target block according to a preset block-out rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each conference member node, wherein the preset block-out rule is formulated based on preset waiting time and preset transaction quantity; when detecting multiple rounds of message consensus of the target block based on the first message signature through each agent node, acquiring a target response result of each agent node to the target block, and determining that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard. Through the mode, on the premise of Byzantine fault tolerance, a common identification module block cutting mechanism is optimized, and a block cutting rule of transaction quantity dimension is added on the basis of the original block cutting according to time dimension, so that when the transaction quantity reaches a configured threshold value, the block cutting is also triggered; when the node consensus is achieved in the target block, the response of each node is sent to the client sending the request, so that the block output is finally completed, the block output speed is lower than the threshold configured by the time dimension theoretically, the block output efficiency is improved, and the technical problem that the block output efficiency of the existing Byzantine fault-tolerant consensus mechanism is low is solved.
Drawings
Fig. 1 is a schematic structural diagram of a mobile terminal in a hardware operating environment according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating a node consensus optimization method according to a first embodiment of the present invention;
FIG. 3 is a schematic flow chart of an embodiment of the present invention;
fig. 4 is a functional block diagram of the first embodiment of the optimized byzantine fault-tolerant system according to the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
As shown in fig. 1, fig. 1 is a schematic terminal structure diagram of a hardware operating environment according to an embodiment of the present invention.
The terminal of the embodiment of the invention can be a PC, and can also be a mobile terminal device with a display function, such as a smart phone, a tablet computer, an e-book reader and the like.
As shown in fig. 1, the terminal may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 1005 may alternatively be a memory device separate from the processor 1001 described above.
Those skilled in the art will appreciate that the terminal structure shown in fig. 1 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
As shown in fig. 1, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a node consensus mechanism optimization program.
In the terminal shown in fig. 1, the network interface 1004 is mainly used for connecting to a backend server and performing data communication with the backend server; the user interface 1003 is mainly used for connecting a client (user side) and performing data communication with the client; and the processor 1001 may be configured to invoke the node consensus mechanism optimization program stored in the memory 1005 and perform the following operations:
when a transaction request sent by a client is received, acquiring a current transaction based on the transaction request;
generating a target block according to a preset block-out rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each conference member node, wherein the preset block-out rule is formulated based on preset waiting time and preset transaction quantity;
when detecting multiple rounds of message consensus of the target block based on the first message signature through each agent node, acquiring a target response result of each agent node to the target block, and determining that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
judging whether the current preset system parameters meet the preset block output rule, wherein the preset block output rule is as follows: the transaction quantity of the current transaction exceeds the preset transaction quantity, or the current waiting time reaches the preset waiting time;
and if so, cutting and packaging the current transaction into a message body waiting for consensus to be used as the target block.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
judging whether the related information of the target block passes the verification of each agenda node;
and if so, judging that the target block is identified by multiple rounds of messages of each agenda node.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
writing the verified target blocks passing through each said agenda node into a local block file and a database;
and based on each of the agenda nodes, packaging a response message signature for the target blocks passing the verification of each of the agenda nodes, and taking the target blocks packaged with the response message signature as the target response result.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
in a first round of message consensus, judging whether the transaction in the target block and the first message signature are both correct or not based on each agenda node;
if yes, packaging a second message signature on the target block, receiving and verifying a first response message generated by each agenda node, and entering a second round of message consensus stage;
and when the first response message is detected to pass through a second round message consensus stage of each member node based on the second message signature, determining that the related information of the target block passes the verification of each member node.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
in the confirmation phase, determining whether the first response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the first response messages passing the verification is larger than or equal to a preset threshold value or not based on each agenda node;
if yes, the target block is packaged with a confirmation message signature based on each chairman node, and a confirmation response message generated by each chairman node is received and verified to enter the response stage;
in the response phase, determining whether the acknowledgement response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the confirmed response messages passing the verification is greater than or equal to the preset threshold value or not based on each agenda node;
and if so, determining that the first response message passes through a second round message consensus stage of each agenda node based on the second message signature.
Further, the processor 1001 may call the node consensus mechanism optimization program stored in the memory 1005, and further perform the following operations:
if not, the chairman node is replaced, and the replaced chairman node is used for generating the block.
Based on the hardware structure, the invention provides various embodiments of the node consensus mechanism optimization method. With the birth of the blockchain, the possibility of human beings to reconstruct a true trusted value network is marked. The blockchain architecture is a distributed architecture. The deployment mode comprises three types, namely a public chain, a alliance chain and a private chain, and corresponds to a decentralized distributed system, a partial decentralized distributed system and a weak central distributed system. In a distributed system, a plurality of hosts form a network cluster through asynchronous communication. In such an asynchronous system, state replication between hosts is required to ensure that each host has consistent state consensus. However, in asynchronous systems, faulty hosts that cannot communicate may occur, and the performance of the hosts may degrade and the network may become congested, which may result in error messages propagating within the system. Therefore, fault tolerance protocol is defined in the asynchronous network with unreliable default to ensure that each host achieves safe and reliable status consensus.
The Byzantine fault-tolerant technology is a fault-tolerant technology in the field of distributed computing. The byzantine assumption is a modeling of the real world, and unpredictable behavior of computers and networks may occur due to hardware errors, network congestion or interruption, and malicious attacks. Byzantine fault tolerance techniques are designed to handle these abnormal behaviors and meet the specification requirements of the problem to be solved. However, the existing Byzantine fault-tolerant block output mechanism is cut into blocks according to the time dimension, so that the technical problem of low block output efficiency of the existing Byzantine fault-tolerant consensus mechanism is caused.
In order to solve the above problems, the present invention provides a node consensus mechanism optimization method, which is used to optimize a process of performing consensus on the same message between nodes. On the premise of Byzantine fault tolerance, a common identification module block cutting mechanism is optimized, and a block cutting rule of transaction quantity dimension is added on the basis of the original block cutting according to time dimension, so that when the transaction quantity reaches a configured threshold value, the block cutting is also triggered; when the node consensus is achieved in the target block, the response of each node is sent to the client sending the request, so that the block output is finally completed, the block output speed is lower than the threshold configured by the time dimension theoretically, the block output efficiency is improved, and the technical problem that the block output efficiency of the existing Byzantine fault-tolerant consensus mechanism is low is solved. The node consensus mechanism optimization method is applied to optimizing the Byzantine fault-tolerant system.
Referring to fig. 2, fig. 2 is a flowchart illustrating a first embodiment of a node consensus mechanism optimization method.
A first embodiment of the present invention provides a node consensus mechanism optimization method, where the node consensus mechanism optimization method includes the following steps:
step S10, when a transaction request sent by a client is received, acquiring a current transaction based on the transaction request;
in this embodiment, the optimized Byzantine Fault-tolerant system in the present invention is an improvement on a block output mechanism thereof based on a Practical Byzantine Fault-tolerant system (PBFT). It should be noted that PBFT is a state machine copy replication algorithm, that is, a service is modeled as a state machine, and the state machine performs copy replication at different nodes of a distributed system. The copies of each state machine preserve the state of the service and also enable the operation of the service. The set of all replicas is represented using the capital letter R, each replica being represented using an integer from 0 to | R | -1. For the convenience of description, it is generally assumed that the number of failed nodes is f, and the number of entire service nodes is | R | — 3f +1, where f is the maximum number of copies that may fail. Although there may be more than 3f +1 copies, the additional copies may not improve reliability except for reduced performance. The PBFT reduces the running complexity of the Byzantine protocol from an exponential level to a polynomial level, and makes the application of the Byzantine protocol in a distributed system possible. PBFT requires that a state be maintained in common and that actions be taken by all nodes be consistent. To do this, three basic types of protocols need to be run, including a consistency protocol, a checkpoint protocol, and a view change protocol.
When the client sends a request to the optimized Byzantine fault-tolerant system, the system receives the request, namely, the initial chairman node can be controlled to process the request, and the transaction in the request is obtained.
Step S20, generating a target block according to a preset block rule and the current transaction, so that the conference node encapsulates the target block with a first message signature, and sends the target block to each of the agenda nodes, wherein the preset block rule is formulated based on a preset waiting time and a preset transaction number;
in this embodiment, it should be noted that the chairman node is the master node, and the role is mainly to perform block output, package the received transaction into a block after verification, add its own signature, and send it to the agenda node for examination. The deputy node is the slave node and is mainly used for reviewing the blocks sent by the deputy and checking the transactions in the blocks, and if no error exists, performing the pass review. If there is a timeout or a problem with the transaction, an operation flow to replace the chairman may be performed. The calculation mode of the chairman node is as follows: p ═ v + k)% n, n is the number of consensus nodes of the agenda nodes, and needs to be an odd number. Initially, k is 0, v is ix, and ix is a preconfigured value. Thus, the initial talker node is v% n.
The preset block-out rule is formulated based on two dimensions of a time dimension and a transaction quantity dimension. The block is triggered when the wait time meets a certain threshold or the number of transactions reaches a certain threshold. The first message signature is the chairman node's own signature. When the current block matching rule is met, the system controls the initial agenda node to check the current transaction, and then cuts and packs the transaction into a message body waiting for consensus to generate a target block.
Step S30, when detecting multiple rounds of message consensus of the target block based on the first message signature by each of the agent nodes, obtaining a target response result of each of the agent nodes to the target block, so as to determine that node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
In this embodiment, the multiple rounds of message consensus on the target block by each agenda node refer to the stages involved in the above-mentioned coherency protocol. The coherence protocol comprises at least several phases: request (Request), sequence number assignment (Pre-Prepare), and response (Reply). Depending on the protocol design, it may include stages such as Prepare, sequence number validation (Commit), etc. After completing multiple rounds of message consensus of each agent node, if each node collects message signatures with the quantity meeting 2f +1, the target block can be judged to pass through the multiple rounds of message consensus of each agent node, the node consensus is achieved currently, and the response is the operation result.
As a specific example, as shown in fig. 3. Meaning of the fields in the figure: b represents block data; h represents the target block height; bH denotes block Hash; v represents the view number of the chairman node; i represents a view number of the current node; d represents a digest of the message. When receiving a request sent by a client, the system elects an initial chairman node according to preset configuration information, and controls the chairman node to generate a target block based on the request of the client when the current chairman node meets a preset block output rule. The chairman node encapsulates the generated target block with a < PreRequest, b, h, v, i, d > message signature and then sends the message signature to each agenda node. After receiving the message, each agenda node verifies the < PreRequest, b, h, v, i, d > message signature and the transaction in the target block, and judges whether the message signature is correct or not. If not, the process of replacing the current chairman node is carried out; if the agreement is correct, the agenda node encapsulates the < PreResponse, bH, h, v, i, d > message signature and then sends the message signature to other consensus nodes. The consensus node receives and checks the PreResponse message and determines whether the message is time out. If the node is overtime, the process of replacing the current chairman node is carried out; if not, continuously judging whether the checked PreResponse number is larger than or equal to f. If not, the process of replacing the current chairman node is carried out, if yes, the encapsulation of < Commit, bH, h, v, i, d > message signature is carried out on the current target block, and the current target block is sent to other common identification nodes. And the consensus node receives and checks the PreResponse message and judges whether the message is overtime. If the node is overtime, the process of replacing the current chairman node is carried out; and if not, continuously judging whether the number of Commit passing the verification is larger than or equal to f. If not, the process of replacing the current chairman node is carried out; if yes, writing the current target block into a local block file and a database, packaging the message signature by the consensus node, packaging the < Reply, b, i, dCommitarray > message signature by the target block, and then sending the message signature to other common nodes.
In the embodiment, when a transaction request sent by a client is received, a current transaction is obtained based on the transaction request; generating a target block according to a preset block-out rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each conference member node, wherein the preset block-out rule is formulated based on preset waiting time and preset transaction quantity; when detecting multiple rounds of message consensus of the target block based on the first message signature through each agent node, acquiring a target response result of each agent node to the target block, and determining that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard. Through the mode, on the premise of Byzantine fault tolerance, a common identification module block cutting mechanism is optimized, and a block cutting rule of transaction quantity dimension is added on the basis of the original block cutting according to time dimension, so that when the transaction quantity reaches a configured threshold value, the block cutting is also triggered; when the node consensus is achieved in the target block, the response of each node is sent to the client sending the request, so that the block output is finally completed, the block output speed is lower than the threshold configured by the time dimension theoretically, the block output efficiency is improved, and the technical problem that the block output efficiency of the existing Byzantine fault-tolerant consensus mechanism is low is solved.
Further, not shown in the figure, based on the first embodiment shown in fig. 2, a second embodiment of the node consensus mechanism optimization method of the present invention is proposed. In this embodiment, before step S30, the method further includes:
judging whether the related information of the target block passes the verification of each agenda node;
and if so, judging that the target block is identified by multiple rounds of messages of each agenda node.
In this embodiment, the related information may include a message signature, transaction information, the number of messages passing the verification, and the like. The system determines whether the relevant information of the target block passes multiple verifications of the agenda node in each stage, for example, whether the message is overtime, whether the verified message meets a threshold, whether the message signature passes verification, and the like. If the system determines whether the related information of the target block passes the verification of each agenda node, the system can determine that the target block passes multiple rounds of message consensus of each agenda node.
Further, in the present embodiment, step S30 includes:
writing the verified target blocks passing through each said agenda node into a local block file and a database;
and based on each of the agenda nodes, packaging a response message signature for the target blocks passing the verification of each of the agenda nodes, and taking the target blocks packaged with the response message signature as the target response result.
In this embodiment, the system writes the target blocks that have been verified by the current multiple agenda nodes into the local block file and database. And each agenda node packages a response message signature < Reply, b, i, dCommitarray > for the target block passing through the multi-round verification and sends the response message signature < Reply, b, i, dCommitarray > as a target response result to the client, and if the client receives more than or equal to f identical Reply messages, the client initiates a request to achieve the whole network consensus.
Further, in this embodiment, the step of determining whether the information related to the target block passes the verification of each of the agenda nodes includes:
in a first round of message consensus, judging whether the transaction in the target block and the first message signature are both correct or not based on each agenda node;
if yes, packaging a second message signature on the target block, receiving and verifying a first response message generated by each agenda node, and entering a second round of message consensus stage;
in this embodiment, the first round of message consensus phases may include a Pre-Prepare phase and a Prepare phase. The second message signature may be a message signature for encapsulation of the target tile by each talker node in the Pre-Prepare phase and the Prepare phase. The first response message is the response sent by each agenda node in the Pre-Prepare phase and the Prepare phase. It should be noted that the Request phase is a Request phase, the Pre-Prepare phase is a sequence number assignment phase, the Prepare phase is an interaction phase, the Commit phase is a sequence number confirmation phase, and the Reply phase is a response phase.
Specifically, it should be noted that, in the Request phase before the Pre-Prepare phase: the client sends a < Request, o, t, c > Request to the agenda node. o: specific operation of the request, t: timestamp added by client when requesting, c: and identifying the client. The Request contains the message content m, and the message digest d (m). The client signs the request. In the Pre-Prepare phase, the agenda node receives the client's request and needs to check: the client requests whether the message signature is correct. The illegal request is discarded. And if the request is correct, allocating a number n, wherein the number n is mainly used for sequencing the request of the client. Then broadcasts a < < Pre-Premate, v, n, d >, m > message to the other talker nodes. v: view number, d client message digest, m message content. < Pre-Prepare, v, n, d > master node signature. n is [ H, H ] within a certain range interval.
In the Prepare stage: the talker node i receives the Pre-Prepare message from the master node, and needs to check: whether the prey node Pre-Prepare message signature is correct or not; whether the current agenda node has received a PRE-prefix message under the same v and with the number n, but with a different signature; whether the d is consistent with the abstract of the m; whether n is within the interval [ H, H ]. The illegal request is discarded. Upon a correct request, replica node i sends a < Prepare, v, n, d, i > message to other nodes, including the chairman node, where v, n, d, m are the same as the content of the Pre-Prepare message, and i is the current talker node number. < Prepare, v, n, d, i > signature of the agenda node i. And recording the Pre-Prepare and the Prepare message into log for recovering the incomplete request operation in the ViewChange process.
And when the first response message is detected to pass through a second round message consensus stage of each member node based on the second message signature, determining that the related information of the target block passes the verification of each member node.
In this embodiment, if the system detects that the first response message passes the second round of message consensus, it may be determined that the information related to the target block has passed the verification of each of the agenda nodes. And if the node fails, carrying out a process of replacing the chairman node.
Further, in this embodiment, before the step of detecting that the first response message passes through a second round of message consensus phase of each of the agenda nodes based on the second message signature, the method further includes:
in the confirmation phase, determining whether the first response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the first response messages passing the verification is larger than or equal to a preset threshold value or not based on each agenda node;
in this embodiment, the preset threshold is f, where f is n-ceil (n/3), n is the number of the agenda nodes, and it needs to be an odd number. In the Commit phase: the parlor node and the parlor node receive the Prepare message and judge whether the message is overtime. If the time is out, the chairman node is replaced; if not, the following check is required: whether the parr node Prepare message signature is correct; whether the current agenda node has received n under the same view v; whether n is within the interval [ H, H ]; whether d is the same as d in the Pre-Prepare that has been currently received. If the verification is passed, judging whether the agenda node i receives the Prepare messages with the verification passing more than or equal to f.
If yes, the target block is packaged with a confirmation message signature based on each chairman node, and a confirmation response message generated by each chairman node is received and verified to enter the response stage;
in this embodiment, if the agent node i receives more than or equal to f Prepare messages that are verified, it sends a message < Commit, v, n, d, i > to other agent nodes including the chairman node, where v, n, d, i have the same content as the Prepare message. < Commit, v, n, d, i > signed by the agenda node i. And recording the Commit message into a log for recovering the incomplete request operation in the ViewChange process. And recording the Prepare messages sent by other agenda nodes into log and entering into a Reply phase.
In the response phase, determining whether the acknowledgement response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the confirmed response messages passing the verification is greater than or equal to the preset threshold value or not based on each agenda node;
in this embodiment, in the Reply stage: the parliament node and the parliament node receive the Commit message and judge whether the message is overtime. If the time is out, the chairman node is replaced; if not, the following check is required: whether the committee message signature is correct or not; whether the current agenda node has received n under the same view v; whether d is consistent with the digest of m. Whether n is within the interval [ H, H ]. If the verification is passed, judging whether the commander node i receives the Commit messages which are more than or equal to f verification passes.
And if so, determining that the first response message passes through a second round message consensus stage of each agenda node based on the second message signature.
In this embodiment, if the talker node i receives the Commit message with f or more verification passes, which indicates that most nodes in the current network have agreed, the request operation o of the client is executed, and < Reply, v, t, c, i, r > is returned to the client, r: if the request operation is the result, the system may determine that the first response message passes through the second round of message consensus phase. In addition, if the client receives more than or equal to f identical Reply messages, the request initiated by the client is proved to have achieved the whole network consensus, otherwise, the client needs to judge whether to resend the request to the chairman node. Record Commit messages sent by other agenda nodes into log.
In this embodiment, the security of the data is ensured by further performing multi-stage verification judgment on the target block and determining that the target block passes through multiple rounds of message consensus of each node only when the target block completely passes through all verification judgment of the multiple stages.
Further, not shown in the figure, a third embodiment of the node consensus mechanism optimization method according to the present invention is proposed based on the first embodiment and the second embodiment shown in fig. 2. In the present embodiment, step S20 includes:
judging whether the current preset system parameters meet the preset block output rule, wherein the preset block output rule is as follows: the transaction quantity of the current transaction exceeds the preset transaction quantity, or the current waiting time reaches the preset waiting time;
and if so, cutting and packaging the current transaction into a message body waiting for consensus to be used as the target block.
In this embodiment, the current preset system parameters include the transaction amount or current waiting time for the current transaction. The preset transaction amount and the preset waiting time are critical values for judging whether the block is produced currently by the system, and can be flexibly set according to actual conditions, and the embodiment is not specifically limited to this. The system determines whether the number of current transactions reaches a preset transaction number or whether a preset waiting time is met currently. If one item is met, the block-out condition is met currently, and the chairman node cuts and packages the current transaction into a message body waiting for consensus to be used as a target block. And if the two items are not met, judging that the block outlet condition is not met currently.
Further, in this embodiment, after the step of determining whether the information related to the target block passes the verification of each of the agenda nodes, the method further includes:
if not, the chairman node is replaced, and the replaced chairman node is used for generating the block.
In this embodiment, if the system determines that the information related to the target block fails one or more times in various verification determinations of the agenda node at each stage, for example, the message is overtime, and the number of messages passing the verification does not satisfy the threshold, the process of replacing the agenda node is performed, and the block is regenerated by using the replaced agenda.
In this embodiment, further based on a multi-dimensional block output rule and a time dimension block output mechanism, when the transaction number reaches a configured threshold, block cutting is also triggered, and theoretically, the block output speed is lower than the time dimension configured threshold, so that the system throughput of block output is improved; by replacing the chairman node when the target block does not pass the verification of each chairman node, the data security is ensured, and the process can be continued.
The invention also provides an optimized Byzantine fault-tolerant system.
The optimized Byzantine fault-tolerant system comprises:
the system comprises a transaction acquisition module, a transaction processing module and a transaction processing module, wherein the transaction acquisition module is used for acquiring a current transaction based on a transaction request sent by a client when the transaction request is received;
the block sending module is used for generating a target block according to a preset block outlet rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each agenda node, wherein the preset block outlet rule is formulated based on preset waiting time and preset transaction quantity;
and the node consensus module is used for acquiring target response results of the agent nodes to the target block when detecting that the target block passes through multiple rounds of message consensus of the agent nodes based on the first message signature, so as to determine that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
The invention also provides a node consensus mechanism optimization device.
The node consensus mechanism optimization device comprises a processor, a memory and a node consensus mechanism optimization program stored on the memory and executable on the processor, wherein the node consensus mechanism optimization program when executed by the processor implements the steps of the node consensus mechanism optimization method as described above.
The method implemented when the node consensus optimization program is executed may refer to each embodiment of the node consensus optimization method of the present invention, and details thereof are not repeated herein.
The invention also provides a computer readable storage medium.
The computer readable storage medium of the present invention stores thereon a node consensus optimization program, which when executed by a processor implements the steps of the node consensus optimization method as described above.
The method implemented when the node consensus optimization program is executed may refer to each embodiment of the node consensus optimization method of the present invention, and details thereof are not repeated herein.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) as described above and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (10)
1. A node consensus mechanism optimization method is applied to an optimized Byzantine fault-tolerant system, wherein the optimized Byzantine fault-tolerant system comprises a client, an agenda node and an agenda node, and the node consensus mechanism optimization method comprises the following steps:
when a transaction request sent by a client is received, acquiring a current transaction based on the transaction request;
generating a target block according to a preset block-out rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each conference member node, wherein the preset block-out rule is formulated based on preset waiting time and preset transaction quantity;
when detecting multiple rounds of message consensus of the target block based on the first message signature through each agent node, acquiring a target response result of each agent node to the target block, and determining that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
2. The node consensus mechanism optimization method of claim 1, wherein the step of generating a target block with the current transaction according to a preset block rule comprises:
judging whether the current preset system parameters meet the preset block output rule, wherein the preset block output rule is as follows: the transaction quantity of the current transaction exceeds the preset transaction quantity, or the current waiting time reaches the preset waiting time;
and if so, cutting and packaging the current transaction into a message body waiting for consensus to be used as the target block.
3. The node consensus mechanism optimization method of claim 1, wherein prior to the step of detecting multiple rounds of message consensus of the target block based on the first message signature by each of the agenda nodes, further comprising:
judging whether the related information of the target block passes the verification of each agenda node;
and if so, judging that the target block is identified by multiple rounds of messages of each agenda node.
4. The node consensus mechanism optimization method of claim 3, wherein the step of obtaining the target response result of each of the agenda nodes to the target block comprises:
writing the verified target blocks passing through each said agenda node into a local block file and a database;
and based on each of the agenda nodes, packaging a response message signature for the target blocks passing the verification of each of the agenda nodes, and taking the target blocks packaged with the response message signature as the target response result.
5. The method of claim 3, wherein the step of determining whether the information related to the target block has been verified by each of the agenda nodes comprises:
in a first round of message consensus, judging whether the transaction in the target block and the first message signature are both correct or not based on each agenda node;
if yes, packaging a second message signature on the target block, receiving and verifying a first response message generated by each agenda node, and entering a second round of message consensus stage;
and when the first response message is detected to pass through a second round message consensus stage of each member node based on the second message signature, determining that the related information of the target block passes the verification of each member node.
6. The node consensus mechanism optimization method of claim 5, wherein the second round of message consensus phases comprises a confirmation phase and a response phase, further comprising, before the step of detecting a second round of message consensus phases when the first response message is signed by each of the agenda nodes based on the second message:
in the confirmation phase, determining whether the first response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the first response messages passing the verification is larger than or equal to a preset threshold value or not based on each agenda node;
if yes, the target block is packaged with a confirmation message signature based on each chairman node, and a confirmation response message generated by each chairman node is received and verified to enter the response stage;
in the response phase, determining whether the acknowledgement response message is time-out based on each of the agenda nodes;
if not, judging whether the number of the confirmed response messages passing the verification is greater than or equal to the preset threshold value or not based on each agenda node;
and if so, determining that the first response message passes through a second round message consensus stage of each agenda node based on the second message signature.
7. The method according to any one of claims 3 to 6, wherein after the step of determining whether the information related to the target block has passed the verification of each of the agenda nodes, the method further comprises:
if not, the chairman node is replaced, and the replaced chairman node is used for generating the block.
8. An optimized Byzantine fault tolerant system, comprising:
the system comprises a transaction acquisition module, a transaction processing module and a transaction processing module, wherein the transaction acquisition module is used for acquiring a current transaction based on a transaction request sent by a client when the transaction request is received;
the block sending module is used for generating a target block according to a preset block outlet rule and the current transaction, so that the conference node packages a first message signature on the target block and sends the target block to each agenda node, wherein the preset block outlet rule is formulated based on preset waiting time and preset transaction quantity;
and the node consensus module is used for acquiring target response results of the agent nodes to the target block when detecting that the target block passes through multiple rounds of message consensus of the agent nodes based on the first message signature, so as to determine that the node consensus is achieved when detecting that the number of the target response results reaches a preset standard.
9. A node consensus mechanism optimizing device, the node consensus mechanism optimizing device comprising: a memory, a processor, and a node consensus mechanism optimization program stored on the memory and executable on the processor, the node consensus mechanism optimization program when executed by the processor implementing the steps of the node consensus mechanism optimization method of any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a node consensus mechanism optimization program, which when executed by a processor, implements the steps of the node consensus mechanism optimization method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010562221.3A CN111756548A (en) | 2020-06-17 | 2020-06-17 | Node consensus mechanism optimization method, system, device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010562221.3A CN111756548A (en) | 2020-06-17 | 2020-06-17 | Node consensus mechanism optimization method, system, device and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111756548A true CN111756548A (en) | 2020-10-09 |
Family
ID=72675383
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010562221.3A Pending CN111756548A (en) | 2020-06-17 | 2020-06-17 | Node consensus mechanism optimization method, system, device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111756548A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113259326A (en) * | 2021-04-21 | 2021-08-13 | 广东电网有限责任公司 | Consensus optimization method and device based on alliance chain network and computer equipment |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109194472A (en) * | 2018-09-19 | 2019-01-11 | 广东微链科技有限公司 | Game block chain common recognition method based on bilinear map and set signature algorithm |
| CN109246122A (en) * | 2018-09-29 | 2019-01-18 | 上海海事大学 | A kind of Byzantine failure tolerance block chain generation method based on gossip propagation agreement |
| WO2019228561A2 (en) * | 2019-09-02 | 2019-12-05 | Alibaba Group Holding Limited | Managing blockchain-based centralized ledger systems |
-
2020
- 2020-06-17 CN CN202010562221.3A patent/CN111756548A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109194472A (en) * | 2018-09-19 | 2019-01-11 | 广东微链科技有限公司 | Game block chain common recognition method based on bilinear map and set signature algorithm |
| CN109246122A (en) * | 2018-09-29 | 2019-01-18 | 上海海事大学 | A kind of Byzantine failure tolerance block chain generation method based on gossip propagation agreement |
| WO2019228561A2 (en) * | 2019-09-02 | 2019-12-05 | Alibaba Group Holding Limited | Managing blockchain-based centralized ledger systems |
Non-Patent Citations (1)
| Title |
|---|
| 韩嗣诚等: "优化可扩展的拜占庭容错共识算法", 《物联网学报》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113259326A (en) * | 2021-04-21 | 2021-08-13 | 广东电网有限责任公司 | Consensus optimization method and device based on alliance chain network and computer equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110648137B (en) | Block processing method, node and system | |
| CN111630826B (en) | Consensus system and method | |
| CN110730225A (en) | Data processing method of Internet of things based on block chain, Internet of things and storage medium | |
| Haeberlen et al. | PeerReview: Practical accountability for distributed systems | |
| Kotla et al. | Zyzzyva: speculative byzantine fault tolerance | |
| CN111586147B (en) | Node synchronization method, device, equipment and storage medium of block chain | |
| Nawab et al. | Blockplane: A global-scale byzantizing middleware | |
| CN110569251A (en) | Data processing method, related equipment and computer readable storage medium | |
| CN111163182A (en) | Block chain-based device registration method and apparatus, electronic device, and storage medium | |
| CN112527534A (en) | Service processing method, device, equipment and storage medium based on message queue | |
| CN112015811B (en) | Method, node and computing device for node management of blockchain systems | |
| CN111414413A (en) | Block chain endorsement verification | |
| CN112035472B (en) | Data processing method, device, computer equipment and storage medium | |
| Jalalzai et al. | Window based BFT blockchain consensus | |
| WO2023040364A1 (en) | Consensus method and apparatus, and blockchain system | |
| CN111339551B (en) | Data verification method and related device and equipment | |
| JP2022523217A (en) | Topology Driven Byzantine Fault Tolerant Consensus Protocol with Voting Aggregation | |
| WO2023040453A1 (en) | Transaction information processing method and apparatus | |
| US11483158B2 (en) | Distributed ledger device, distributed ledger system, and distributed ledger management method | |
| CN111722946A (en) | Distributed transaction processing method and device, computer equipment and readable storage medium | |
| Correia et al. | Worm-IT–a wormhole-based intrusion-tolerant group communication system | |
| Zhao | A byzantine fault tolerant distributed commit protocol | |
| CN111756548A (en) | Node consensus mechanism optimization method, system, device and storage medium | |
| CN110908801B (en) | Data processing method and device based on block chain, computer equipment and storage medium | |
| CN116846888A (en) | Consensus processing method, device, equipment and storage medium of block chain network |
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 | ||
| AD01 | Patent right deemed abandoned | ||
| AD01 | Patent right deemed abandoned |
Effective date of abandoning: 20231110 |