CN116668199B - Block chain disfigurement checking method based on Bayesian tolerance - Google Patents
Block chain disfigurement checking method based on Bayesian tolerance Download PDFInfo
- Publication number
- CN116668199B CN116668199B CN202310947912.9A CN202310947912A CN116668199B CN 116668199 B CN116668199 B CN 116668199B CN 202310947912 A CN202310947912 A CN 202310947912A CN 116668199 B CN116668199 B CN 116668199B
- Authority
- CN
- China
- Prior art keywords
- block
- height
- signature
- vote
- node
- 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
- 238000000034 method Methods 0.000 title claims abstract description 38
- 206010061619 Deformity Diseases 0.000 title claims description 14
- 238000012790 confirmation Methods 0.000 claims abstract description 34
- 206010063659 Aversion Diseases 0.000 claims abstract description 26
- 238000004806 packaging method and process Methods 0.000 claims abstract description 16
- 238000012552 review Methods 0.000 claims abstract description 13
- 238000012856 packing Methods 0.000 claims description 31
- 230000006399 behavior Effects 0.000 claims description 11
- 238000007689 inspection Methods 0.000 claims description 8
- 238000010200 validation analysis Methods 0.000 claims description 7
- 238000011156 evaluation Methods 0.000 claims description 3
- 238000005096 rolling process Methods 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000008094 contradictory effect Effects 0.000 description 2
- 238000013461 design Methods 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
- 238000012360 testing method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
-
- 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/40—Network security protocols
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Abstract
The invention provides a block chain aversion examination method based on Byzantine tolerance, which carries out voting review work and comprises the following steps: SA1 witness nodes forward their last confirmed heights to other witness nodes according to voting forwarding constraintSA2, all witness nodes review the signature sets forwarded by other witness nodes and judge whether the signature sets are wrongly acted or not; SA3, if the wrongly acting is found, checking the signature set by the witness node and finding out a wrongly person; SA4 packaging the wrongdoer, evidence and punishment result into a wrongdoer check block with a packaging height of the final confirmation height+wait height λ, the sanity check block competes with the normal block in unison, and if the sanity check block is confirmed, the split block is rolled back. The invention can efficiently identify the bad nodes in the consensus network and shorten the block confirmation time.
Description
Technical Field
The invention relates to a Byzantine tolerant blockchain witness consensus mechanism, in particular to a checking method aiming at bad nodes.
Background
The traditional Raft consistency consensus algorithm can only tolerate fault nodes and cannot avoid the damage caused by wrongly operating nodes, so that the traditional Raft algorithm can be seriously influenced when wrongly operating nodes appearPerformance, even under the disturbance of a rogue node, seriously jeopardizes the security of the system. The traditional BFT consensus can further tolerate node disfigurement problem, but the consensus network has multiple rounds of communication, and the communication complexity reachesО(n 2 ) Is not suitable for large-scale application scenes. How to find out and complete the treatment of the offensive behavior in a few rounds and finally decide the consensus is a problem in the field.
Patent application number 2022100519427, namely a block chain witness consensus method, system, equipment and storage medium based on Bayesian fault tolerance, discloses a block chain witness consensus method based on Bayesian fault tolerance, which is provided with packing nodes and witness nodes, and comprises the following steps: s1, packing nodes to generate blocks, and broadcasting; s2, the witness node performs voting broadcasting and counting; s3, confirming a main chain according to rules; in step S2, all witness nodes are at any block height, and only one round of voting broadcasting is carried out; and step S3, no matter whether the main chain is confirmed or not, the packing node only collects votes of more than 2/3 nodes, namely, the step S1 is returned to carry out the packing of the next round of blocks, and when the packing node carries out the packing of the next round of blocks, one block which is collected to the most votes is selected as a father block. The rule of the main chain confirmation is that if one node collects votes of more than 2/3 nodes of a certain block in one block height, the block is confirmed, and the chain where the block is located is confirmed as the main chain. When the consensus participation node collects votes of a witness node for a plurality of blocks under the same height, the witness node is marked as bad.
The foregoing is provided merely for the purpose of facilitating understanding of the technical solutions of the present invention and is not intended to represent an admission that the foregoing is prior art.
Disclosure of Invention
The invention aims to solve the problems and provide a blockchain dislike checking method based on Byzantine tolerance.
In order to achieve the above object, the technical scheme of the present invention is as follows:
a blockchain aversion inspection method based on Byzantine tolerance comprises the following steps: s1, packaging a block; s2, the witness node performs signature voting on the block, and the signature voting is counted; s3, judging whether the main chain confirms or not, and carrying out next round of packaging after conforming to the packaging rule;
the disqualifying inspection method also performs voting review work, including:
SA1 witness nodes forward their last confirmed heights to other witness nodes according to voting forwarding constraintIs a signature set to be reviewed;
SA2, all witness nodes review the signature set forwarded by other witness nodes and judge whether the signature set is wrongly acted or not;
SA3 if the disqualifying behavior is found, the witness node will send its own last confirmation altitudeIs sent to other witness nodes while requiring them to send +.>Other bifurcated signature sets which collide with the confirmation block are checked, and a wrongdoer is found;
SA4 packaging the perpetrator, evidence and penalty result into a perpetrator check block, uniformly competing the perpetrator check block and the common block, and rolling back the classified block if the perpetrator check block is confirmed.
In step SA1, the voting-forwarding constraint is: the transmitting node transmits the last acknowledgement altitude to the receiving nodeIf +.>The sending node receives the vote of the receiving node at the height, then at the height + ->Lower random selectionSelecting a vote which is different from the receiving node and is bifurcated, and sending the vote to the receiving node; if no votes have been received from the receiving node, at a height +.>And randomly selecting a vote which is different from the vote and forked with the vote, and sending the vote to the receiving node.
In step SA3, when the witness node checks the signature set, if a signature conflict is found, the conflicting signer is selected as the perpetrator, and if no signature conflict is found, the wrong blocking person is selected as the perpetrator.
In step SA4, the packing height of the obsolete check block is the last confirm height+wait height λ.
In step S2, the witness node checks whether the block to be voted is a descendant block of the determined block, if not, it indicates that there is a bad act, and at this time, the block is not voted for a signature, and the process proceeds directly to step SA1.
In step S2, when the witness node counts the signature votes, it is checked whether the block of the signature votes is a descendant block of the block determined by itself, if not, it is indicated that there is a bad act, and at this time, the statistics of the signature votes is not performed, and the process proceeds directly to step SA1.
In step S3, using a virtual vote number main chain validation rule, specifically, the witness node counts the current height and the votes obtained by all the non-validated blocks traced upward from the current height; if one block at the current height obtains votes of more than 2/3 witness nodes, the block is confirmed, the chain where the block is located is confirmed as a main chain, all the blocks which are not confirmed before the block is located on the chain are confirmed together, and the packing node selects the block as a father block for packing in the next round; if no block at the current height obtains votes of more than 2/3 witness nodes, the packing node traces back from the current height, sums up the votes obtained by the sub-blocks at the same height, and is used as the virtual votes obtained by the common parent blocks of the sub-blocks, if the virtual votes of any parent block reach more than 2/3, the parent block is also confirmed, the chain of the parent block is confirmed as the main chain, the parent block is called an ancestor block, all the unacknowledged blocks in front of the ancestor block on the chain are also confirmed together, the packing node sequentially selects blocks with more virtual votes from top to bottom from the confirmed parent block until the block with the largest votes is obtained at the current height and is used as the parent block for next round of packing.
In addition, the invention also provides a blockchain disqualifying checking system based on the Bayesian tolerance, which comprises a signature set forwarding module to be checked, a voting forwarding constraint module, a checking module and a disqualifying checking module.
In addition, the invention also provides a blockchain disfigurement checking device based on Byzantine tolerance, which comprises: the system comprises a memory, a processor and a blockchain aversion checking program which is stored in the memory and can run on the processor and is based on the Bayesian tolerance, wherein the blockchain aversion checking program based on the Bayesian tolerance is configured with a blockchain aversion checking method based on the Bayesian tolerance.
The invention also provides a storage medium, wherein the storage medium is stored with a blockchain aversion checking program based on the Bayesian tolerance, and the blockchain aversion checking program based on the Bayesian tolerance realizes a blockchain aversion checking method based on the Bayesian tolerance when executed.
By adopting the technical scheme, the invention has the following advantages:
1. the invention can efficiently identify the bad nodes in the consensus network and shorten the block confirmation time.
2. The invention ensures that the confirmation time of the transaction is determined under the bad condition, thereby ensuring that the transaction with higher safety requirement is successfully completed.
3. The invention can effectively ensure the consistency of fault tolerance based on Bayesian and the timeliness of discovering the wrought behaviors.
Drawings
FIG. 1 is a schematic diagram of the voting forwarding constraints of the present invention.
FIG. 2 is a schematic illustration of the invention disfigurement check procedure.
FIG. 3 is a schematic representation of the success of the disfigurement check of the present invention.
FIG. 4 is a schematic representation of the failure of the disfigurement check of the present invention.
Fig. 5 is a schematic diagram of a virtual vote count backbone validation rule of the present invention.
FIG. 6 is a schematic diagram of a disqualifying inspection system of the present invention.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Example 1: the invention discloses a block chain aversion checking method based on Byzantine tolerance, which comprises the following steps of:
s1, packaging a block; s2, the witness node performs signature voting on the block, and the signature voting is counted; s3, judging whether the main chain confirms or not, and carrying out next round of packing after conforming to the packing rule.
The above process is a basic process of blockchain operation based on the bayer tolerance, and is common general knowledge, and the present invention is only basically cited herein, and is not described in detail. In addition to the above flow, the invention also performs voting review work. The voting review work is repeated all the time during the running of the blockchain.
The voting evaluation working steps are as follows:
SA1 witness nodes forward their last confirmed heights to other witness nodes according to voting forwarding constraintIs a signature set to be reviewed;
SA2, all witness nodes review the signature set forwarded by other witness nodes and judge whether the signature set is wrongly acted or not;
SA3 if the disqualifying behavior is found, the witness node will send its own last confirmation altitudeIs given to other seeThe witness node simultaneously requires other witness nodes to send +.>Other branched signature sets which collide with the confirmation block are arranged, and the signature sets are checked, if the signature collision is found, a collision signer is selected as a wrongly person, and if the signature collision is not found, an error block-out person is selected as the wrongly person;
SA4 packaging the wrongdoer, evidence and punishment result into a wrongdoer check block with a packaging height of the final confirmation heightWaiting for height lambda, the obsolete check block competes with the normal block uniformly, but must vote more than 2/3 of the round until acknowledged, if the obsolete check block is acknowledged, then rollback the split block-i.e. last acknowledge height +.>Thereafter, only the chain in which the confirmed obsolete check block resides is reserved, and the other branches are all invalidated.
The voting forwarding constraint in step SA1 is: the current witness node (referred to herein as the sending node) sends the last acknowledgement altitude to the other witness nodes (referred to herein as the receiving nodes)If +.>The sending node receives the vote of the receiving node at the height, then at the height + ->Randomly selecting a vote which is different from the receiving node and is forked, and sending the vote to the receiving node; if no votes have been received from the receiving node, at a height +.>Randomly selecting a part of branches different from the branchVoting, and transmitting to the receiving node.
In the review process of step SA2, if the votes under the different branches of the confirmed block are found, the vote is found to be a bad act.
The basic rules of the bayer tolerance are common knowledge, and the invention is not described in detail, and can further restrict the basic rules of the bayer tolerance, such as:
constraint 1. The witness nodes only vote one round on the block at each height, and collect votes of other witness nodes;
constraint 2. After receiving the votes of more than 2/3 witness nodes under the current height, the packing node can carry out the packing work of the next height block no matter whether the votes are concentrated in the same block or not;
constraint 3. If one block gets votes of more than 2/3 witness nodes, the block is confirmed, the chain where the block is located is confirmed as the main chain, all the blocks which are not confirmed before the block is located on the chain are also confirmed together, and the packing node selects the block as the father block of the next round of packing.
In step S2, the witness node may check whether the block to be voted is a descendant block of the block determined by itself (the current witness node), if not, it indicates that there is a bad act, and at this time, the block is not voted for a signature, and directly proceeds to step SA1.
When the witness node counts the signature votes, it is checked whether the block of the received signature votes is a descendant block of the block determined by itself (the current witness node), if not, it is indicated that there is a bad act, at this time, the statistics of the signature votes is not performed, and the process proceeds directly to step SA1.
The offspring blocks of the present invention refer to: if a current block is traced upward, having a common chain connection with a previous height block, the current block may be referred to as a descendant block of the previous height block. The previous height block may be referred to as an ancestor block of the current block.
In addition, the invention designs a virtual ticket number main chain confirmation rule, specifically, the packing node counts the current height and the ticket number obtained by all the unacknowledged blocks traced upwards by the current height;
if one block at the current height obtains votes of more than 2/3 witness nodes, the block is confirmed, the chain where the block is located is confirmed as a main chain, all the blocks which are not confirmed before the block is located on the chain are confirmed together, and the packing node selects the block as a father block for packing in the next round;
if no block at the current height obtains votes of more than 2/3 witness nodes, the packing node traces back from the current height, sums up the votes obtained by the sub-blocks at the same height, and is used as the virtual votes obtained by the common parent blocks of the sub-blocks, if the virtual votes of any parent block reach more than 2/3, the parent block is also confirmed, the chain of the parent block is confirmed as the main chain, the parent block is called an ancestor block, all the unacknowledged blocks in front of the ancestor block on the chain are also confirmed together, the packing node sequentially selects blocks with more virtual votes from top to bottom from the confirmed parent block until the block with the largest votes is obtained at the current height and is used as the parent block for next round of packing.
The above main chain verification rule may be applied to the present invention, but is not necessarily required. Other conventional backbone validation rules may be used with the present invention.
The invention is described in detail below with reference to the attached drawings:
all witness nodes of the blockchain are commonly known in blocks. Under the condition that packing nodes are not limited, a plurality of nodes can reach agreement in branches with different heights according to the constraint condition of the Bayesian tolerance consensus mechanism, and finally determined main chains are selected. At each height, 3f+1 witness nodes participating in consensus can perform a round of named voting on the existing bifurcation, and when the node collects 2f+1 votes (whether the votes are concentrated in the same block or not), the node can perform judgment of whether the main chain is confirmed or not and perform packing operation of the next block. If witness nodes are at the same heightIf voting is performed twice or more, the node is marked as a dislike node, and f Bayesian nodes are tolerated at most for dislike. When the witness node forwards the signature set, the witness node will perform the voting forwarding constraint, as shown in fig. 1, and assume that a is a transmitting node, E is a receiving node, and the last confirmation height at this time is h. If A receives E votes at h, randomly selecting a voting signature set which is different from node E and is branched to be sent to a packaging node, wherein E votes at hSo can choose as +.>Or (b)Is a voting signature set; if E votes are not received, randomly selecting a set of voting signatures which diverge from itself, e.g. +.>Or->And (3) the voting signature set is sent to E.
All witness nodes can review the received signature sets, if the signature sets are found to be bad, the witness nodes can send signature sets with the last confirmed heights to other witness nodes, meanwhile, other witness nodes are required to send signatures with other branches with the last confirmed heights, the signatures are checked, if signature conflicts are found, the signer is used as a bad person, and if no signature conflicts are found, the wrong blocking person is selected as the bad person.
The node will package the perpetrator, evidence and penalty results into a perpetrator check block, the package height being the own last confirmation height, assuming h+ wait height λ. The sanity check block with height h+lambda competes with the normal block uniformly, but must go through 2f+1 votes per round until confirmed, if the sanity check block is finally confirmed (i.e. after more than 2/3 votes are collected)Waiting time determined in BayesianAlso continuously confirmed in the same, as shown in fig. 2, after the h+λ height is confirmed, two continuous heights of h+λ+1 and h+λ+2 are also confirmed), then the split block is rolled back, i.e., +.>In the following, all branches are invalidated except for the chain in which the obsolete check block is located.
In the process of confirming the main chain, as shown in fig. 5, the voting conditions collected by the nodes are as follows: at a height of a, blockObtain f votes, block->Obtain 1 vote, blockObtain f votes, block->At the a-height, no number of votes is found, and the number of votes obtained by any one block reaches 2f+1, so that the main chain cannot be confirmed at the a-height. At this time, trace back upwards, at a-1 height, block +.>Is a blockSub-blocks of (2), so block->Obtain f virtual votes, block->Block->Is a blockSub-blocks of (2), so block->Obtain f+1 virtual votes, block->Due to block->There is no number of votes, so there is no virtual number of votes, and at a-1 height, the virtual number of votes obtained without any one block reaches 2f+1, so the main chain cannot be confirmed at a-1 height. Continuing the trace back upwards, at a-2 height, due to the blockSum block->Is a block->Sub-blocks of (2), so block->2f+1 virtual votes, block +.>Due to block->There is no virtual number of votes, so it is also no virtual number of votes, at a-2 height, due to the block +.>The number of virtual votes obtained reaches 2f+1, so at a-2 height, the block +.>The chain in which the chain is located is also identified as the main chain. Block->Is called asIs a ancestor block of (c). If block->Was not confirmed before, at this time due to +.>Obtain confirmation, block->Is also confirmed.
The packing node sequentially selects blocks with multiple virtual votes from top to bottom from ancestor blocks until the block with the highest votes are obtained at the current height and is used as a parent block for next round of packing. As shown in fig. 5, the packing nodes will select in turnFinal selection->As the parent block for the a+1 round of packaging.
According to the view of figure 5,and->With a common chain connection, namely:therefore, it is->May be referred to as +.>Is a descendant region of (1)A block. Likewise, the same reason is that->May be referred to as +.>Is a descendant block of (1), but +.>Cannot be called +.>As the two blocks have no common chain connection. But->May be referred to as +.>The connected common chains of the offspring blocks are: />；/>May also be referred to as +.>The connected common chains of the offspring blocks are: />，
Witness node is confirmingThe signature set of the last confirmed height (i.e., the a-2 height here) is then forwarded to other witness nodes according to the voting forwarding constraints. Due to->Is based onThe counted virtual votes are obtained, so the signature set forwarded by the witness node is actually the voting signature set at a height.
Consistency certification based on bayer fault tolerance (where consistency refers to the admission of only one bifurcation block is confirmed):
for a bifurcation at one height, different numbers of votes received may result in different behaviors. We divide witness nodes into two types with different numbers of votes received:
1.to>A set is determined for the branches of the ancestor block. The witness node out of the set will only select +.>At the same time follow-up if found with +.>The blocks that are ancestor blocks are packed, and a dislike check is initiated.
2.To>A set is selected for the branches of the ancestor block. The witness node out of the set will only select +.>But later if found in +.>The blocks that are ancestor blocks are packed, directly to +.>Voting is performed.
According to the validation rules, if there is a branch at a certain future altitudeLower collection toOr the signature vote of the witness node above, he must become the backbone. When->Receive->Witness nodes will only fall into both of these categories. Only when there are duplicate votes from bad nodes will the following occur:
to>A set is selected for the branches of the ancestor block. The witness nodes in the set receive more than one vote or are the nodes packaged by mistake, and the output blocks only select +.>。
From the above, we make the following evidence.
Conclusions to be verified 1: even if there isAnd in the same height, two branches are not confirmed by different witness nodes.
And (3) proving: if there isEach disqualified node can forge different votes for different blocks at the same height, for +.>For each block, at most, there are votes within the same height:
because each block has only one parent block, it can be known that the total number of votes for all branches at the same height is at most:
if it is to be completedConfirmation of more than one branch, at least +.>And (3) completing a plurality of branch confirmation and total ticket number difference values:
when (when)When the value is 1 at the minimum, it is found that even if the number of votes is added, it is impossible to support simultaneous completion of the confirmation of a plurality of branches.
Pending conclusion 2: if blocks of different branches may be identified at different heights, witness nodes collect data within 2 heights after identifying the first branchThe votes necessarily find bad behaviour.
And (3) proving: assuming that there isAnd->Both branches are acknowledged by part of the nodes at different heights. Wherein (1)>At the position ofTicket number collected and +.>At->The number of tickets collected under height is equal to or greater than +.>。
After the branch is confirmed, the branch confirmation set receives the blocks of other branches and initiates a dislike check without voting, so that the branch confirmation set has a pair of branchesThe honest node that votes is not right +.>Confirmation is performed. Based on the above conditions we classify these witness nodes into 3 classes, confirm +.>Is->Not confirmed->Is->Bayesian node->. The method comprises the following steps:
(1)
to ensure thatThe confirmed ones are necessarily:
(2)
so there are:
(3)
because all nodes totalTherefore, there are:
(4)，
according to (2) (4), it is possible to:
(5)
at the height ofAfter that, there is->Middle node Collection->According to (1) (5) can be:
(6)
therefore, it isThe internal nodes must collect +.>Is a vote of (a). />In (a) and (b)Node uncertainty->It is at arbitrary height +>Is->Must contain non +.>Voting under branches, according to the voting forwarding constraint described above, not +.>The votes under the branches are passed on +.>In the node.
At the height ofIn (1) receive height->Not->The voting of the branches is allowed, at which point no aversion is found.
But at the height ofWhen not->The votes of the branches are passed on +.>In the node, at this time, the->When the intermediate node performs the review, the intermediate node can find out the bad behavior.
To sum up, if witness nodes collect a branchThe signature votes of the witness nodes above, if there is a bad behaviour leading to another bifurcation being confirmed, are collected in two rounds +.>Within the vote, it can be found.
Some descriptions about the waiting height λ:
to ensure that the validation time of a transaction is deterministic in case of a bad situation, thereby ensuring that a transaction requiring a high security is completed, it is necessary to provide a waiting time for a Bayesian determination. The bayer determination latency needs to meet the following two conditions:
1. the absence of other branches will be confirmed in the following rounds;
2. the confirmed bifurcation is not rolled back by a sanity check.
From the previous evidence, it is known that in the two collection roundsAfter the voting of (2), it can find out the dislike, check the dislike, and terminate the confirmation wait, so +.>The condition 1 can be satisfied.
Since no two contradictory branches are confirmed at the same height, after confirming one branch, the other nodes need to confirm the contradictory branches at the next height at the highest speed. As shown in the figure 3 of the drawings,at->Time complete->Confirmation of bifurcation, but->Not complete->Confirmation of bifurcation, ->Fastest->Completing confirmation when the test is completed;
because ofCollect->Is the honest node pair +.>Voting necessarily is greater than +.>Therefore, it isCollect->In the voting of (2), remove->The possible Bayesian votes necessarily contain +.>Voting. At this timeFind bad behaviour, for last confirmed height +>A high level of maliciousness is checked at +.>The votes are collected when the time is spent,finish the check confirmation of dislike, finally roll back +.>Time->And (3) bifurcation.
As in fig. 4, ifFailing to collect +.>If the examination is made, the examination will fail, and the +.>Bifurcation is confirmed. Because of->Failing to wait for enough time, therefore->Can not be confirmed and at the same time->After waiting for enough time, cannot be rolled back. Of course, if at time t4 or t5, -/-, is present>Is confirmed because there are no three consecutive check-out confirmations, +.>Eventually it is confirmed.
It can be seen that the light source is,waiting height for disfigurement checkA minimum of 3 and only the rollback of blocks within a height of 2 is completed, so +.>The minimum waiting time is 2, and the condition 2 can be satisfied.
It is therefore preferable that the method comprises,，/>。
it should be noted that the above-described working procedure is merely illustrative, and does not limit the scope of the present invention, and in practical application, a person skilled in the art may select part or all of them according to actual needs to achieve the object of the present invention, which is not limited herein.
Example 2: in addition, as shown in fig. 6, the embodiment of the invention further provides a blockchain aversion checking system based on the Bayesian tolerance, which further comprises a signature set forwarding module to be checked, a voting forwarding constraint module, a checking module and a aversion checking module based on the known blockchain aversion checking system based on the Bayesian tolerance.
The signature set forwarding module to be reviewed is used for forwarding the final confirmation height of the signature set forwarding module to other nodesTo be reviewed.
The voting forwarding constraint module is used for constraining the forwarding content of the signature set forwarding module to be reviewed, and the signature set forwarding module to be reviewed sends the final confirmation height of the signature set forwarding module to be reviewedIf +.>The sending node receives the vote of the receiving node at the height, then at the height + ->Randomly selecting a vote which is different from the receiving node and is forked, and sending the vote to the receiving node; if no votes have been received from the receiving node, at a height +.>And randomly selecting a vote which is different from the vote and forked with the vote, and sending the vote to the receiving node.
And the evaluation module is used for checking the signature set to be evaluated to find out the wrongly acting behavior.
The dislike checking module sends the final confirmation height of the module when the review module finds dislikeIs sent to other witness nodes while requiring them to send +.>Other bifurcated signatures are added, the signatures are checked, if signature conflicts are found, a conflict signer is selected as a wrongly acting person, and if no signature conflicts are found, an error block-out person is selected as a wrongly acting person; then the wrongdoer, the evidence and the punishment result are packed into a wrongdoer check block, the packing height is the final confirmation height +.>+wait height λ.
The obsolete check block and the normal block will compete uniformly, but must go through 2f+1 votes per round until confirmed, if the obsolete check block is confirmed, the obsolete check block will roll back on the split block-i.e. the last confirm heightThereafter, only the chain in which the confirmed obsolete check block resides is reserved, and the other branches are all invalidated.
In addition, the present embodiment is merely a basic description of the blockchain disfigurement checking system based on the bayer tolerance according to the present invention, and technical details not described in detail in the present embodiment may refer to the method provided in any embodiment of the present invention, which is not described herein.
Example 3: it will be apparent to those skilled in the art that the system and method of the above embodiments may be implemented by software plus a necessary general purpose hardware platform, but may also be implemented by hardware, although in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. Read Only Memory)/RAM, magnetic disk, optical disk) and including several instructions for causing a terminal device (which may be a mobile phone, a computer, a node packaging device, or a network device, etc.) to perform the method according to the embodiments of the present invention.
The present invention therefore also provides a b-chain aversion inspection apparatus based on b-camping tolerance, comprising: the system comprises a memory, a processor and a blockchain aversion checking program which is stored in the memory and can run on the processor and is based on the Bayesian tolerance, wherein the blockchain aversion checking program based on the Bayesian tolerance is configured with a blockchain aversion checking method based on the Bayesian tolerance.
In addition, the invention also provides a storage medium, wherein the storage medium is stored with a blockchain disfigurement checking program based on Byzantine tolerance.
Since, in a real situation, when a device or a program is deployed, the execution of a certain program may be to perform all steps, or may be to perform only a certain step, and implement all steps by cooperation of a plurality of programs,
therefore, the blockchain aversion checking program based on the Bayesian tolerance realizes all or a certain flow in the blockchain aversion checking method based on the Bayesian tolerance when being executed.
The foregoing description of the preferred embodiments of the present invention should not be taken as limiting the scope of the invention, but rather should be understood to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the following description and drawings.
Claims (8)
1. The blockchain aversion inspection method based on Bayesian tolerance comprises the following steps: s1, packaging a block; s2, the witness node performs signature voting on the block, and the signature voting is counted; s3, judging whether the main chain confirms or not, and carrying out next round of packaging after conforming to the packaging rule; the method is characterized in that the method also carries out voting and reviewing work, and comprises the following steps:
SA1 witness nodes forward their last confirmed heights to other witness nodes according to voting forwarding constraintIs a signature set to be reviewed;
SA2, all witness nodes review the signature set forwarded by other witness nodes and judge whether the signature set is wrongly acted or not;
SA3 if the disqualifying behavior is found, the witness node will send its own last confirmation altitudeIs sent to other witness nodes while requiring them to send +.>Other bifurcated signature sets which collide with the confirmation block are checked, and a wrongdoer is found;
SA4 packaging the perpetrator, evidence and punishment result into a disfigurement check block, uniformly competing the disfigurement check block and the common block, and if the disfigurement check block is confirmed, rolling back the classified block, namely finally confirming the heightThen, only the chain where the confirmed disfigurement check block is located is reserved, and other branches are all invalidated;
in step SA1, the voting-forwarding constraint is: the transmitting node transmits the last acknowledgement altitude to the receiving nodeIf +.>The sending node receives the vote of the receiving node at the height, then at the height + ->Randomly selecting a vote which is different from the receiving node and is forked, and sending the vote to the receiving node; if no votes have been received from the receiving node, at a height +.>And randomly selecting a vote which is different from the vote and forked with the vote, and sending the vote to the receiving node.
2. The method according to claim 1, wherein in step SA3, when the witness node checks the signature set, if a signature conflict is found, the conflicting signer is selected as a wrongly, and if no signature conflict is found, the wrong signer is selected as a wrongly.
3. The method as claimed in claim 1, wherein in step SA4, the packing height of the block for the bad check is the last confirmed height+wait height λ.
4. The method according to claim 1, wherein in step S2, the witness node checks whether the block to be voted is a descendant of the block determined by itself, and if not, indicates that there is a bad act, and the block is not voted for a signature and proceeds directly to step SA1.
5. The method according to claim 1, wherein in step S2, when the witness node counts the signature votes, it is checked whether the block of the signature vote is a descendant block of the block determined by itself, and if not, it indicates that there is a bad act, and the statistical work of the signature vote is not performed any more, and the process proceeds directly to step SA1.
6. The blockchain disqualifying checking system based on the Bayesian tolerance is characterized by comprising a signature set forwarding module to be reviewed, a voting forwarding constraint module, a review module and a disqualifying checking module;
the signature set forwarding module to be reviewed is used for forwarding the final confirmation height of the signature set forwarding module to other nodesIs a signature set to be reviewed;
the voting forwarding constraint module is used for constraining the forwarding content of the signature set forwarding module to be reviewed, and the voting forwarding constraint is as follows: the transmitting node transmits the last acknowledgement altitude to the receiving nodeIf +.>The sending node receives the vote of the receiving node at the height, then at the height + ->Randomly selecting a vote which is different from the receiving node and is forked, and sending the vote to the receiving node; if no vote of the receiving node has been received, then at altitude/>Randomly selecting a vote which is different from the vote and is forked with the vote, and sending the vote to a receiving node;
the evaluation module is used for checking the signature set to be evaluated to find out the wrongly acting;
the dislike checking module is used for sending the final confirmation height of the user when the dislike checking module finds out dislike behaviorsIs sent to other witness nodes while requiring them to send +.>Other branched signature sets conflicting with the validation block are added, and these signature sets are checked to find out the wrongdoer, then the wrongdoer, evidence and penalty result are packed to generate a wrongdoer check block, the wrongdoer check block and the ordinary block are uniformly competing, if the wrongdoer check block is validated, the branched block is rolled back, i.e. the final validation height->Thereafter, only the chain in which the confirmed obsolete check block resides is reserved, and the other branches are all invalidated.
7. A b/c-tolerant based blockchain aversion inspection apparatus comprising a memory, a processor and a b/c-tolerant based blockchain aversion inspection program stored on the memory and executable on the processor, the b/c-tolerant based blockchain aversion inspection program being configured to implement the b/c-tolerant based blockchain aversion inspection method of any one of claims 1 to 5.
8. A storage medium, wherein a block chain aversion inspection program based on the bayer tolerance is stored on the storage medium, and when executed, the block chain aversion inspection method based on the bayer tolerance according to any one of claims 1 to 5 is realized.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310947912.9A CN116668199B (en) | 2023-07-31 | 2023-07-31 | Block chain disfigurement checking method based on Bayesian tolerance |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310947912.9A CN116668199B (en) | 2023-07-31 | 2023-07-31 | Block chain disfigurement checking method based on Bayesian tolerance |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116668199A CN116668199A (en) | 2023-08-29 |
| CN116668199B true CN116668199B (en) | 2023-10-10 |
Family
ID=87724591
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310947912.9A Active CN116668199B (en) | 2023-07-31 | 2023-07-31 | Block chain disfigurement checking method based on Bayesian tolerance |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116668199B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114090693A (en) * | 2022-01-18 | 2022-02-25 | 安徽中科晶格技术有限公司 | Byzantine fault-tolerant-based block chain witness consensus method, system, equipment and storage medium |
| CN115473710A (en) * | 2022-08-31 | 2022-12-13 | 杭州云象网络技术有限公司 | Byzantine fault-tolerant consensus method applied to block chain |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108898390B (en) * | 2018-06-27 | 2021-01-12 | 创新先进技术有限公司 | Intelligent contract calling method and device based on block chain and electronic equipment |
| US11366910B2 (en) * | 2018-12-27 | 2022-06-21 | Eli Talmor | Method and system for secure applications using blockchain |
| US11526610B2 (en) * | 2019-05-21 | 2022-12-13 | Veracode, Inc. | Peer-to-peer network for blockchain security |
-
2023
- 2023-07-31 CN CN202310947912.9A patent/CN116668199B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114090693A (en) * | 2022-01-18 | 2022-02-25 | 安徽中科晶格技术有限公司 | Byzantine fault-tolerant-based block chain witness consensus method, system, equipment and storage medium |
| CN115473710A (en) * | 2022-08-31 | 2022-12-13 | 杭州云象网络技术有限公司 | Byzantine fault-tolerant consensus method applied to block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116668199A (en) | 2023-08-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102469267B1 (en) | Blockchain consensus method, accounting node and node | |
| CN106789844B (en) | Malicious user identification method and device | |
| CN111695994B (en) | Block chain consensus method and system based on credit score | |
| CN116668199B (en) | Block chain disfigurement checking method based on Bayesian tolerance | |
| CN111028969B (en) | Design method of containment control strategy of nuclear power plant | |
| CN115022326A (en) | Block chain Byzantine fault-tolerant consensus method based on collaborative filtering recommendation | |
| CN109582578B (en) | System, method, computer readable medium and electronic device for software test case | |
| CN111563044B (en) | Program spectrum error positioning method based on program variation | |
| US7310791B2 (en) | Method for correcting layout errors | |
| CN112288533A (en) | Payment order fusing protection method and device and electronic equipment | |
| WO2024040796A1 (en) | Block chain power transaction system, consensus method, device and storage medium | |
| CN111898123B (en) | Malicious operation identification method, device, equipment and readable storage medium | |
| CN115277108A (en) | Method and system for defending decentralized application race attack | |
| CN115062312A (en) | Intelligent contract vulnerability detection method, device, equipment and storage medium | |
| Diks et al. | Optimal adaptive broadcasting with a bounded fraction of faulty nodes | |
| CN114610544A (en) | Artificial intelligence big data analysis processing system and method based on block chain | |
| CN113922347A (en) | Ground protection fixed value optimization method and system based on mismatch degree evaluation index and storage medium | |
| CN112529462A (en) | Service verification method, device, server and storage medium | |
| CN112037062A (en) | Transaction consensus method, device, electronic equipment and readable storage medium | |
| CN113256289A (en) | Block chain judging method and device and electronic equipment | |
| CN111695997A (en) | Block chain consensus method and system based on node credit scoring and pre-loyalty points | |
| CN111666562B (en) | Active defense method and system for software security | |
| CN115174565B (en) | Consensus method and device based on block chain slicing technology | |
| CN117112288B (en) | Disk array verification method and device, storage medium and electronic equipment | |
| JP2001067248A (en) | System and method for gathering fault log |
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 |