CN114820183B - Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm - Google Patents
Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm Download PDFInfo
- Publication number
- CN114820183B CN114820183B CN202111049565.5A CN202111049565A CN114820183B CN 114820183 B CN114820183 B CN 114820183B CN 202111049565 A CN202111049565 A CN 202111049565A CN 114820183 B CN114820183 B CN 114820183B
- Authority
- CN
- China
- Prior art keywords
- block group
- node
- height
- block
- nodes
- 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.)
- Active
Links
Images
Classifications
-
- 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
- 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/104—Peer-to-peer [P2P] networks
Abstract
The invention is suitable for the technical improvement field of block chains, and provides a method and a system for eliminating the bifurcation problem in a parallel voting certification consensus algorithm, wherein the method comprises the following steps: s1, judging whether a network generates a subarea or not before submitting a block group by a wheel value accounting node which is proved to be identified by parallel voting; s2, judging whether the height a of the last state block group of the node is higher than the height of the other legal block group after the network is recovered; s3, the minority nodes request block group information with the height of a from the majority nodes, check the block group information, rewrite the block group with the height of a, and enable the network to recover to be normal. The method improves the bifurcation problem of the PPoV consensus algorithm caused by network partition by delaying block dropping and timing the height of the synchronization block group, and improves the usability of the PPoV consensus algorithm. In an actual application scene, the improvement can well avoid the problems of transaction data confusion and the like caused by chain bifurcation.
Description
Technical Field
The invention belongs to the field of block chain technology improvement, and particularly relates to a method and a system for eliminating a bifurcation problem in a parallel voting certificate consensus algorithm.
Background
In recent years, with the acceleration of industrial informatization, digitization and networking and the popularization of intelligent terminals, the internet has become one of the driving forces for the development of human society and is closely linked with the life of people. In 2018, the total amount of Chinese internet users reaches 8 hundred million, the number of internet users worldwide exceeds 40 hundred million, and the data volume generated on the internet per day exceeds 5 terabytes. The anonymity and the low threshold of the Internet facilitate the life of people and provide a hotbed for breeding malicious programs such as Trojan horses, viruses and the like. In order to resist various emerging attacking means, more and more new technologies are continuously emerging.
The development of the blockchain technology can be traced to the white paper "bitcoin" published by the chinese smart in 2008 for the earliest time: a peer-to-peer electronic cash system is favored because of its completely decentralized and account book tamper-resistant nature. The block chain is a distributed storage technology with tamper-proof fault-tolerant capability, and the safety of data is ensured through technologies such as chain structures, hash algorithms, asymmetric encryption and the like. As with the conventional distributed storage technology, the blockchain also needs to coordinate the operations of the nodes through a consensus algorithm to ensure the consistency of the data stored by the nodes. The bitcoin, which is the most widely used block chain system, has many advantages such as data tamper resistance.
With the development of policy and industry, the application of block chains in many fields, such as financial trade, public service industry, tourism industry, intelligent education, catering industry, logistics industry, medical construction and other fields, is increasing.
The block chain structure can be roughly divided into 6 levels, namely a data layer, a network layer, a consensus layer, a motivation layer, a contract layer and an application layer.
The data layer is the bottom layer and mainly comprises functions of data storage and transaction record, and the layer has the most basic logic structures such as a chain structure and a hash function;
the network layer is used for realizing the mutual communication among the nodes and has the functions of data transmission and verification;
the consensus layer is a core part of the block chain, encapsulates various consensus algorithms and is mainly used for realizing consensus of block, block header generation and transaction data. The consensus algorithm is selected from multiple aspects, so that the safety of block chain data and the convenience and quickness in the transaction process are facilitated, and various unintentional or malicious consensus attacks are prevented;
the incentive layer is mainly responsible for introducing an incentive mechanism of the mining nodes, for example, the digital token allocation is carried out on miners who mine new blocks, and the mining work of the miners is encouraged;
the contract layer mainly comprises a written intelligent contract and various scripts, so that the block chain obtains programmable application attributes;
the application layer is a specific application of the block chain in a real industry scene, and is mainly embodied in various programmable currencies.
The first three layers are indispensable in the block chain architecture, and the last three layers can be flexibly adjusted according to the requirements of the actual scene.
According to different application scenarios and the openness of a network running by a participating node, the blockchain can be divided into a public chain, a private chain and a alliance chain. The public chain is open to the whole network, any user node in the network can freely join or leave the block chain system, and the authority of everyone is equal; in a private chain, an organization or a node completely controls the generation authority of a block or a block group, which is similar to a centralized system; the alliance chain is between the public chain and the private chain, and is managed by a plurality of members, different authorities and identities are granted to different nodes, and a block chain system is maintained together.
However, the consensus algorithm adopted by the bitcoin has the defects of energy waste and low efficiency, so that the consensus algorithm is difficult to cope with other application scenarios with high throughput. Aiming at the defect of low throughput, people optimize the consensus algorithm of the bitcoin or design a new consensus algorithm as the consensus algorithm of the block chain.
The voting certification (PoV, proof of volume) consensus algorithm designs a specific role model, and classifies nodes in the blockchain network into four roles, namely committee (commission), butler (Butler), candidate Butler (Candidate) and common User (edit User). Committees are authorities in blockchain networks that collectively manage the entire blockchain, and all transactions need to be executed with most of the committees' consent.
The candidate housekeeping can be converted after being applied for joining by a common user. The steward is selected from the candidate stewards, and when the common user becomes the candidate steward, the steward is qualified to be selected as the steward. The election process is carried out by committees, each committee needs to vote for each candidate housekeeper in the voting stage, and the Nb nodes with large votes become housekeeper nodes. The housekeeping node is mainly responsible for collecting transactions and generating blocks, and each round of block generation is performed by a housekeeper, called a duty housekeeper, randomly assigned by the block generated in the previous round. The PoV consensus algorithm also specifies that the candidate caretaker needs to be voted again after every M normal blocks are generated, so as to generate the next caretaker, and the voting information and the result thereof are stored in the M +1 th block. After the block is generated, the next block packaging cycle is started, meanwhile, the manager in the previous cycle is changed into a candidate manager, the right for generating the block is lost, and instead, the candidate manager appointed by the special block is changed into a manager to be responsible for a new round of block packaging.
The algorithm generates a new block by consensus, and has two kinds of nodes participating together, namely a manager node needing to generate the new block and all committee nodes in charge of auditing votes, at the moment, the name of the manager generating the block is a Duty manager (Duty Butler), and the Duty manager is determined by the manager numbers selected by the committee. Suppose there are n committees participating in the block generation process, each C 1 ,C 2 ,…,C n The total number of manager nodes serving as the round of consensus process is m, and the manager nodes are respectively B 1 ,B 2 ,…,B m The overall consensus process of the PoV algorithm, as shown in fig. 1, illustrates the overall process of generating a commit for a block. The PoV contains a total of four processes, namely preparation (Prepare), preparation (Ready), commit (Commit) and Confirm (Confirm), wherein the Confirm process is a Commit process after the block is generated, so that no information is transmitted.
Each block is composed of a block header and a plurality of transactions associated with the consensus. In the preparation process, the attendant node responsible for calculating the generation block of the round takes out and combines a plurality of transaction transactions in the transaction reserve pool in the round of consensus process to generate a pre-block, and then the attendant node transmits the generated pre-block to all committee nodes. The method of distinguishing between pre-blocks and complete real blocks consists in observing whether the block has a timestamp, the authentication information of all committees and the serial number of the attendant responsible for the generation of the next block.
The committee node needs to check the received block header of the pre-block and a plurality of transaction information, if the check is successful, signature authentication is carried out on the pre-block header, and the authentication is transmitted to the manager on duty. The manager on duty can complement the pre-block completely and finally become a formal block after receiving the committee certification which is larger than n/2.
All the nodes which receive the newly-released block generated at this time store the block in a local block chain of the node, and update some corresponding information and data, such as the number of the next attendant, so as to confirm the attendant who generates the next new block. The integrity of the pre-block header is supplemented by the voting signatures of all committees, the PoV defines the committee authentication time at which the vote is the latest as the real generation time of the block, and the next attendant housekeeping number is generated by performing a calculation such as a hash operation on the voting signatures. These methods utilize the unpredictability and tamper resistance of the votes, and since the votes generated by each committee are all unordered and random, the serial number of the next attendant node obtained by hash operation is also random.
The PoV only allows one steward to generate blocks in each consensus period, only one block is generated in each consensus, and the other stewards are idle, so the block generation process is serialized. However, since the communication complexity of PoV is O (3 Nc), nc is the number of committee, and the attendant needs to send the generated blocks to all committee request signatures, the data throughput of PoV will decrease linearly as the number of committee nodes increases, which adversely affects the scalability of PoV.
In addition, since the next attendant number in the PoV is calculated by using the committee signatures in the block, and the attendant can change the next attendant number by arbitrarily arranging and combining the signatures when collecting the signatures and storing the signatures in the block header, there is a possibility of self-privy mining.
The Parallel voting certification (PPoV, parallel Proof of volume) is a consensus mechanism of the Parallel voting certification, is a consensus algorithm improved on the basis of PoV, inherits the mechanisms of the PoV in the aspects of communication complexity, safety, monitorability, fairness and the like, solves the defect of poor expandability of the PoV by the design of Parallel generation blocks, and obtains high transaction throughput and good expandability by the algorithm. The PPoV consensus defines that data on a block chain is stored in the form of block groups. The block group consists of a block group head and a block group body. Each block group header contains the height of the current block group and the voting result. The block group contains all the blocks that pass the voting. Each block comprises information such as a hash value, a mercker root, a public key of a generator, a timestamp and the like of a previous block group and a transaction set. The algorithm continues the idea of separating the voting right and the accounting right of the node, and totally designs five kinds of identity nodes including a verification node, an accounting node, a candidate accounting node, a round value accounting node and a common node. The verification nodes have voting right, vote on the block data in consensus, the voting weights of all the verification nodes are equal, and only blocks which obtain more than 50% of votes can be legal blocks. The accounting node is a bearer of the block chain accounting function, and is responsible for collecting transaction data generated by the network node, packaging the transaction into blocks, broadcast blocks, commit block groups and the like. The candidate accounting nodes do not have the ability to directly participate in the consensus process, but qualify for election by the verifying node as an accounting node. At any time of system operation, a unique round value accounting node is in charge of collecting and counting voting information generated by the verification node, the node is selected from the accounting nodes, and the voting mode is the same as the common consensus of the PoV. The common node cannot join the consensus process, but can receive the blockchain data sent by other nodes and can also issue a transaction.
PPoV refers to all operations that need to be performed to generate a block set as a round of consensus, and generally requires that the time to complete a round of consensus not exceed a maximum value, which is referred to as a timeout. The consensus process is completed by the accounting node and the verification node together. After a round of consensus begins, each accounting node generates a block and broadcasts the block to the network, and all nodes in the network need to collect the blocks. And after collecting all the blocks generated by the accounting node, the verifying node verifies the blocks and sends votes to the round value accounting node, wherein the votes comprise the signature of the verifying node, the hash value of each block and the verification result. The round value accounting node is responsible for collecting and counting votes, the block which obtains more than half of the verification passing tickets can be a legal block and can be stored in a finally generated block group, and the block which obtains more than half of the verification failing tickets is an illegal block. The round-robin accounting node needs to store the voting list and the voting result in the block group header, and finally broadcast the block group header to the network. The node that receives the block header and all valid blocks assembles them into a complete block group and stores it in the local block chain.
Because PPoV has more than one accounting node to process transactions in parallel, the design effectively prevents the possible downtime problem of the system, but introduces the bifurcation of the block chain. Network partitioning occurs if the round-robin accounting node is at the synchronization block header and it is in the minority dispatch network. The other node will generate a round robin accounting node and generate the same height block group, and when the network recovers, the two same height and valid block groups will cause the block chain to branch.
Disclosure of Invention
The invention aims to provide a method and a system for eliminating the bifurcation problem in a parallel voting certification consensus algorithm, which aim to solve the bifurcation problem in a PPoV algorithm and adopt the technical problems of synchronizing self height, delaying block falling and the like.
The invention is realized in such a way that a method for eliminating the bifurcation problem in the parallel vote proof consensus algorithm comprises the following steps:
s1, judging whether a network generates partitions or not before submitting block groups by a round value accounting node for parallel voting certification consensus, if so, continuing to execute a consensus algorithm in each partition to generate different block groups and executing the next step, and if not, submitting the previous block group and executing a transaction after the next block group falls;
s2, judging whether the height a of the last state block group of the node is higher than that of the other legal block group after the network is recovered, if not, the node realizes that the block group with the height a of the node needs to be rewritten according to the longest chain principle, and if so, combining the other block group into the block group with the height a;
s3, the minority nodes request block group information with the height of a from the majority nodes, check the block group information, rewrite the block group with the height of a, and enable the network to recover to be normal.
The invention further adopts the technical scheme that: in the step S3, after network communication is resumed, the round-valued accounting node that has a large number of votes for the verification node needs to be selected according to the number of nodes newly added to the block group, and the next block group continues to be generated.
The further technical scheme of the invention is as follows: at nodes in the minority and majority of networks, the block groups are legal, although the header information is different.
The further technical scheme of the invention is as follows: in step S2, a request is made from the current height when the node synchronization block group height is high, and if the block group of a certain node is found to be different from the block group of the current height of the node and the height of the block group of the node is greater than that of the node, the block group of the current height needs to be rewritten.
Another object of the present invention is to provide a system for eliminating a fork problem in a parallel vote proof consensus algorithm, wherein the system for eliminating a fork problem in a parallel vote proof consensus algorithm comprises:
the partition judging module is used for judging whether the network generates partitions before submitting the block groups by the wheel value bookkeeping nodes for parallel voting certification consensus, if so, the consensus algorithm is continuously executed in each partition to generate different block groups and execute the next step, and if not, the previous block group is submitted and the transaction is executed after the next block group is subjected to block drop;
the block height judging module is used for judging whether the height a of the last state block group of the node is higher than the height of another legal block group after the network is recovered, if not, the node realizes that the block group with the height a of the node needs to be rewritten according to the longest chain principle, and if so, the other block group is combined into the block group with the height a;
and the rewriting recovery module is used for requesting block group information with the height of a from the majority of the dispatching nodes by the minority of the dispatching nodes, checking the block group information to pass, rewriting the block group with the height of a, and recovering the network to be normal.
The further technical scheme of the invention is as follows: and after network communication is recovered, selecting a round value accounting node which has more votes for the verification node according to the number value of the newly added nodes in the block group in the rewriting recovery module to continue to generate the next block group.
The further technical scheme of the invention is as follows: at nodes in the minority and majority of dispatch networks, the block groups are legal, although the header information is different.
The invention further adopts the technical scheme that: the block height judging module requests from the current height when the node synchronization block group height is high, and if the block group of a certain node is different from the block group with the current height of the node and the block group height of the node is larger than the node height, the block group with the current height needs to be rewritten.
The beneficial effects of the invention are: the method improves the bifurcation problem of the PPoV consensus algorithm caused by network partition by delaying block dropping and timing the height of the synchronization block group, and improves the usability of the PPoV consensus algorithm. In an actual application scene, the improvement can well avoid the problems of transaction data confusion and the like caused by chain bifurcation.
Drawings
Figure 1 is a schematic diagram of a housekeeper node and a committee node.
Fig. 2 is a schematic diagram of various nodes in a network.
Fig. 3 is a first diagram illustrating block group heights and node partitioning according to an embodiment of the present invention.
Fig. 4 is a diagram illustrating a block group height and a node partitioning according to an embodiment of the present invention.
Fig. 5 is a third schematic diagram after the block group height and the node partitioning according to the embodiment of the present invention.
Fig. 6 is a flowchart of a method for eliminating a bifurcation problem in a parallel vote proof consensus algorithm according to an embodiment of the present invention.
Detailed Description
As shown in fig. 6, in the present solution, in order to solve the problem of forking in the PPoV algorithm, the technical problems of synchronizing the self height, delaying the block dropping, and the like are adopted.
When the transaction processing and the packaging of the PPoV algorithm are carried out, the PPoV algorithm is responsible for round value accounting nodes voted by the verification nodes, only one round value accounting node is provided in each period of time, and the polling rotated by the round value accounting nodes also needs to be processed by the current round value accounting node, so that a problem is easily caused, namely if the round value accounting node goes down, the process of calculating the sequence number of the next round value accounting node cannot be carried out any more, and the PPoV system goes into paralysis as shown in FIG. 2. In addition, when the following two partitions occur in the network, the downtime problem also exists: (1) most of the verification nodes and the round-robin accounting nodes are isolated in one partition, and a few other nodes are isolated in another partition.
(2) A few verification nodes and round billing nodes are isolated in one partition and most other nodes are isolated in another partition.
In the first case, during the operation of the PPoV algorithm, the part of the network with only a few verification nodes will be stuck due to the lack of work of the round-robin accounting node, while the other part of the network will be stuck due to the need to calculate the next round-robin accounting node in the algorithm, but the round-robin accounting node is not in the partition, and the subsequent consensus process will also be stuck.
In the second case, a minority of verification nodes and the round value accounting node are isolated in the same partition, and at the moment, the round value accounting node wants to generate a partition group, but cannot receive the vote of the majority of verification nodes all the time through continuous communication and waiting, and the generation of a new partition group cannot be mentioned; although the other partition has a plurality of verification nodes, the verification nodes cannot obtain the request of transaction verification any more because the PPoV consensus algorithm has no re-election mechanism, and at this time, any partition cannot operate normally. Therefore, a timeout reselection mechanism is introduced in the scheme to solve the problem of downtime in the PPoV.
In addition, the election of the round-robin accounting node in the PPoV algorithm is specified by voting to generate a random number by the verification node. The original random number generation algorithm counts the latest voting of the verification nodes, and does not fully consider the preorder voting of other verification nodes. Therefore, the scheme improves the generation algorithm of the random number.
Suppose now that the entire consensus network has seven nodes { P1, P2, P3, P4, P5, P6, P7}, when the P1 node is a round-robin accounting node, and when the network is in a synchronization phase for submitting a block group. Assuming that the P1 node has synchronized the highly a blockgroup information to the { P1, P2, P3} node, the { P1, P2, P3} node recognizes the highly a blockgroup header and submits it.
But at this time, a problem occurs in the network, and two network partitions of { P1, P2, P3} and { P4, P5, P6, P7} appear. At this time, it can be found that the height of the { P1, P2, P3} node is a, but the height of the { P4, P5, P6, P7} node is a-1, then for the first three nodes, they can enter the consensus generation process of the block group with the height of a +1, at this time, if the round accounting node is changed to the P2 node in a certain round, P2 will wait for the voting of the majority verifying node, obviously, he cannot receive the voting of the majority assigning node because the majority assigning node is located in another network partition. Therefore, after P2 waits for a timeout period, the round-robin accounting node is replaced by P3, and P3 repeats the running logic of P2, and naturally cannot obtain the approval of most verification nodes, so that the nodes in the { P1, P2, P3} set are always in the round-robin rotation of the round-robin accounting nodes, but cannot generate a new block group all the time, as shown in fig. 3.
At this time, for nodes of the { P4, P5, P6, P7} network partition, because the network partition exists, they cannot receive the information of the block group with the height of a, and then after waiting for a timeout period, they will generate the replacement of the round-robin accounting node and regenerate the block group. But the next round value accounting node P2 node is also overtime because the next round value accounting node is also unable to communicate, and then the next round value accounting node P4 node is waited as the round value accounting node. The P4 node will re-generate the block group with height a. However, this block group is different from the block group with height a generated by P1 (the generator is different, because the node of another partition cannot participate in the generation of the block group), and in this case, the block group with height a generated by P1 is considered as a, and the block group with height a generated by P4 is considered as a1. At the same time, because the nodes are in the majority pie, they can also continue to generate new groups of blocks of height a1+1, a1+2, a1+3, as shown in FIG. 4.
At this time, it can be seen that if the algorithm continues to run, the fork that has occurred in the network cannot be repaired, and then the existing algorithm cannot handle and recover from the situation. Assuming the network is back up to normal, the nodes { P1, P2, P3} will find that the nodes { P4, P5, P6, P7} are taller than themselves, and they will go to the nodes { P4, P5, P6, P7} to request the block group a +1 after a. However, in fact, the current next block group of other nodes is a1+1, and when { P1, P2, P3} requests the block group, it will find that its block group header information does not match a, so that the block cannot be successfully merged into a.
At this time, the algorithm principle has actually been problematic, and both { P1, P2, P3} and { P4, P5, P6, P7} consider the block group information with its own height a to be valid. And from an algorithmic point of view, these two block groups of height a are indeed both valid, since they are generated by the round accounting node. In this case, unrecoverable forking of the network occurs.
It can be seen that this problem arises because network partitioning occurs when the round value accounting node is in the synchronization block group phase, and it is in the minority dispatch network. The other node creates a round-robin accounting node and creates groups of blocks of the same height, and when the network recovers, two blocks of the same height and both valid create partitions for the network.
Theoretically, the consensus mechanism herein is inevitable if the situation of network partitioning is encountered after improvement, mainly how to recover from the bifurcation state to the normal state.
Firstly, when the network is recovered to be normal, the final state of the node is that the height of the current block group of { P1, P2, P3} is a, and the legal block group of { P4, P5, P6, P7} is found to be higher than itself, and at the same time, the node can find that the nodes are legal except that the head information is different from itself.
At this time { P1, P2, P3} can be considered as a minority group of blocks and network partition recovery occurs, then they realize that the block group with height a needs to be rewritten according to the longest chain rule. Thus { P1, P2, P3} needs to request the information of the block group with height a from { P4, P5, P6, P7} and check that the network can be recovered to normal by rewriting the block group with height a.
But now another problem arises in that if P1, P2, P3 already submits the group of blocks with height a and modifies the state database, it needs to modify the state database again when receiving the group of blocks of a1. At this time, there are two ways of submitting, one is direct modification, so that the data of { P1, P2, P3} and { P4, P5, P6, P7} are not synchronized because of the influence of the transaction already executed in the a block group; the other is to restore the state database to the state of the block group before the block group a is generated, and to re-perform the transaction packaged in a1 on P1, P2, and P3, which may cause disorder of the user side although the final state is the same.
So, for the sake of enhancing its availability, the performance may be slightly sacrificed, that is, when a block group is received, the node does not submit the block group first, because it cannot determine whether the block group is overwritten later. According to the principle of longest chain, the current block group is submitted after the next block group generates an approval message, as shown in fig. 5.
Two major modifications to the original PPoV consensus scheme can be made in specific implementation. First, the node needs to delay the block group to be submitted, and needs to wait for the next block group to be submitted. And secondly, requesting from the current height when the node synchronization block group height is high, and if the block group of a certain node is different from the block group of the current height of the node and the block group height of the node is higher than the node, rewriting the block group of the current height is needed. After network communication is resumed, the accounting node with more votes of the verification node is selected as a round-robin accounting node according to the number value of the nodes newly added in the block, and the next block group is generated continuously.
The scheme provides a mode of delaying block falling and timing the height of the synchronous block group to improve the bifurcation problem of the PoV consensus algorithm caused by network partition, and improve the usability of the PPoV consensus algorithm. In an actual application scene, the improvement can well avoid the problems of transaction data confusion and the like caused by chain bifurcation.
The invention aims at improving the problem that under the scenes that the network environment is unstable and the network is easy to diverge, the PPoV consensus algorithm can generate block groups with the same height and different contents due to the parallel work of the accounting nodes with different round values. The method firstly analyzes the reason of the phenomenon, then proposes a method for adopting delay block dropping, regularly synchronizing the heights of other node block groups and rewriting the current height block group, and well solves the problem of chain branching existing in the PPoV consensus algorithm.
The above description is intended to be illustrative of the preferred embodiment of the present invention and should not be taken as limiting the invention, but rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.
Claims (8)
1. A method for eliminating the bifurcation problem in the parallel vote proof consensus algorithm is characterized by comprising the following steps of:
s1, judging whether a network generates partitions or not before submitting block groups by a round value accounting node for parallel voting certification consensus, if so, continuing to execute a consensus algorithm in each partition to generate different block groups and executing the next step, and if not, submitting the previous block group and executing a transaction after the next block group falls;
s2, judging whether the height a of the last state block group of the node is higher than the height of the other legal block group after the network is recovered, if not, the node realizes that the block group with the height a of the node needs to be rewritten according to the longest chain rule, and if so, combining the other block group into the block group with the height a;
s3, the minority nodes request block group information with the height of a from the majority nodes, check the block group information, rewrite the block group with the height of a, and enable the network to recover to be normal.
2. The method for eliminating bifurcation in the parallel vote proof consensus algorithm according to claim 1, wherein a round accounting node with more votes from the verifying node is selected according to the number of newly added nodes in the block group to continue to generate the next block group in step S3 after network communication is resumed.
3. The method of claim 2, wherein the block groups are legal even though the header information is different at nodes in the minority and majority distribution networks.
4. The method as claimed in claim 3, wherein the step S2 requests the node from the current height when the node synchronization block group height is higher, and if the block group of a node is found to be different from the block group of the current height of the node and the block group height of the node is higher than the node, the block group of the current height needs to be rewritten.
5. The system for eliminating the fork problem in the parallel vote proof consensus algorithm is characterized by comprising the following steps
The partition judging module is used for judging whether the network generates partitions before submitting the block groups by the wheel value bookkeeping nodes for parallel voting certification consensus, if so, the consensus algorithm is continuously executed in each partition to generate different block groups and execute the next step, and if not, the previous block group is submitted and the transaction is executed after the next block group is subjected to block drop;
the block height judging module is used for judging whether the height a of the last state block group of the node is higher than that of another legal block group after the network is recovered, if not, the node realizes that the block group with the height a of the node needs to be rewritten according to the longest chain principle, and if so, the other block group is combined into the block group with the height a;
and the rewriting recovery module is used for requesting block group information with the height of a from the majority of the dispatching nodes by the minority of the dispatching nodes, checking the block group information to pass, rewriting the block group with the height of a, and recovering the network to be normal.
6. The system for eliminating the fork problem in the parallel vote proof consensus algorithm as claimed in claim 5, wherein the rewrite recovery module selects the round accounting node with more votes for the verification node to continue generating the next block group according to the number of newly added nodes in the block group after network communication is recovered.
7. The system of claim 5, wherein at nodes in the minority and majority distribution networks, the block groups are legal despite different header information.
8. The system of claim 5, wherein the block height determining module requests the node from the current height when the node synchronization block height is reached, and if the block group of a node is found to be different from the block group of the current height of the node and the block group height of the node is greater than the node, the block group of the current height needs to be rewritten.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111049565.5A CN114820183B (en) | 2021-09-08 | 2021-09-08 | Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111049565.5A CN114820183B (en) | 2021-09-08 | 2021-09-08 | Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114820183A CN114820183A (en) | 2022-07-29 |
| CN114820183B true CN114820183B (en) | 2023-01-31 |
Family
ID=82526481
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111049565.5A Active CN114820183B (en) | 2021-09-08 | 2021-09-08 | Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114820183B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107507006A (en) * | 2017-08-11 | 2017-12-22 | 杭州秘猿科技有限公司 | A kind of common recognition bifurcated processing method based on license chain |
| US9875510B1 (en) * | 2015-02-03 | 2018-01-23 | Lance Kasper | Consensus system for tracking peer-to-peer digital records |
| CN111679936A (en) * | 2020-05-26 | 2020-09-18 | 中国工商银行股份有限公司 | Block chain network bifurcation automatic recovery method, device and system |
| CN112104482A (en) * | 2020-08-11 | 2020-12-18 | 佛山赛思禅科技有限公司 | Consensus method based on parallel voting |
| CN112487496A (en) * | 2020-12-07 | 2021-03-12 | 合肥达朴汇联科技有限公司 | Block chain consensus system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10523421B2 (en) * | 2016-11-30 | 2019-12-31 | International Business Machines Corporation | Checkpoints for permissionless blockchains |
| US20200059369A1 (en) * | 2017-05-16 | 2020-02-20 | Peking University Shenzhen Graduate School | Determining consensus by parallel proof of voting in consortium blockchain |
| US11875400B2 (en) * | 2019-01-31 | 2024-01-16 | Salesforce, Inc. | Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (DLT) |
-
2021
- 2021-09-08 CN CN202111049565.5A patent/CN114820183B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9875510B1 (en) * | 2015-02-03 | 2018-01-23 | Lance Kasper | Consensus system for tracking peer-to-peer digital records |
| CN107507006A (en) * | 2017-08-11 | 2017-12-22 | 杭州秘猿科技有限公司 | A kind of common recognition bifurcated processing method based on license chain |
| CN111679936A (en) * | 2020-05-26 | 2020-09-18 | 中国工商银行股份有限公司 | Block chain network bifurcation automatic recovery method, device and system |
| CN112104482A (en) * | 2020-08-11 | 2020-12-18 | 佛山赛思禅科技有限公司 | Consensus method based on parallel voting |
| CN112487496A (en) * | 2020-12-07 | 2021-03-12 | 合肥达朴汇联科技有限公司 | Block chain consensus system |
Non-Patent Citations (2)
| Title |
|---|
| 区块链分叉问题的分析研究;侯佳忆等;《科技视界》;20200325(第09期);第168-170页 * |
| 预防区块链分叉的节点检测算法研究;魏彬等;《内江师范学院学报》;20200220(第02期);第41-47页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114820183A (en) | 2022-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Wang et al. | Sok: Sharding on blockchain | |
| Abraham et al. | The blockchain consensus layer and BFT | |
| CN111131209B (en) | Improved efficient consensus method, system, computer device and storage medium | |
| Xu et al. | A survey of blockchain consensus protocols | |
| CN110289966B (en) | Byzantine fault tolerance-based anti-adaptive attack union chain consensus method | |
| Sonnino et al. | Replay attacks and defenses against cross-shard consensus in sharded distributed ledgers | |
| Aiyer et al. | BAR fault tolerance for cooperative services | |
| Liu et al. | Building blocks of sharding blockchain systems: Concepts, approaches, and open problems | |
| CN112104482B (en) | Consensus method based on parallel voting | |
| US20210256016A1 (en) | Blockchain system and method | |
| Li et al. | PoV: An efficient voting-based consensus algorithm for consortium blockchains | |
| CN113553375B (en) | Partitioned storage device and method for image type block chain | |
| Sohrabi et al. | ZyConChain: A scalable blockchain for general applications | |
| US20230017790A1 (en) | Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof | |
| CN114049123A (en) | Block chain consensus method and device, computer equipment and storage medium | |
| Tsai et al. | Lessons learned from developing permissioned blockchains | |
| CN115797070A (en) | Block chain transaction method, device and system based on broker account incentive | |
| Xi et al. | A comprehensive survey on sharding in blockchains | |
| CN113448694B (en) | Block chain consensus method for improving transaction processing capability | |
| Yao et al. | Sok: A taxonomy for critical analysis of consensus mechanisms in consortium blockchain | |
| CN114820183B (en) | Method and system for eliminating bifurcation problem in parallel voting certification consensus algorithm | |
| CN111970370A (en) | Communication equipment system-oriented multilayer block chain protocol expansion system and method | |
| Liu et al. | A secure and practical blockchain scheme for IoT | |
| KR20210127231A (en) | Energized Identity based blockchain | |
| Wu et al. | Multimaster Node Byzantine Fault-Tolerant Consensus Algorithm Based on Consistent Hash Algorithm |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |