CN116015674A - Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature - Google Patents
Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature Download PDFInfo
- Publication number
- CN116015674A CN116015674A CN202211623691.1A CN202211623691A CN116015674A CN 116015674 A CN116015674 A CN 116015674A CN 202211623691 A CN202211623691 A CN 202211623691A CN 116015674 A CN116015674 A CN 116015674A
- Authority
- CN
- China
- Prior art keywords
- node
- signature
- nodes
- information
- random number
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000012795 verification Methods 0.000 claims abstract description 18
- 230000008569 process Effects 0.000 claims abstract description 17
- 238000004364 calculation method Methods 0.000 claims abstract description 4
- 239000011159 matrix material Substances 0.000 claims description 49
- 238000012360 testing method Methods 0.000 claims description 9
- 238000007689 inspection Methods 0.000 claims description 7
- 238000012508 change request Methods 0.000 claims description 6
- 230000007246 mechanism Effects 0.000 claims description 5
- 230000004044 response Effects 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 230000008859 change Effects 0.000 claims description 3
- 230000009191 jumping Effects 0.000 claims description 2
- 238000005516 engineering process Methods 0.000 abstract description 10
- 238000013507 mapping Methods 0.000 abstract description 2
- 238000004891 communication Methods 0.000 description 9
- 230000002776 aggregation Effects 0.000 description 6
- 238000004220 aggregation Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a Bayesian-tolerant error node consensus method based on a threshold signature, which mainly solves the problems of low Bayesian-tolerant safety and low algorithm performance of the existing consensus technology. The implementation scheme is as follows: dividing the nodes in the network into four groups, and selecting reliable nodes in the groups according to the trust value of the nodes in each group to host a consensus process by a selected leader node; each group of selected leader nodes transmits transaction information to the group of nodes; the node in the group verifies the received message, signs the transaction information considered to be correct by the node in the group, and broadcasts the transaction information to the node in the leader in the group; and the leader nodes of each group share the received signature information, aggregate and verify the received signature information by adopting a threshold signature technology and a bilinear mapping method, and verify that the passed transaction achieves consensus among all nodes. The invention improves consensus efficiency and system safety, reduces the calculation amount in the verification process, and can be applied to the transaction process on the blockchain.
Description
Technical Field
The invention belongs to the technical field of computers, and further relates to a Bayesian error-resistant node consensus method which can be applied to a transaction process on a block chain.
Background
With the continuous development of internet technology, people work and life are closely related to the internet. With the proliferation of the number of users, the number of requests made per unit time, and the amount of data processed per unit time are not acceptable by the traditional single machine system. For this reason, distributed storage has been developed. The distributed storage achieves the aim of data consistency by dispersing and storing data on a plurality of independent devices and coordinating the operation among the devices. In recent years, with the heat of the blockchain technology, the problem of ensuring the consistency of data among nodes of a cluster under distributed storage has become an important point.
The prior art of ensuring consistency of data copies maintained by all nodes in a distributed storage system mainly adopts a consensus method. In the running process of the consensus method, the performance of the consensus method in terms of safety, activity, efficiency and the like is mainly focused. The problem of inconsistent data among nodes of the security requirement cluster is avoided; the active requirement cluster can continue to provide service to the outside under the condition that part of nodes are down; efficiency requires that the cluster node reach consensus on a piece of data not be too long. Because distributed storage has high requirements on security and efficiency, the design of a consensus method with high security, high activity and high efficiency has important significance.
Diego Ongaro et al, in its published paper "In search of an understandable consensus algorithm," presents a compact, easily understood Leader election and log replication consensus method. The method is a non-Bayesian fault-tolerant CFT type consensus method, namely nodes participating in consensus cannot tamper transaction information and log content. The specific process is as follows: the system randomly selects a certain node to be a leader node according to the timeout time, the leader node sends the received transaction information to other nodes in the system, the other nodes respond according to the voting mode, and when a plurality of nodes in the system approve the transaction, the transaction is considered to be agreed in the whole system. The method is mainly oriented to a distributed database and a blockchain system with a node verification function, so that for some open applications, for example, a public-chain blockchain system with nodes capable of being added at will, wherein the nodes participating in consensus may be Byzantine malicious nodes, and the method cannot be applied.
In the paper "Practical byzantine fault tolerance and proactive recovery" published by Barbara Liskov et al, a first Bayesian fault-tolerant method applied to the engineering field is proposed, which adopts a 3-stage communication interaction process, and confirms the communication complexity of the original Bayesian fault-tolerant method by mutual interaction between nodes, wherein the communication complexity of the original Bayesian fault-tolerant method is defined by O (n 3 ) Reduce to O (n) 2 ). In the method, as the main node is selected in turn according to the number, the selecting mode is easy to be attacked by DDoS and Sybil in the P2P network, and has potential safety hazard; and because three-stage broadcasting is adopted, the whole network forwarding with extremely high communication overhead is required to be carried out twice, and the consensus efficiency is seriously affected.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a method for consensus of Bayesian error-resistant nodes based on threshold signatures, so as to avoid potential safety hazard to a system caused by a Bayesian malicious node becoming a leader node and improve the consensus efficiency of on-chain transactions.
The technical scheme of the invention is as follows: the method solves the problem that the CFT type consensus method cannot be applied to a public chain block chain system with Byzantine malicious nodes by combining a threshold signature technology in a cryptography theory and a trust value of a computing node, and the PBFT method sequentially selects leader nodes according to numbers, so that the malicious leader nodes cause potential safety hazards such as DDoS attack and Sybil attack, and the like, and the realization steps comprise the following steps:
1. a Bayesian error resistant node consensus method based on threshold signature is characterized by comprising the following steps:
(1) Initializing a system;
(1a) In the key initialization stage, a trusted third party mechanism TTP assists a blockchain system to generate a public-private key pair (x, y), the public key y is disclosed, the private key x is divided into N parts and provided for N nodes to share, and each node holds part of the private key x i The method comprises the steps of carrying out a first treatment on the surface of the Third party institutionThe TTP generates a random number matrix XX for private of a signature party and a random number public key matrix YY corresponding to the random number matrix XX, and distributes the random number matrix XX to N nodes in the system;
(1b) In system initialization grouping, nodes are divided into four groups according to traffic analysis, a trust value threshold value TV is set, and an initialization trust value higher than the threshold value is set for each node
(1c) When the system initiates leader election, each group independently elects in the group
The node with the highest value becomes the leader node;
(2) The client sends a Request message < Request < m, t, c > containing transaction content m, client information c and a view client Request sequence timestamp t to a leader node of each group;
(3) The leader node allocates a serial number n for the received transaction information, and sends the message content m, the transaction serial number n, the view number v and the abstract d of the message to other nodes in the group for checking through the message < < appdities, v, n, d >, m >:
if the check is passed, the node enters a signature response stage, and the step (4) is executed;
otherwise, jumping to the step (8) to perform view replacement;
(4) The node entering the signature response stage utilizes the private key x allocated by the TTP for itself in the step (1) i And a random number matrix XX, YY signs the received transaction information and sigma the signature i Private key x i Corresponding public key y i Information w for verifying a signature i By message<<AppendEntriesReponse,v,n,i>,y i ,w i ,σ i >Broadcasting to all nodes except for the nodes in the group, wherein v is the current view number, and i is the node number;
(5) After the leader node receives at least t +1 appendesresponse messages,signature information sigma received by oneself i By acknowledgement messages<<Commit,v,n,i>,y i ,w i ,σ i >Transmitting to all leader nodes except for oneself;
(6) Any leader node aggregates the more than t+1 Commit messages after receiving them, and verifies the aggregate signature σ:
if the verification is passed, executing the step (7);
otherwise, verify the received partial signature sigma i And to sigma i Verifying the nodes i which do not pass the step (8);
(7) Any leader node enters a Reply phase and broadcasts a message < < Reply, v, t, c, i >, w, sigma > with an aggregate signature sigma and verification information w to a client;
(8) View replacement of unverified signature:
(8a) Any node in the system that is considered to need to initiate a view change will contain its own signature information sigma i Verification information w i Part of public key y i View change request of (a)<Viewchange<h,v-1,i,v,m>y i ,w i ,σ i >Transmitting to other nodes in the same group, wherein v is a new view number, and h is summary information;
(8b) Any node which receives at least t+1 view replacement requests aggregates signature information and verifies the signature information:
if the verification is passed, the step (8 c) is entered;
otherwise, returning to the step (8 a) to reinitiate the view replacement request;
(8c) The node sends a < ViewChange-ack, < h, i, v >, y, w, sigma > message to other different leader nodes in the system; other leader nodes clear the consistency request before view replacement, nodes in the system are also regrouped, and step (9) is executed;
(9) A leader election process;
(9a) Node receiving leader election signal, calculates own TV under view v v i Value, TV within each group v i The highest value nodeThe point will send a message<RequestVote,v,t,TV v i >Giving other nodes in the packet;
(9b) After receiving the RequestVote message, other nodes in the group check the RequestVote message;
if the check passes, the leader node sends a message containing y to other nodes in the group i ,w i ,σ i Is a message of (2)<RequestVoteResponse,v,t,TV v i >y i ,w i ,σ i >；
Otherwise, returning to the step (8 a) to reinitiate the view replacement request;
(9c) After receiving more than t+1 RequestVoteResponse requests, the node synthesizes the requests into an aggregate signature and verifies the signature;
if the verification is passed, the node sends a message < < value, v, t, i > y, w, sigma > selected by the node as a leader to the client and other grouping leader nodes to finish leader election;
otherwise, returning to the step (8).
Compared with the prior art, the invention has the following advantages:
1) According to the invention, as a trust value calculation mode is introduced, namely, different trust values are given to each node according to the behavior of each node in the consensus process and the communication delay of each node and other nodes, the reliability of election can be improved, so that the node with higher consensus efficiency becomes a leader node, the potential safety hazard caused by the fact that the leader node is selected by turns by the nodes in the existing consensus technology is effectively solved, and the problem of 'lean and rich' caused by the fact that a single node becomes the leader node for many times is effectively avoided.
2) The invention introduces the threshold signature technology, and the system private key can be recovered only if the threshold signature technology requires any node combination more than the threshold number, otherwise, the system private key cannot be recovered, so that the system private key cannot be recovered even if the nodes with less than the threshold number are combined, the system can resist the busy malicious nodes, and the consensus safety is improved.
3) The invention introduces bilinear mapping technology, which can reduce the communication complexity of the existing Bayesian error resistant consensus technology and improve the consensus efficiency while ensuring the same security.
Drawings
FIG. 1 is a flow chart of an implementation of the present invention;
FIG. 2 is an overall node interaction diagram of a portion of a consensus transaction in accordance with the present invention;
FIG. 3 is an overall node interaction diagram of the view conversion section of the present invention;
FIG. 4 is an overall node interaction diagram of the leader election portion of the present invention.
Detailed Description
The invention will be further described with reference to the accompanying drawings.
Referring to fig. 1, the implementation steps of this example are as follows:
Before transaction consensus begins, initializing a system, wherein the system comprises the steps of initializing a secret key, initializing node grouping conditions and initializing node elections of each grouping leader, and the specific implementation is as follows:
1.1 Initializing the key):
1.1.1 Generating public-private key pairs (x, y) through a trusted third party mechanism TTP auxiliary blockchain system, dividing the private key x into N parts and providing the N parts for N nodes to share, wherein each node holds part of the private key x i ；
1.1.2 Third party authority TTP generates a random number matrix XX for private use by the signer and a corresponding random number public key matrix YY:
first, define G 1 ,G 2 For two multiplications groups g 1 ,g 2 To generate the element, p is the group G 1 E is G 1 ×G 1 →G 2 Defining a hash function H: {0,1} * →G 1 Public key
Public system parameter params= { G 1 ,G 2 ,e,y,H}；
Next, a random number matrix XX proprietary to the signer is generated by the third party authority TTP:
then, the third party mechanism TTP calculates a formula according to the public key
Calculating a corresponding public random number matrix YY:
wherein xx jk A random element of the jth row and the kth column in the private random number matrix, wherein j is from 1 to u, and k is from 1 to v;
for an element in the j-th row and k-th column of the public random number matrix, mod p is the remainder of each element in the matrix;
1.1.3 Third party authority TTP generates a private random number matrix XX for each node i i And public random number matrix YY i ：
First, each element in the random number matrix XX is divided into N parts according to a secret sharing scheme, and a private random number matrix XX is generated for each node i i ：
Then, according to the calculation formula of the public key
Calculating a public random number matrix YY corresponding to each node i i ：/>
Wherein (xx) jk ) i Is a random element of the jth row and kth column in the private random number matrix of node i,
the method comprises the steps that mod p is an element of a jth row and a kth column in a public random number matrix of a node i, and each element in the matrix is subjected to redundancy;
1.2 Initialization of node packets: dividing the nodes into four groups according to the analysis of the traffic, and replacing the mutual communication of all the nodes by the mutual communication of part of the nodes so as to reduce the communication complexity and improve the consensus efficiency;
1.3 Initializing leader elections: setting an initialization trust value for each node i
Select +/within each group>
The highest valued node becomes the leader node.
The consensus transaction portion is described below in connection with FIG. 2:
and step 2, the client transmits transaction information.
The client sends a Request message < Request < m, t, c > containing transaction content m, client information c and a view client Request sequence timestamp t to a leader node of each group;
and 3, the leader node sends transaction information to the nodes in the group, and other nodes check the transaction information.
3.1 The leader node sends information containing message content m, transaction sequence number n, view number v and message abstract d to other nodes in the group;
3.2 Other nodes verify the received information, the verification content of which includes three aspects:
one is to check whether the summary information of m is consistent with d,
secondly, checking whether the view number v is consistent with the view number known by the user,
thirdly, checking whether the message number n is a valid number;
3.3 Determining the subsequent operation according to the result of the inspection:
if the inspection content is completely passed, step 4 is executed,
otherwise, step 8 is run.
And 4, broadcasting signature information among the nodes in the group.
4.1 A) private key x assigned to the node by a third party authority i And a private key random number matrix XX, the public key random number matrix YY signing the received transaction information:
4.1.1 Node calculates the random number R according to the node number i, the message m z ：
R z ＝h(m)mod i
Where h (m) is the hash result of the transaction message;
4.1.2 Sequentially taking out random number matrix XX i In column z, R z The random numbers of the rows are summed to obtain a random number R selected by the node i i ：
Wherein the method comprises the steps of
Is a random number matrix XX i In column z, R z The random number of the row, mod p, is the remainder of the result of summing;
4.1.3 Node calculates signature information sigma for a message i Verifying signed information w i Public key information y i ：
Wherein x is i For the partial private key corresponding to node i, y i G, for the partial public key corresponding to node i 1 For the first multiplication group G 1 Is a generator of (1);
4.2 Intra-group node completing signature sigma signature i Private key x i Corresponding public key y i Information w for verifying a signature i Broadcast to all nodes within the group except for themselves.
And 5, the leader node sends signature information to other grouping leader nodes.
When the leader node receives the signature information of more than t+1 nodes, the leader node sends the received signature information to all leader nodes except the leader node through the confirmation information.
And 6, aggregating and verifying the signatures by the leader node.
6.1 For the leader node to receive more than t+1 signature information, according to the received signature information { sigma } 1 ,σ 2 ,...,σ t -calculating an aggregate signature σ, and verifying signature information w, public key information y:
wherein x is i R is a partial private key of a node i The random number selected for node i, R is the random number ultimately selected by the signerX is a system private key, h (m) is a hash result of transaction information, g 1 For the first multiplication group G 1 Is lambda i Is a Lagrangian coefficient;
6.2 The leader node checks the aggregate signature result σ):
e(σ,g 1 )＝e(h(m),yw)
wherein e is a specified bilinear map; if the result on the left side of the equation is equal to the result on the right side of the equation, the test passes;
6.3 Determining the subsequent operation according to the result of the inspection:
if the aggregate signature sigma passes the check, the step 7 is operated;
otherwise, respectively verifying the received signature sigma i ；
6.4 Leadership node signs sigma for each part i And (3) performing inspection:
e(σ i ,g 1 )＝e(w i y i ,h(m))
wherein sigma i G for the received signature from node i 1 For the first multiplication group G 1 If the result on the left side of the equation is equal to the result on the right side of the equation, then the test is passed;
6.5 Determining the subsequent operation according to the result of the inspection:
if signature sigma i If the test fails, the step 8 is executed;
otherwise, check the next signature sigma received i ；
Step 7, the leader node broadcasts a message < < Reply, v, t, c, i >, w, σ > with the aggregate signature σ and the verification information w to the client.
And 8, the node performs view replacement on the signature which is not verified.
Referring to fig. 3, the specific implementation of this step is as follows:
8.1 The node initiates a view change, there are three cases:
the slave node does not receive the leader node message within the timeout period;
the message signature verification of the leader node fails;
receiving more than f+1 error feedback information from the node;
8.2 A node that considers a need to initiate a view change request sends a signature message to other nodes in the group.
The node which needs to initiate the view replacement request is considered to sign the message, and the specific process is the same as the signature method in the step 4.1); the node will then contain its own signature information sigma i Verification information w i Part of public key y i The view change request of (2) is sent to other nodes in the same group;
8.3 More than t+1 signature messages sigma are received by other nodes in the group i The aggregation into a signature sigma, the specific process is the same as the aggregation mode in the step 6.1);
8.4 The node which completes the aggregation signature checks the aggregation result sigma, and the specific implementation process is the same as the checking mode in the step 6.2);
8.5 Determining the subsequent operation according to the result of the inspection:
if the verification is passed, the step 8.6) is entered;
otherwise, returning to the step 8 to reinitiate the view replacement request;
8.6 The node which completes the aggregate signature sends the message containing the aggregate signature to other different leader nodes in the system, and the other leader nodes remove the consistency request before the view replacement after receiving the message and regroup the nodes in the system.
And 9, the node elects the leader in the group.
Referring to fig. 4, the specific implementation of this step is as follows:
9.1 Node that receives leader election signal, calculates its own TV under view v v i Value:
wherein a, b, c are three different adjustment factors, respectively, isLeader is a 0/1 variable,to indicate whether the node is the leader node in view v-1, feekmessage indicates the amount of error feedback information received by the node in view v-1,
representing the average time of the node to communicate feedback with other nodes;
9.2 Intra-group TV) v i The node with the highest value will message<RequestVote,v,t,TV v i >Sending to other nodes in the packet;
9.3 Checking the received information by other nodes:
9.3.1 Judging the TV of the node sending the RequestVote message v i Whether the value is greater than itself;
if yes, go through the check, execute step 9.3.2);
otherwise, no information is sent;
9.3.2 Judging whether the view number contained in the RequestVote message is consistent with the view number considered by the RequestVote message;
if the two types of the data are consistent, the step 9.4) is executed through checking;
otherwise, no information is sent.
9.4 A node passing the test sends a message containing y to other nodes in the group i ,w i ,σ i The specific process is the same as the signature method described in step 4.1);
9.5 More than t+1 signature messages sigma are received by other nodes in the group i The aggregation into a signature sigma, the specific process is the same as the aggregation mode in the step 6.1);
9.6 A node that completes the aggregate signature verifies the aggregate result σ: the specific implementation process is the same as the test mode in the step 6.2);
9.7 Determining the subsequent operation according to the test result:
if the verification is passed, the node sends the message selected as the leader to the client and other grouping leader nodes to complete the consensus transaction process;
otherwise, returning to the step 8 to reinitiate the view replacement request.
The above description is only one specific example of the invention and does not constitute any limitation of the invention, and it will be apparent to those skilled in the art that various modifications and changes in form and details may be made without departing from the principles, construction of the invention, but these modifications and changes based on the idea of the invention are still within the scope of the claims of the invention.
Claims (10)
1. A Bayesian error resistant node consensus method based on threshold signature is characterized by comprising the following steps:
(1) Initializing a system;
(1a) In the key initialization stage, a trusted third party mechanism TTP assists a blockchain system to generate a public-private key pair (x, y), the public key y is disclosed, the private key x is divided into N parts and provided for N nodes to share, and each node holds part of the private key x i The method comprises the steps of carrying out a first treatment on the surface of the The third party mechanism TTP generates a random number matrix XX for private signature parties and a random number public key matrix YY corresponding to the random number matrix XX, and distributes the random number matrix XX and the random number public key matrix YY to N nodes in the system;
(1b) In system initialization grouping, nodes are divided into four groups according to traffic analysis, a trust value threshold value TV is set, and an initialization trust value TV higher than the threshold value is set for each node 0 i ；
(1c) Each group independently elects TV within the group upon system initialization leader election 0 i The node with the highest value becomes the leader node;
(2) The client sends a Request message < Request < m, t, c > containing transaction content m, client information c and a view client Request sequence timestamp t to a leader node of each group;
(3) The leader node allocates a serial number n for the received transaction information, and sends the message content m, the transaction serial number n, the view number v and the abstract d of the message to other nodes in the group for checking through the message < < appdities, v, n, d >, m >:
if the check is passed, the node enters a signature response stage, and the step (4) is executed;
otherwise, jumping to the step (8) to perform view replacement;
(4) The node entering the signature response stage utilizes the private key x allocated by the TTP for itself in the step (1) i And a random number matrix XX, YY signs the received transaction information and sigma the signature i Private key x i Corresponding public key y i Information w for verifying a signature i By message<<AppendEntriesReponse,v,n,i>,y i ,w i ,σ i >Broadcasting to all nodes except for the nodes in the group, wherein v is the current view number, and i is the node number;
(5) After receiving at least t+1 appendesresponse messages, the leader node sends signature information sigma received by itself i By acknowledgement messages<<Commit,v,n,i>,y i ,w i ,σ i >Transmitting to all leader nodes except for oneself;
(6) Any leader node aggregates the more than t+1 Commit messages after receiving them, and verifies the aggregate signature σ:
if the verification is passed, executing the step (7);
otherwise, verify the received partial signature sigma i And to sigma i Verifying the nodes i which do not pass the step (8);
(7) Any leader node enters a Reply phase and broadcasts a message < < Reply, v, t, c, i >, w, sigma > with an aggregate signature sigma and verification information w to a client;
(8) View replacement of unverified signature:
(8a) Any node in the system that is considered to need to initiate a view change will contain its own signature information sigma i Verification information w i Part of public key y i View change request of (a)<Viewchange<h,v-1,i,v,m>y i ,w i ,σ i >Transmitting to other nodes in the same group, wherein v is a new view number, and h is summary information;
(8b) Any node which receives at least t+1 view replacement requests aggregates signature information and verifies the signature information:
if the verification is passed, the step (8 c) is entered;
otherwise, returning to the step (8 a) to reinitiate the view replacement request;
(8c) The node sends a < ViewChange-ack, < h, i, v >, y, w, sigma > message to other different leader nodes in the system; other leader nodes clear the consistency request before view replacement, nodes in the system are also regrouped, and step (9) is executed;
(9) A leader election process;
(9a) Node receiving leader election signal, calculates own TV under view v v i Value, TV within each group v i The highest valued node will send the message<RequestVote,v,t,TV v i >Giving other nodes in the packet;
(9b) After receiving the RequestVote message, other nodes in the group check the RequestVote message;
if the check passes, the leader node sends a message containing y to other nodes in the group i ,w i ,σ i Is a message of (2)<RequestVoteResponse,v,t,TV v i >y i ,w i ,σ i >；
Otherwise, returning to the step (8 a) to reinitiate the view replacement request;
(9c) After receiving more than t+1 RequestVoteResponse requests, the node synthesizes the requests into an aggregate signature and verifies the signature;
if the verification is passed, the node sends a message < < value, v, t, i > y, w, sigma > selected by the node as a leader to the client and other grouping leader nodes to finish leader election;
otherwise, returning to the step (8).
2. The method of claim 1 wherein the third party authority TTP in step (1) generates a private random number matrix XX and its corresponding public key random number matrix YY as follows:
(1a) And (3) system establishment:
definition G 1 ,G 2 For two multiplications groups g 1 ,g 2 To generate the element, p is the group G 1 E is G 1 ×G 1 →G 2 Defining a hash function H: {0,1} * →G 1 Public key
Public system parameter params= { G 1 ,G 2 ,e,y,H}；
(1b) The TTP generates a random number matrix XX for private signature party, and calculates a corresponding public random number matrix YY according to the calculation formula of the public key in 1 (a), and the structure is as follows:
wherein xx jk A random element of the jth row and the kth column in the private random number matrix, wherein j is from 1 to u, and k is from 1 to v;
for an element in the j-th row and k-th column of the public random number matrix, mod p is the remainder of each element in the matrix.
3. The method of claim 1 wherein the third party authority TTP in step (1) sends the private random number matrix XX and the public random number matrix YY to N nodes in the system by dividing each element in the random number matrix XX, YY into N shares according to a secret sharing scheme and distributing their secrets to each node in the network, the private random number matrix XX obtained by each node i i And public random number matrix YY i The following are respectively indicated:
wherein (xx) jk ) i Is a random element of the jth row and kth column in the private random number matrix of node i,
the mod p is one element of the j-th row and the k-th column in the public random number matrix of the node i, and the mod p is used for taking the remainder of each element in the matrix.
4. The method of claim 1, wherein the other nodes in the group in step (3) examine messages < < appdities, v, n, d >, m > comprising: checking whether the summary information of m is consistent with d; checking whether the view number v is consistent with the view number known by the user; it is checked whether the message number n is a valid number.
5. The method of claim 1, wherein the signature σ is calculated in step (4) i Public key y i Information w for verifying a signature i The implementation is as follows:
(4a) The node calculates the random line number R according to the node number i, the message m z ：
R z ＝h(m)mod i
Where h (m) is the hash result of the transaction message;
(4b) Sequentially taking out random number matrix XX i In column z, R z The random numbers of the rows are summed to obtain a random number R selected by the node i i ：
Wherein the method comprises the steps of
Is a random number matrix XX i In column z, R z The random number of the row, mod p, is the remainder of the result of summing;
(4c) Node calculates signature information sigma for a message i Verifying signed information w i Public key information y i ：
Wherein x is i For the partial private key corresponding to node i, y i G, for the partial public key corresponding to node i 1 For the first multiplication group G 1 Is a generator of (1).
6. The method of claim 1, wherein the leader node aggregates the received messages exceeding t+1 Commit and verifies the signature in step (6) by:
(6a) The leader node receives signature information { sigma }, based on the received signature information 1 ,σ 2 ,...,σ t -calculating an aggregate signature σ, and information w, y for verifying the signature:
wherein x is i R is a partial private key of a node i The random number selected for node i, R is the random number ultimately selected by the signer, x is the system private key, h (m) isHash result of transaction information g 1 For the first multiplication group G 1 Is lambda i Is a Lagrangian coefficient;
(6b) The leader node checks the aggregate signature result sigma:
e(σ,g 1 )＝e(h(m),yw)
wherein e is a specified bilinear map; if the left-hand side of the equation is equal to the right-hand side of the equation, the test passes.
(6c) The leader node signs sigma for each part i And (3) performing inspection:
e(σ i ,g 1 )＝e(w i y i ,h(m))
wherein sigma i G for the received signature from node i 1 For the first multiplication group G 1 If the result on the left of the equation is equal to the result on the right of the equation, then the test passes.
7. The method of claim 1, wherein the node in step (8 a) that needs to initiate a view change request calculates signature σ i Public key y i Information w for verifying a signature i The implementation is as follows:
(8a1) The node calculates the random line number R according to the node number i, the message m z ：
R z ＝h(m)mod i
Where h (m) is the hash result of the transaction message;
(8a2) Sequentially taking out random number matrix XX i In column z, R z The random numbers of the rows are summed to obtain a random number R selected by the node i i ：
Wherein the method comprises the steps of
Is a random number matrix XX i In column z, R z Random number of rows mod p is the junction for summingFruit residue is taken;
(8a3) Node calculates signature information sigma for a message i Verifying signed information w i Public key information y i ：
Wherein x is i For the partial private key corresponding to node i, y i G, for the partial public key corresponding to node i 1 For the first multiplication group G 1 Is a generator of (1).
8. The method of claim 1, wherein the node receiving at least t+1 view change requests in step (8 b) aggregate signs and verifies the message by:
(8b1) The node receives signature information { sigma }, based on the received signature information 1 ,σ 2 ,...,σ t -calculating an aggregate signature σ, and information w, y for verifying the signature:
wherein x is i R is a partial private key of a node i The random number selected for the node i, R is the random number finally selected by the signing party, x is the system private key, h (m) is the hash result of the transaction information, g 1 For the first multiplication group G 1 Is lambda i Is a Lagrangian coefficient;
(8b2) The node checks the aggregate signature result sigma:
e(σ,g 1 )＝e(h(m),yw)
wherein e is a specified bilinear map; if the left-hand side of the equation is equal to the right-hand side of the equation, the test passes.
9. The method of claim 1, wherein the node receiving the leader election signal in step (9 a) calculates its own TV under view v v i The values, the formula, are as follows:
wherein a, b, c are three different adjustment factors, respectively, isLeader is a 0/1 variable, which is used to indicate whether the node is the leader node in view v-1, feekmessage indicates the amount of error feedback information received by the node in view v-1,
indicating the average time for the node to communicate feedback with other nodes.
10. The method of claim 1, wherein other nodes in the group in step (9 b) are configured to communicate with the message<RequestVote,v,t,TV v i >The examination was performed as follows:
(9b1) TV for judging nodes sending RequestVote messages v i Whether the value is greater than itself:
if yes, go through checking, carry out step (9 b 2);
otherwise, no information is sent;
(9b2) Judging whether the view number contained in the RequestVote message is consistent with the view number considered by the RequestVote message or not:
if the information is consistent, transmitting RequestVoteResponse information to the leader node and other nodes in the group through checking;
otherwise, no information is sent.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211623691.1A CN116015674A (en) | 2022-12-16 | 2022-12-16 | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211623691.1A CN116015674A (en) | 2022-12-16 | 2022-12-16 | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116015674A true CN116015674A (en) | 2023-04-25 |
Family
ID=86029221
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211623691.1A Pending CN116015674A (en) | 2022-12-16 | 2022-12-16 | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116015674A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210109825A1 (en) * | 2018-08-31 | 2021-04-15 | Advanced New Technologies Co., Ltd. | Transaction consensus processing method and apparatus for blockchain and electronic device |
| CN115051985A (en) * | 2022-04-01 | 2022-09-13 | 重庆邮电大学 | Data consensus method of Byzantine fault-tolerant consensus protocol based on dynamic nodes |
| CN115276999A (en) * | 2022-06-10 | 2022-11-01 | 大连理工大学 | Self-adaptive switching efficient fault-tolerant consensus method based on trust model |
-
2022
- 2022-12-16 CN CN202211623691.1A patent/CN116015674A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210109825A1 (en) * | 2018-08-31 | 2021-04-15 | Advanced New Technologies Co., Ltd. | Transaction consensus processing method and apparatus for blockchain and electronic device |
| CN115051985A (en) * | 2022-04-01 | 2022-09-13 | 重庆邮电大学 | Data consensus method of Byzantine fault-tolerant consensus protocol based on dynamic nodes |
| CN115276999A (en) * | 2022-06-10 | 2022-11-01 | 大连理工大学 | Self-adaptive switching efficient fault-tolerant consensus method based on trust model |
Non-Patent Citations (3)
| Title |
|---|
| THAI Q T 等: "Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems", THE JOURNAL OF SUPERCOMPUTING, 31 December 2019 (2019-12-31) * |
| 任畅 等: "一种量子安全拜占庭容错共识机制", 计算机科学, 7 September 2021 (2021-09-07) * |
| 包振山;王凯旋;张文博;: "基于树形拓扑网络的实用拜占庭容错共识算法", 应用科学学报, no. 01, 30 January 2020 (2020-01-30) * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220385460A1 (en) | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system | |
| CN111371744B (en) | Byzantine fault-tolerant consensus method based on distributed key | |
| US11626993B2 (en) | Network for improved verification speed with tamper resistant data | |
| Douceur | The sybil attack | |
| CN109685505B (en) | Byzantine fault-tolerant consensus optimization method based on association ring signature | |
| CN113642019A (en) | Double-layer grouping Byzantine fault-tolerant consensus method and system | |
| CN110445795B (en) | Block chain authentication uniqueness confirmation method | |
| CN115378604A (en) | Identity authentication method of edge computing terminal equipment based on credit value mechanism | |
| CN110830244A (en) | Anti-quantum computing vehicle networking method and system based on identity secret sharing and alliance chain | |
| CN114463009B (en) | Method for improving transaction security of large-scale energy nodes | |
| CN115051985B (en) | Data consensus method of Bayesian-preemption fault-tolerant consensus protocol based on dynamic nodes | |
| Corman et al. | A Secure Group Agreement (SGA) protocol for peer-to-peer applications | |
| CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
| CN105956490B (en) | A method of it generates in a network environment, safeguard trust data | |
| CN114862397B (en) | Double-decoupling block chain distributed method based on double-chain structure | |
| CN116015674A (en) | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature | |
| CN114826699B (en) | Byzantine attack resisting method in decentralized federal learning based on block chain | |
| CN116527275A (en) | Remote medical agent signature verification method and system | |
| Chen et al. | Scalable byzantine fault tolerant public key authentication for peer-to-peer networks | |
| Zhang et al. | FortunChain: EC-VRF-based scalable blockchain system for realizing state sharding | |
| CN113129001A (en) | Block chain cross-chain and asset hosting oriented quantum attack resistant threshold signature scheme | |
| Kamel et al. | Distributed data validation network in IoT: a decentralized validator selection model | |
| Bonnaire et al. | A scalable architecture for highly reliable certification | |
| Zhang et al. | Secure decentralized learning with blockchain | |
| Chen et al. | An Efficient Byzantine Fault-Tolerant Consensus Mechanism Based on Aggregate Threshold Ring Signature |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |