CN113949518A - Consensus method and system for improving block chain throughput - Google Patents
Consensus method and system for improving block chain throughput Download PDFInfo
- Publication number
- CN113949518A CN113949518A CN202111208576.3A CN202111208576A CN113949518A CN 113949518 A CN113949518 A CN 113949518A CN 202111208576 A CN202111208576 A CN 202111208576A CN 113949518 A CN113949518 A CN 113949518A
- Authority
- CN
- China
- Prior art keywords
- node
- replica
- consensus
- nodes
- aggqc
- 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 20
- 230000002159 abnormal effect Effects 0.000 claims description 3
- 230000004043 responsiveness Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- 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
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention belongs to the technical field of block chains, and particularly relates to a consensus method and a consensus system for improving the throughput of a block chain. The node types of the consensus system are divided into three types, namely a main node, an auxiliary main node and a replica node; the method of the consensus system for improving the block chain throughput comprises a NewView stage; a Prepare stage; a PreCommit stage; a Commit stage; a consensus method and a system for improving block chain throughput solve the problem that the throughput is greatly reduced when a main node generates errors after a first round of voting in the conventional consensus system.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a consensus method and a consensus system for improving the throughput of a block chain.
Background
The consensus algorithm can be classified into a fault Tolerance (CFT) consensus algorithm and a Byzantine Fault Tolerance (BFT) consensus algorithm according to the fault Tolerance type. The fault tolerance consensus algorithm mainly adopts Paxos, Raft and the like, can only tolerate errors such as downtime of nodes, and cannot ensure the consistency of honest node data if malicious nodes exist.
At present, the complexity of the HotStuff consensus algorithm is much lower than that of other consensus algorithms, so that the HotStuff consensus algorithm is concerned widely. The common recognition of Optimistic Responsiveness (Optimistic Responsiveness) is achieved by three rounds of voting for five stages (NewView, Prepare, PreCommit, Commit, Decide); then, based on the fact that Fast-HostStuff is proposed, aggregation signatures are used for replacing threshold signatures in HotStuff in a New View stage, HotStuff of four stages (New View, Prepare, PreCommit and Commit) of two-round voting is achieved, and execution efficiency is improved. However, in both algorithms, when the master node has an error after the first round of voting, the throughput is greatly reduced.
Therefore, we propose a consensus method and system for improving the throughput of the blockchain.
Disclosure of Invention
The invention aims to provide a consensus method and a consensus system for improving block chain throughput, so as to solve the problem that the throughput is greatly reduced when a master node generates errors after a first round of voting in the consensus system.
A common identification system for improving the throughput of a block chain is characterized in that the node types of the common identification system are divided into three types, namely a main node, an auxiliary main node and a replica node; one main node controls the consensus, and when the main node is in downtime or abnormal attack, one secondary main node controls the consensus.
Furthermore, the number of the main nodes and the auxiliary main nodes in the nodes is given to be 1, and the rest are replica nodes.
Further, each view in the consensus system has a view number, and the view numbers are non-repeating and monotonically increasing.
Further, the number of nodes S of the consensus system satisfies S3 f +2, where the number of nodes is S and the maximum allowable fault tolerance number is f.
A method for a consensus system for improving blockchain throughput, comprising the steps of:
s1 NewView stage: after the master node and the auxiliary master node receive the NewView messages sent by the S-f replica nodes, the messages and the signatures are simultaneously aggregated into aggQC, and the aggQC comprises the prepareQC with the largest view number stored by the replica nodes;
s2 preparation stage: judging whether the new block and aggQC received by the replica node are obtained by the broadcast of the main node, and then sending a PrepareVote message to perform a first round of voting;
s3 PreCommit stage: judging whether the main node is down or abnormally attacked, broadcasting PreCommit information containing prepareQC to the whole network, and performing a second round of voting;
s4 Commit stage: the block is submitted into a blockchain.
Further, in step S1, the NewView message includes a prepareQC with the largest view number stored in the replica node.
Further, in step S1, when the master node is not down or abnormally attacked, the master node selects a block of prepareQC with the largest view number from all received messages to generate a new block, and then aggregates the collected messages and their signatures into aggqc (aggregate quality certificate).
Further, when the main node is not down or is not abnormally attacked, the main node broadcasts the new block and the aggQC in the whole network in the Prepare stage, and the duplicate node receives and votes (signs), and meanwhile, the memory of the secondary main node is released and no operation is performed any more.
Further, when the main node is down or abnormally attacked, the secondary main node broadcasts the new block and aggQC in the whole network in the Prepare stage, and the replica node receives and votes (signs).
Further, in step S1, when the master node goes down or is abnormally attacked, the secondary master node selects a block of the prepareQC with the largest view number from all received messages to generate a new block, then aggregates the collected messages and their signatures into aggQC (aggregate quality indicator), broadcasts the new block and aggQC in the Prepare stage in the whole network, and is accepted and voted (signed) by the replica node.
Further, in step S2, when the new tile and aggQC received by the duplicate node are obtained by broadcasting from the master node, the master node sends a preparVote message to perform a first round of voting after the voting (signature); otherwise, sending a PrepareVote message to the secondary main node for the first round of voting.
Further, in step S3, when the replica node receives the preconmit message broadcast by the master node, the second round of voting is performed by sending a preconmit vote message to the master node;
further, in step S3, when the master node is not down or abnormally attacked, and the master node receives the preparVote messages sent by the (S-f) replica nodes, the master node aggregates all the preparVote messages (instead of the S-f) and their signatures into prepareQC; otherwise, the secondary main nodes are aggregated into prepareQC; the PreCommit message containing prepareQC is then broadcast to the full network.
Further, in step S3, when the replica node receives the preconmit message broadcast by the secondary host node, the preconmit message is sent to the secondary host node for the second round of voting;
further, in step S4, when the primary node or the secondary node receives (S-f) of the precompimit messages sent by the replica node, it aggregates all the messages (but not S-f) and their signatures into precompimitqc, then sends a Commit message containing precompimitqc to the replica node, and the replica node submits the chunk into the chunk chain after receiving the Commit message.
In summary, due to the adoption of the technical scheme, the beneficial technical effects of the invention are as follows:
the consensus method and the system for improving the block chain throughput solve the problem that the throughput of the conventional consensus system is greatly reduced when a main node has an error after the first round of voting by setting a NewView stage, an S2 Premate stage, a PreCommit stage and a Commit stage, and improve the execution efficiency at the same time.
Drawings
FIG. 1 is a flow chart of the operation of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail with reference to the following embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
A common identification system for improving the throughput of a block chain is characterized in that the node types of the common identification system are divided into three types, namely a main node, an auxiliary main node and a replica node; leading consensus by one main node, and leading consensus by one auxiliary main node when the main node is in downtime or abnormal attack; the number of the main nodes and the auxiliary main nodes in the nodes is 1, and the rest are replica nodes; each view in the consensus system has a view number, and the view numbers are not repeated and are monotonically increased; the number of nodes S of the consensus system satisfies S3 f +2, wherein the number of nodes is S, and the allowed maximum fault-tolerant number is f.
A method for improving a consensus system of blockchain throughput, comprising the steps of:
s1 NewView stage: after the master node and the auxiliary master node receive the NewView messages sent by the S-f replica nodes, the messages and the signatures are simultaneously aggregated into aggQC, and the aggQC comprises the prepareQC with the largest view number stored by the replica nodes;
s2 preparation stage: judging whether the new block and aggQC received by the replica node are obtained by the broadcast of the main node, and then sending a PrepareVote message to perform a first round of voting;
s3 PreCommit stage: judging whether the main node is down or abnormally attacked, broadcasting PreCommit information containing prepareQC to the whole network, and performing a second round of voting;
s4 Commit stage: the block is submitted into a blockchain.
In the stage of NewView, after receiving NewView messages sent by (S-f) replica nodes, a primary node and a secondary node comprise prepareQC (quality certificate) with the largest view number stored by the replica nodes:
if the master node is not down or abnormally attacked at the moment, the master node selects a block of prepareQC with the largest view number from all received messages to generate a new block, and then the collected messages and signatures thereof are simultaneously aggregated into aggQC (aggregate quality certificate):
if the main node is not down or abnormally attacked at the moment, the main node broadcasts the new block and aggQC in the whole network in the Prepare stage, and the duplicate nodes receive and vote (sign), and meanwhile, the memory of the secondary main node is released and no operation is performed any more;
if the main node is down or abnormally attacked at the moment, the secondary main node broadcasts the new block and aggQC in the whole network in the Prepare stage, and the duplicate nodes accept and vote (sign).
If the main node is down or abnormally attacked at the moment, the secondary main node selects a block of prepareQC with the largest view number from all received messages to generate a new block, then aggregates the collected messages and signatures thereof into aggQC (aggregate Quorum certificate), broadcasts the new block and the aggQC in the whole network in the Prepare stage, and receives and votes (signs) by the replica node.
In the Prepare stage, if the new block and aggQC received by the replica node are obtained by broadcasting from the main node, the prepareVote message is sent to the main node for the first round of voting after voting (signature); otherwise, sending a PrepareVote message to the secondary main node for the first round of voting.
In the PreCommit stage, if the main node is not down or is not abnormally attacked, after the main node receives the PrepareVote messages sent by the (S-f) replica nodes, the main node aggregates all the received PrepareVote messages (but not the S-f) and the signatures thereof into a PrepareQC; otherwise, the secondary host nodes aggregate into prepareQC. The PreCommit message containing prepareQC is then broadcast to the full network.
If the replica node receives the PreCommit message broadcasted by the main node, the PreCommit Vote message is sent to the main node to perform a second round of voting;
if the replica node receives the PreCommit message broadcast by the secondary main node, the PreCommit Vote message is sent to the secondary main node for the second round of voting;
in the Commit stage, after receiving (S-f) PreCommitVote messages sent by the replica node, the primary node or the secondary node aggregates all messages (but not S-f) and their signatures into a PreCommitQC, and then sends a Commit message containing the PreCommitQC to the replica node, which submits the block to the block chain after receiving the Commit message.
The above description is not intended to limit the present invention, but rather, the present invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention.
Claims (10)
1. A consensus system for improving blockchain throughput, comprising: the node types of the consensus system are divided into three types, namely a main node, an auxiliary main node and a replica node; leading consensus by one main node, and leading consensus by one auxiliary main node when the main node is in downtime or abnormal attack;
the number of the main nodes and the auxiliary main nodes in the nodes is 1, and the rest are replica nodes;
each view in the consensus system has a view number, and the view numbers are not repeated and are monotonically increased;
the number of nodes S of the consensus system satisfies S3 f +2, wherein the number of nodes is S, and the allowed maximum fault-tolerant number is f.
2. A consensus method for improving blockchain throughput, comprising the steps of:
s1 NewView stage: after the master node and the auxiliary master node receive the NewView messages sent by the S-f replica nodes, the messages and the signatures are simultaneously aggregated into aggQC, and the aggQC comprises the prepareQC with the largest view number stored by the replica nodes;
s2 preparation stage: judging whether the new block and aggQC received by the replica node are obtained by the broadcast of the main node, and then sending a PrepareVote message to perform a first round of voting;
s3 PreCommit stage: judging whether the main node is down or abnormally attacked, broadcasting PreCommit information containing prepareQC to the whole network, and performing a second round of voting;
s4 Commit stage: the block is submitted into a blockchain.
3. The consensus method of claim 2, wherein: in step S1, the NewView message includes a prepareQC with the largest view number stored in the replica node.
4. The consensus method of claim 2, wherein: in step S1, when the master node is not down or abnormally attacked, the master node selects a block of prepareQC with the largest view number from all the received messages to generate a new block, and then aggregates the collected messages and their signatures into aggQC; when the main node is not down or is not abnormally attacked, the main node broadcasts the new block and aggQC in the whole network in the Prepare stage, the duplicate nodes receive and vote, and meanwhile, the memory of the secondary main node is released and no operation is performed any more; when the main node is down or abnormally attacked, the secondary main node broadcasts the new block and the aggQC in the whole network in the Prepare stage, and the replica node receives and votes.
5. The consensus method of claim 2, wherein: in step S1, when the master node goes down or is abnormally attacked, the secondary master node selects a block of the prepareQC with the largest view number from all the received messages to generate a new block, then aggregates the collected messages and their signatures into aggQC, broadcasts the new block and aggQC in the whole network in the Prepare stage, and the new block and aggQC are received and voted by the replica node.
6. The consensus method of claim 2, wherein: in step S2, when the new tile and aggQC received by the replica node are obtained by broadcasting from the master node, the master node sends a PrepareVote message to perform a first round of voting after the voting; otherwise, sending a PrepareVote message to the secondary main node for the first round of voting.
7. The consensus method of claim 2, wherein: in step S3, when the replica node receives the precompommit message broadcast by the master node, it sends the precompommit message to the master node to perform a second round of voting.
8. The consensus method of claim 2, wherein: in step S3, when the master node is not down or abnormally attacked and the master node receives the preparVote messages sent by the S-f replica nodes, the master node aggregates all the preparVote messages and their signatures into prepareQC; otherwise, the secondary main nodes are aggregated into prepareQC; the PreCommit message containing prepareQC is then broadcast to the full network.
9. The consensus method of claim 2, wherein: in step S3, when the replica node receives the precompmit message broadcast by the secondary host node, the precompmit message is sent to the secondary host node to perform a second round of voting.
10. The consensus method of claim 2, wherein: in step S4, after receiving S-f precompommitvoltage messages sent by the replica node, the primary or secondary primary node aggregates all the messages and their signatures into precompimitqc, then sends a Commit message containing precompimitqc to the replica node, and then the replica node submits the chunk into the chunk chain after receiving the Commit message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111208576.3A CN113949518A (en) | 2021-10-18 | 2021-10-18 | Consensus method and system for improving block chain throughput |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111208576.3A CN113949518A (en) | 2021-10-18 | 2021-10-18 | Consensus method and system for improving block chain throughput |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113949518A true CN113949518A (en) | 2022-01-18 |
Family
ID=79330920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111208576.3A Pending CN113949518A (en) | 2021-10-18 | 2021-10-18 | Consensus method and system for improving block chain throughput |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113949518A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110445778A (en) * | 2019-08-01 | 2019-11-12 | 中盾云链(广州)信息科技有限公司 | A kind of common recognition algorithm applied to alliance's chain |
| CN110633323A (en) * | 2019-09-16 | 2019-12-31 | 腾讯科技（深圳）有限公司 | Business data storage method, device, storage medium and computer equipment |
| CN111355810A (en) * | 2020-03-17 | 2020-06-30 | 重庆邮电大学 | Improved PBFT consensus method based on credit and voting mechanism |
| WO2020258831A1 (en) * | 2019-06-28 | 2020-12-30 | 创新先进技术有限公司 | Method and device for master node handover processing in blockchain system |
| CN112417046A (en) * | 2020-11-23 | 2021-02-26 | 宙通科技(南京)有限公司 | Parallelization Byzantine fault-tolerant method applied to block chain consensus mechanism |
| CN112532396A (en) * | 2020-12-04 | 2021-03-19 | 广东工业大学 | Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium |
-
2021
- 2021-10-18 CN CN202111208576.3A patent/CN113949518A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020258831A1 (en) * | 2019-06-28 | 2020-12-30 | 创新先进技术有限公司 | Method and device for master node handover processing in blockchain system |
| CN110445778A (en) * | 2019-08-01 | 2019-11-12 | 中盾云链(广州)信息科技有限公司 | A kind of common recognition algorithm applied to alliance's chain |
| CN110633323A (en) * | 2019-09-16 | 2019-12-31 | 腾讯科技（深圳）有限公司 | Business data storage method, device, storage medium and computer equipment |
| CN111355810A (en) * | 2020-03-17 | 2020-06-30 | 重庆邮电大学 | Improved PBFT consensus method based on credit and voting mechanism |
| CN112417046A (en) * | 2020-11-23 | 2021-02-26 | 宙通科技(南京)有限公司 | Parallelization Byzantine fault-tolerant method applied to block chain consensus mechanism |
| CN112532396A (en) * | 2020-12-04 | 2021-03-19 | 广东工业大学 | Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium |
Non-Patent Citations (3)
| Title |
|---|
| DAMILARE PETER OYINLOYE ET AL.: "Blockchain Consensus: An Overview of Alternative Protocols", SYMMETRY, vol. 13, no. 8 * |
| HOSSAM SAMY ET AL.: "Enhancing the performance of the blockchain consensus algorithm using multithreading technology", AIN SHAMS ENGINEERING JOURNAL, vol. 12, no. 3, XP086779209, DOI: 10.1016/j.asej.2021.01.019 * |
| KEBIRA AZBEG ET AL.: "An Overview of Blockchain Consensus Algorithms: Comparison, Challenges and Future Directions", ADVANCES ON SMART AND SOFT COMPUTING * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110784346B (en) | Reputation value-based PBFT consensus system and method | |
| CN110796547A (en) | Improved practical Byzantine fault-tolerant system based on alliance block chain | |
| CN111355810B (en) | Improved PBFT consensus method based on credit and voting mechanism | |
| CN108848056B (en) | Block chain consensus method based on verification | |
| CN110677485B (en) | Dynamic layered Byzantine fault-tolerant consensus method based on credit | |
| CN111106942A (en) | Block chain credit mechanism based on AP-PBFT algorithm | |
| CN114422513B (en) | Block chain consensus method based on Raft-PBFT | |
| CN112532396A (en) | Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium | |
| CN113141414B (en) | Grouped multi-chain asynchronous consensus method for block chain nodes in CNFS protocol | |
| CN115665170B (en) | Block chain consensus method based on reputation and node compression mechanism | |
| He et al. | An improvement of consensus fault tolerant algorithm applied to alliance chain | |
| CN113781218A (en) | Grouping PBFT consensus algorithm based on feature trust | |
| CN111935207A (en) | Block chain system consensus method based on improved C4.5 algorithm | |
| CN114218612A (en) | Consensus method suitable for high-frequency trading scene of alliance chain | |
| CN114050904B (en) | Consensus system and method based on two-level leader node fragmentation structure | |
| CN111555858B (en) | Practical Byzantine fault-tolerant consensus method based on block chain type storage | |
| CN113010903A (en) | Catering industry oil smoke online monitoring method and system based on block chain | |
| CN116633942A (en) | Bayesian-busy fault tolerance consensus method for high-speed response client | |
| CN113949518A (en) | Consensus method and system for improving block chain throughput | |
| CN114499874B (en) | Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet | |
| CN113992398A (en) | Improved PBFT consensus algorithm | |
| CN116232893A (en) | Consensus method and device of distributed system, electronic equipment and storage medium | |
| CN114205092B (en) | Optimistic Bayesian-preemption fault-tolerant consensus method without rollback | |
| CN113438092B (en) | Transaction broadcasting method and system | |
| CN115189871A (en) | Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature |
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 |