CN115834579A - Block chain consensus method, device and system and electronic equipment - Google Patents
Block chain consensus method, device and system and electronic equipment Download PDFInfo
- Publication number
- CN115834579A CN115834579A CN202211393272.3A CN202211393272A CN115834579A CN 115834579 A CN115834579 A CN 115834579A CN 202211393272 A CN202211393272 A CN 202211393272A CN 115834579 A CN115834579 A CN 115834579A
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- reputation value
- current
- nodes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a block chain consensus method, a block chain consensus device, a block chain consensus system and electronic equipment, wherein the block chain consensus method comprises the following steps: determining a main node of a consensus unit in the consensus process of the current round; determining whether an updating condition for updating the reputation value of the node is met or not based on a consensus process between the primary node and the secondary node; if the updating condition is met, updating the current reputation value of each node based on the current reputation value, successful consensus times and overtime times of the node; determining the selected probability of the node based on the updated current reputation value of the node; and selecting a new main node based on the selected probability of different nodes, switching to the next consensus unit by using the new main node, and performing the next consensus in the next consensus unit. By adopting the block chain consensus method, the block chain consensus device, the block chain consensus system and the electronic equipment, the problems of large calculated amount and poor election credibility of the main node in the existing consensus algorithm are solved.
Description
Technical Field
The present application relates to the field of blockchain technologies, and in particular, to a method, an apparatus, a system and an electronic device for blockchain consensus.
Background
The block chain system adopts a distributed structure, has a decentralized characteristic, has a plurality of network nodes to record data, and under the condition that a few nodes are malignant, the data among all the nodes need to maintain consistency through a certain mechanism, and punishment is carried out on the malicious nodes in the network, so that the safety of the block chain system is guaranteed, and the consensus algorithm is a core technology of the block chain, namely the data of each node in the block chain is guaranteed to be consistent through a certain algorithm. The consensus algorithm of the current block chain mainly has two modes: one is to compete out the block right through calculation or the number of held coins to prove the transaction validity of the self; the other method is that one or more trusted nodes are selected to broadcast the transaction, the rest nodes are used as following nodes to perform voting, and multiple communications are needed between the secondary node and the main node.
However, in the two consensus algorithms, the first method has a large calculation amount and high requirements on the machine; in the second mode, in the process of voting, signing and electing the master node, the possibility that partial nodes jointly falsify the key parameters of the system with other nodes to forge the signature exists, and the credibility of the master node can also have a certain influence on the safety and efficiency of the system.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a block chain consensus method, apparatus, system and electronic device, so as to solve the problems of large computation amount and poor election credibility of a master node in the conventional consensus algorithm.
In a first aspect, an embodiment of the present application provides a block chain consensus method, applied to a block chain server, including:
determining a main node of a consensus unit in the consensus process of the current round, wherein the consensus unit comprises a plurality of nodes which are divided into the main node and auxiliary nodes, and the consensus unit is used for describing the current state of a multi-auxiliary system;
determining whether an updating condition for updating the node reputation value is met or not based on a consensus process between the main node and the auxiliary node;
if the updating condition is met, updating the current reputation value of each node based on the current reputation value, successful consensus times and overtime times of the node;
determining the selected probability of the node based on the updated current reputation value of the node;
and selecting a new main node based on the selected probability of different nodes, switching to the next consensus unit by using the new main node, and performing the next consensus in the next consensus unit.
Optionally, before determining the master node of the consensus unit in the current round of consensus process, the method further includes: for each node in the consensus unit, distributing a corresponding initial reputation value for the node based on the node information of the node; and selecting the node with the highest initial reputation value in the consensus unit as the initial main node.
Optionally, determining whether an update condition for updating the node reputation value is satisfied comprises: determining whether the current round of consensus process is finished or whether the auxiliary node senses that the main node is in error; and if the current consensus process is finished or the secondary node senses that the primary node makes mistakes, determining that the updating condition for updating the reputation value of the node is met.
Optionally, before updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus and the number of timeout, further comprising: determining values of a successful reward factor and an overtime penalty factor; determining whether the node successfully agrees with other nodes in the current round of agreement process; if the consensus is successfully achieved, adding 1 to the number of successful consensus times of the node; if the node fails to successfully achieve the consensus due to timeout, the number of times of timeout of the node is added by 1.
Optionally, updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus times, and the number of timeout times includes: detecting whether the node has malicious behaviors in the consensus process; if the malicious behavior exists, setting the current credit value of the node to be 0; if no malicious behavior exists, calculating the product of the successful reward factor and the successful consensus times to obtain a successful consensus credit value; calculating the product of the overtime penalty factor and the overtime times to obtain an overtime deduction credit value; and calculating the sum of the current reputation value and the successful consensus reputation value of the node, and taking the difference between the sum and the overtime deduction reputation value as the updated current reputation value of the node.
Optionally, determining the selected probability of the node based on the updated current reputation value of the node includes: calculating the sum of the updated current reputation values of all nodes; and taking the ratio of the updated current reputation value of the node to the sum of the updated current reputation values of all nodes as the selected probability of the node.
Optionally, electing a new master node based on the selected probabilities of the different nodes, including: and arranging the selected probabilities of different nodes in a descending order, and taking the node corresponding to the selected probability with the first rank as a new main node.
In a second aspect, an embodiment of the present application further provides a block chain consensus apparatus, where the apparatus includes:
the system comprises a main node determining module, a joint recognizing unit and a judging module, wherein the main node determining module is used for determining a main node of the joint recognizing unit in the process of the joint recognizing, the joint recognizing unit comprises a plurality of nodes, the plurality of nodes are divided into a main node and an auxiliary node, and the joint recognizing unit is used for describing the current state of a multi-auxiliary system;
the updating condition determining module is used for determining whether the updating condition of the reputation value of the updating node is met or not based on the consensus process between the main node and the auxiliary node;
the reputation value calculation module is used for updating the current reputation value of each node based on the current reputation value, the successful consensus times and the overtime times of the node if the update conditions are met;
the probability calculation module is used for determining the selected probability of the node based on the updated current reputation value of the node;
and the unit updating module is used for selecting a new main node based on the selected probability of different nodes, switching to the next consensus unit by using the new main node, and performing the next consensus in the next consensus unit.
In a third aspect, an embodiment of the present application further provides a block chain consensus system, where the system includes: the system comprises a block chain server and a consensus unit, wherein the consensus unit comprises a plurality of nodes, and the plurality of nodes are divided into a main node and a secondary node;
the block chain server executes the block chain consensus method;
the main node of the consensus unit receives the voting signature sent by the secondary node to generate new block information, and sends the new block information to the secondary node;
and the secondary node verifies the new block information by using a multiple signature algorithm, and if the verification is passed, the secondary node identifies the data in the new block information.
In a fourth aspect, an embodiment of the present application further provides an electronic device, including: a processor, a memory and a bus, the memory storing machine-readable instructions executable by the processor, the processor and the memory communicating via the bus when the electronic device is operating, the machine-readable instructions when executed by the processor performing the steps of the block chain consensus method as described above.
The embodiment of the application brings the following beneficial effects:
according to the block chain consensus method, the block chain consensus device, the block chain consensus system and the electronic equipment, whether the reputation value of each node is updated or not can be determined by the block chain server, the current reputation value of each node is determined according to the initial reputation value, the successful consensus times and the overtime times of the node, a new main node is elected based on the election probability corresponding to the current reputation value, and accordingly the new main node is elected by the block chain server based on the current reputation values of different nodes without competing for the block weight through the calculation power or the number of held coins, the election credibility and the consensus efficiency of the main node are improved.
In order to make the aforementioned objects, features and advantages of the present application comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
To more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a flowchart illustrating a block chain consensus method provided by an embodiment of the present application;
fig. 2 is a schematic structural diagram illustrating a blockchain consensus apparatus according to an embodiment of the present disclosure;
fig. 3 is a schematic structural diagram illustrating a blockchain consensus system according to an embodiment of the present disclosure;
fig. 4 shows a schematic structural diagram of an electronic device provided in an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. Every other embodiment that one skilled in the art can obtain without inventive effort based on the embodiments of the present application falls within the scope of protection of the present application.
It should be noted that, before the present application is proposed, the blockchain system adopts a distributed structure, has a decentralized characteristic, has a plurality of network nodes to record data, and when there are a few nodes doing malicious activities, the data between all nodes needs to maintain consistency through a certain mechanism, and penalizes the malicious nodes existing in the network, thereby ensuring the security of the blockchain system. The consensus algorithm of the current block chain mainly has two modes: one is to compete out the block right through calculation or the number of held coins to prove the transaction validity of the self; the other method is that one or more trusted nodes are selected to broadcast the transaction, the rest nodes are used as following nodes to perform voting, and multiple communications are needed between the secondary node and the main node. However, in the two consensus algorithms, the first method has a large calculation amount and high requirements on the machine; in the second mode, in the process of voting, signing and electing the master node, the possibility that partial nodes jointly falsify the key parameters of the system with other nodes to forge the signature exists, and the credibility of the master node can also have a certain influence on the safety and efficiency of the system.
Based on this, the embodiments of the present application provide a block chain consensus method to improve the consensus efficiency and the election credibility of the master node.
Referring to fig. 1, fig. 1 is a flowchart illustrating a block chain consensus method according to an embodiment of the present disclosure. As shown in fig. 1, the block chain consensus method provided in the embodiment of the present application is applied to a block chain server, and includes:
and step S101, determining a main node of the consensus unit in the current consensus process.
In this step, the consensus unit may refer to view, and the consensus process is composed of views one after another. The consensus unit corresponding to the current consensus process can also be referred to as a current consensus unit.
The consensus unit comprises a plurality of nodes which are divided into a main node and a secondary node, and is used for describing the current state of the multi-copy system. In addition, a plurality of nodes share data on the same view, and cannot share data across views.
In a consensus unit, a certain main node exists, the main node dominates the consensus protocol, consensus is achieved through voting in several stages, and then switching is carried out to the next consensus unit to continue consensus.
In the embodiment of the application, when the block chain is initialized and started, all nodes in the block chain are in a state of participating in election of the main node, a certain credit value is allocated to each node at the moment, and the initial main node in the first round of consensus process is selected according to the credit value. And if the main node is selected for a certain round of consensus after the first round of consensus process, determining the main node of the round of consensus according to the selected probability of each node. Wherein a blockchain refers to a federation blockchain.
In an optional embodiment, before determining the master node of the consensus unit in the current round of consensus process, the method further includes: for each node in the consensus unit, distributing a corresponding initial reputation value for the node based on the node information of the node; and selecting the node with the highest initial reputation value in the consensus unit as an initial main node.
Specifically, when a node joins a blockchain network, initial reputation value allocation is performed according to information provided when the node actually registers a blockchain, for example: and distributing the initial credit value according to the computer configuration parameters when the node registers the block chain, wherein the higher the computer configuration parameters are, the larger the initial credit value distributed to the node is, and the lower the computer configuration parameters are, the lower the initial credit value distributed to the node is.
During the first round of consensus, the initial main node can be directly selected according to the initial reputation value of each network access node, and the node with the highest initial reputation value is used as the initial main node.
And step S102, determining whether the updating condition of the reputation value of the updating node is met or not based on the consensus process between the main node and the auxiliary node.
In this step, the consensus process may refer to a pipelined consensus process, which is similar to the HotStuff algorithm, but different in the master node selection method and the vote signature algorithm used each time.
The update condition may refer to a condition of whether to update the reputation value of the node, and the update condition is used to determine whether to update the reputation value of the node.
A flow type consensus process is adopted between the main node and the auxiliary node, and the flow type consensus process is described in detail in the following content, which is not described herein again.
In an alternative embodiment, determining whether an update condition for updating the node reputation value is satisfied comprises: determining whether the current round of consensus process is finished or whether the auxiliary node senses that the main node is in error; and if the current consensus process is finished or the secondary node senses that the primary node makes mistakes, determining that the updating condition for updating the reputation value of the node is met.
Specifically, in the current round of consensus process, two situations may occur, one is that the consensus process is ended due to the agreement between the primary node and the secondary node, and the other is that the consensus process is over time due to the error of the primary node, so that the reputation value of each node needs to be updated when the situations occur, so as to use the updated reputation value to select the primary node in the next round of consensus process.
Therefore, whether the process of the consensus in the current round is finished and whether the auxiliary node senses that the main node has an error are taken as updating conditions, and as long as one of the two conditions occurs, the credit value of each node is updated to ensure the accuracy of the main node of the consensus in the next round. Wherein, the end of the consensus process means that after undergoing a preparation stage, a pre-submission stage, a submission stage and a decision stage of the consensus process, all nodes correspond to a recognized block chain, and the updating of chain data on the block chain indicates that the consensus process of the round is ended; the secondary node senses that the primary node has errors, namely that when the secondary node performs signature verification on the primary node message, the signature verification is incorrect or the primary node message is waited for overtime.
And step S103, if the updating condition is met, updating the current reputation value of each node based on the current reputation value of the node, the successful consensus times and the overtime times.
In this step, assuming that the current round of consensus process is round a consensus, and the current reputation value of the node a is 10 before determining whether the update condition is satisfied, if the server determines that the update condition of the node reputation value is satisfied, the server updates the current reputation value of the node a by using the current reputation value 10, the number of successful consensus times, and the number of timeout times, and enumerates the master node in round a +1 based on the updated current reputation value of the node a and the updated current reputation value of the other node.
In an optional embodiment, before updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus times, and the number of time-outs, further comprising: determining values of a successful reward factor and an overtime penalty factor; determining whether the node successfully agrees with other nodes in the current round of agreement process; if the consensus is successfully achieved, adding 1 to the number of successful consensus times of the node; if the node fails to successfully achieve the consensus due to timeout, the number of times of timeout of the node is added by 1.
Here, the successful reward factor may refer to a reputation value reward coefficient given for successful consensus achievement, and the successful reward factor is used to improve the reputation value of the node which successfully achieves consensus.
The timeout penalty factor may refer to a credit penalty factor given by unsuccessful agreement of consensus, and is used to reduce the credit value of the node that did not successfully agree.
Specifically, before updating the current reputation value of a node, values of two parameters are determined, where the two parameters are a successful reward factor and a timeout penalty factor, and the larger the successful reward factor is, the higher the reward for the reputation value brought by achieving consensus is, the larger the timeout penalty factor is, the higher the penalty for the reputation value brought by failing to achieve consensus is, and the values of the two parameters are both set values. For each node in the consensus unit, if the node successfully achieves consensus in a certain cycle of consensus process, accumulating the successful consensus times of the node by 1; if the node fails to successfully participate in the consensus due to overtime in a certain consensus process, the overtime times of the node are added by 1 in an accumulated mode, and therefore the successful consensus times or the overtime times of the node are changed no matter whether the node successfully achieves the consensus or not, so that the performance of the node in one consensus process is represented.
When a node joins the blockchain network, the successful consensus times and the timeout times of the node are initialized, that is, both are set to 0.
In an alternative embodiment, updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus occurrences, and the number of time-outs includes: detecting whether the node has malicious behaviors in the consensus process; if malicious behaviors exist, setting the current reputation value of the node to be 0; if no malicious behavior exists, calculating the product of the successful reward factor and the successful consensus times to obtain a successful consensus credit value; calculating the product of the overtime penalty factor and the overtime times to obtain an overtime deduction credit value; and calculating the sum of the current reputation value and the successful consensus reputation value of the node, and taking the difference between the sum and the overtime deduction reputation value as the updated current reputation value of the node.
Specifically, in a round of consensus process, whether each node has a malicious behavior needs to be detected in real time, if a node has a malicious behavior, the current reputation value of the node is set to 0, the node is rejected to participate in the subsequent consensus process, and the node does not have the right of selecting a master node and cannot be elected as the master node. If no malicious behavior exists, updating the current reputation value of the node according to the following formula:
C i_2 ＝C i_1 +αSucc i -βOve i ；
in the above formula, C i_2 Represents the updated current reputation value, C, of the ith node i_1 Representing the current reputation value of the ith node before updating, alpha representing a successful reward factor, beta representing a timeout penalty factor, succ i Indicates the number of successful consensus, ove i Indicating the number of timeouts.
Wherein, the malicious behavior refers to that the node has malicious attack behavior, such as: the tampered information or node receives the correct ciphertext message but declares it to be an error ciphertext message.
And step S104, determining the selected probability of the node based on the updated current reputation value of the node.
In this step, the selection probability may refer to the probability of being selected as the master node, the higher the selection probability is, the higher the probability of being selected as the master node is, and the lower the selection probability is, the lower the probability of being selected as the master node is.
In the embodiment of the application, each node corresponds to an updated current reputation value, the selection probability of the node can be determined according to the updated current reputation value of each node, and a new master node is selected according to the selection probability corresponding to each node.
In an optional embodiment, determining the probability of being selected of the node based on the updated current reputation value of the node comprises: calculating the sum of the updated current reputation values of all nodes; and taking the ratio of the updated current reputation value of the node to the sum of the updated current reputation values of all nodes as the selected probability of the node.
Specifically, the sum of the updated current reputation values of all the nodes is calculated, the quotient of the updated current reputation value of the ith node and the sum of the updated current reputation values of all the nodes is used as the selection probability of the ith node, and the selection probability can be calculated according to the following formula:
in the above formula, C i_2 Represents the updated current reputation value, P, of the ith node i Representing the probability of being selected for the ith node.
Step S105, selecting a new main node based on the selected probability of different nodes, switching to the next consensus unit by using the new main node, and performing the next consensus in the next consensus unit.
In this step, the current consensus unit corresponds to the current consensus process, and assuming that a node a in the current consensus unit is a master node, after determining the selection probability of each node, the blockchain server selects a new master node according to the multiple selection probabilities of different nodes, and assuming that a selected node b is a new master node, the new master node b is used to generate a next consensus unit, and a new round of consensus is performed in the next consensus unit. The node inside the next recognition unit is not changed, but only the master node of the next recognition unit and the master node of the current recognition unit are changed.
In addition, each consensus unit has its own number, and assuming that the current consensus unit number is 9, the next consensus unit number is 9+1=10.
In an alternative embodiment, electing a new master node based on the selected probabilities of the different nodes includes: and arranging the selected probabilities of different nodes in a descending order, and taking the node corresponding to the selected probability with the first ranking as a new master node.
Specifically, if there are 50 nodes, the 50 nodes correspond to 50 selection probabilities, the selection probabilities are arranged in descending order, and if the first selection probability is the selection probability of the node b, the node b is used as a new master node, that is, the master node of the next common identification unit.
In a preferred example, the selection probabilities of different nodes may be arranged in a descending order, nodes corresponding to a set number of top-ranked selection probabilities are used as candidate master nodes, and a node is randomly selected from the candidate master nodes as a new master node according to the selection probability.
Compared with the block chain consensus method in the prior art, the method and the device have the advantages that whether the credit value of each node is updated or not can be determined by the block chain server, the current credit value of each node is determined according to the initial credit value of the node, the successful consensus times and the overtime times, the new main node is elected based on the corresponding election probability of the current credit value, and accordingly, the new main node is elected by the block chain server based on the current credit values of different nodes without competing for the block weight through the calculation power or the number of held coins, the election credibility and the consensus efficiency of the main node are improved, and the problems that in the existing consensus algorithm, the calculation amount is large and the election credibility of the main node is poor are solved.
Based on the same inventive concept, the embodiment of the present application further provides a block chain consensus method, and as the principle of solving the problem of the apparatus in the embodiment of the present application is similar to that of the block chain consensus method described above, the method may be used for implementing the apparatus, and the repeated parts are not described again.
Referring to fig. 2, fig. 2 is a schematic structural diagram of a block chain consensus device according to an embodiment of the present application. As shown in fig. 2, the blockchain consensus apparatus 200 includes:
a master node determining module 201, configured to determine a master node of a consensus unit in a current round of consensus, where the consensus unit includes multiple nodes, the multiple nodes are divided into a master node and a slave node, and the consensus unit is used to describe a current state of a multi-duplicate system;
an update condition determining module 202, configured to determine whether an update condition for updating the node reputation value is satisfied based on a consensus process between the primary node and the secondary node;
the reputation value calculating module 203 is configured to, for each node, update the current reputation value of the node based on the current reputation value of the node, the number of successful consensus times, and the number of timeout times if the update condition is satisfied;
a probability calculation module 204, configured to determine, based on the updated current reputation value of the node, a selected probability of the node;
a unit updating module 205, configured to select a new master node based on the selected probabilities of different nodes, switch to a next consensus unit by using the new master node, and perform a next round of consensus in the next consensus unit.
Referring to fig. 3, fig. 3 is a schematic structural diagram of a block chain consensus system according to an embodiment of the present application. As shown in fig. 3, the blockchain consensus system 300 includes: a blockchain server 310 and a consensus unit 320, wherein the consensus unit 320 comprises a plurality of nodes, and the plurality of nodes are divided into a primary node and a secondary node;
the blockchain server 310 performs the blockchain consensus method;
the master node of the consensus unit 320 receives the voting signature sent by the secondary node to generate new block information, and sends the new block information to the secondary node;
and the secondary node verifies the new block information by using a multiple signature algorithm, and if the verification is passed, the secondary node performs consensus on the data in the new block information.
The following describes the consensus process between nodes in detail.
The body process of the consensus process is similar to the hot stuff algorithm, but differs in the algorithm by which the master node (leader node) picks and signs the vote each time it is used.
The consensus process is pipelined, each message is a proxy, the proxy includes newly generated new block information and QC (certificate), wherein the QC includes a signature generated by combining messages sent from more than 2/3 nodes received at each stage by a leader node through a multiple signature algorithm, a hash value of a new block, and a number of a current consensus unit, the proxy can be understood as a transaction or a proposal, the QC can be understood as achieving a consensus for the transaction or the proposal, the hash value of the new block is calculated according to an attribute of the new block, and the hash value algorithm of the new block is not described herein in detail as belonging to the prior art.
The following two situations can both result in the end of the current consensus process and then switch to the next consensus process, one is the consensus achieved in the current round, and the other is the error of the master node. Once a new master node is elected and merged into the preparation phase, it indicates that a switch to the next round of consensus process has been made.
Each round of consensus process is divided into four stages, preparation, pre-submission, submission and decision, and each stage is described below.
When the consensus unit is switched, the server informs each node of the master node of the consensus unit after switching, and each node sends a New-view message to the master node.
The first stage is as follows: a preparation phase (prepare phase).
The preparation phase begins with the master node receiving more than 2/3 of the New-view messages (including the master node itself), each of which contains the latest preparation-QC (signature certificate of the preparation phase).
And the main node selects the QC with the largest consensus unit number from the prepare-QC as a high-QC and generates a corresponding new block.
And the main node broadcasts the proxy message containing the new block information to the auxiliary node, the auxiliary node verifies the proxy message according to the multiple signature algorithm after receiving the proxy message, determines whether the proxy message is correct, and generates a prefix-volume message by signature if the proxy message is correct and returns the prefix-volume message to the main node.
And a second stage: the pre-commit phase (presimit phase).
After receiving the prefix-vote message of more than 2/3 nodes, the main node indicates that enough nodes confirm the state transition request, the main node serves as a verifier to verify whether the signature is valid, if so, the prefix-vote is aggregated into a prefix-QC to generate a prefix message, and the prefix message is broadcast to the secondary node. Wherein the presommit message is attached with the prefix-QC.
And after receiving the presimit message, the secondary node verifies the presimit message according to a multiple signature algorithm, verifies whether the presimit message is correct, and if the presimit message is correct, signs to generate a presimit-vote message and returns the presimit-vote message to the primary node.
And a third stage: commit phase (commit phase).
Similar to the commit stage, after receiving the commit-vote message of more than 2/3 nodes, the main node verifies whether the signature in the commit-vote message is valid, aggregates the commit-vote into a commit-QC to generate a commit message if the signature in the commit-vote message is valid, and broadcasts the commit message to the secondary node. Wherein the commit message is appended with prescommit-QC.
And after receiving the commit message, the secondary node verifies whether the commit message is correct according to a multiple signature algorithm, and if the commit message is correct, the signature generates a commit-vote which is returned to the main node.
Meanwhile, the auxiliary node updates the lock-QC state corresponding to the other locked new blocks to presommit-QC, and the operation of the pipeline is kept. Here, it is possible that the consensus process of a plurality of blocks goes to the commit stage, but the current secondary node can only agree on the QC corresponding to 1 block, and the QCs of other blocks are all in the locked state.
A fourth stage: a decision stage (decide stage).
And after receiving the commit-vote message of more than 2/3 nodes, the master node verifies whether the signature in the commit-vote message is valid, if so, the signature is aggregated into commit-QC, a delete message is generated, and the delete message is broadcast to the secondary node. Wherein, the decide message is accompanied by commit-QC.
And after receiving the decide message, the secondary node confirms the validity and executes the requirements in the block, namely the secondary node executes the transaction in the proposal pointed by commit-QC.
And increasing the number of the common identification unit by 1 to obtain the number of the next common identification unit, and starting the next round of common identification unit. And meanwhile, updating the successful consensus times and the overtime times, determining the current credit value of each node, then selecting the node with the highest selected probability as a New main node, and sending a New-view message to the New main node by each secondary node to complete the replacement of the consensus unit.
The multiple signature algorithm is explained below.
The multiple signature algorithm is a MuSig2 signature algorithm, and the multiple signature algorithm ensures the validity and the non-tamper property of the signature through two rounds of communication.
Firstly, signature parameters are selected:
the signature parameters include: group parameters, hash function H _ agg, hash function H _ non, hash function H _ sig. Wherein the group parameters include: G. p, G, v, m and n, wherein G represents a p-order cyclic group, p represents a lambda bit prime number, G represents a generator of G, v represents the logarithm of a random public and private key required to be generated by each node in the signature, m is a message to be signed, namely data to be identified, and n is the number of nodes participating in identification. The value of v may be selected according to actual situations, and a larger value of v indicates that the more the number of pairs of the random public and private keys that need to be generated, the higher the security is, but the lower the calculation efficiency is, whereas a smaller value of v indicates that the fewer the number of pairs of the random public and private keys that need to be generated, the lower the security is, but the higher the calculation efficiency is.
Wherein the domain-to-value ranges of the three hash functions are from [0,1 ]]* To Z p The H _ agg function is used to generate an aggregate public key, the H _ non function is used to aggregate the generated multiple nonce pairs, and the H _ sig function is used for the final signature. Illustratively, the hash function may be MD5The function may be a sha256 function.
And secondly, generating a key:
each signer generates a random private key x, the formula being x ← $ Z p And obtaining a public key X corresponding to the random private key X, wherein X = g x 。
Thirdly, aggregating public keys:
first, with L = { X 1 ,X 2 ,…,X n Denotes a set of respective public keys obtained by the n signature nodes in the previous step, for the public key X i e.L, and the polymerized public key can be obtained by the following formula
a i ＝H agg (L，X i )；
In the above formula, a i Is the aggregate coefficient of the ith node.
Step four, first round signature:
each signer node is according to the formula r for j ∈ {1, \8230;, v } (v denotes the logarithm of the random public and private key in the group parameter, j denotes the several public and private key pairs) 1,j ←$Z p Generating a random private key r 1,j ，r 1,j The jth random private key representing node number 1.
Calculated according to the following formula 1,1 ,…,R 1,v ) And will be (R) 1,1 ,…,R 1,v ) Sending the data to the main node, and performing similar calculation on the other nodes to obtain (R) 2,1 ,…,R 2,v ),…,(R n,1 ,…,R n,v ) And sending to the master node. Wherein, the calculation formula is:
the master node receives the signals sent by other nodes (R) i,1 ,…,R i,v ) Time calculation of R j Obtaining (R) 1 ,R 2 ,…,R v ) And will be (R) 1 ,R 2 ,…,R v ) Broadcast to all signers. Wherein R is j The calculation formula of (a) is as follows:
wherein i belongs to {1, \8230;, n }, j belongs to {1, \8230;, v }.
Step five, second round signature:
obtained from the first round of signatures 1 ,R 2 ,…,R v ) And aggregated public key
Calculating signature information s by the following formula 1 ：
In the above formula, m is a parameter in the group parameter, representing the information to be signed, a 1 Denotes an aggregation coefficient of node number 1, p is a parameter in the group parameter, denotes a prime number of λ bits, x 1 Is the private key of the signer.
Obtaining signature information s 1 Then, s is 1 Broadcast to other nodes, and other nodes perform the same operation. The master node receives itSignature information(s) returned by other node 2 ,…,s n ) Then, the main node calculates the signature by using the signature information of each node
Wherein, the calculation formula of s is as follows:
sixthly, verifying:
verifier according to given aggregated public key
Message m and signature
If it is
Then the signature is certified
Valid returns true, otherwise false is returned. The verifier may be a master node or a slave node.
Referring to fig. 4, fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. As shown in fig. 4, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.
The memory 420 stores machine-readable instructions executable by the processor 410, when the electronic device 400 runs, the processor 410 communicates with the memory 420 through the bus 430, and when the machine-readable instructions are executed by the processor 410, the steps of the block chain consensus method in the embodiment of the method shown in fig. 1 may be performed.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such understanding, the technical solutions of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.
Finally, it should be noted that: the above-mentioned embodiments are only specific embodiments of the present application, and are used to illustrate the technical solutions of the present application, but not to limit the technical solutions, and the scope of the present application is not limited to the above-mentioned embodiments, although the present application is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: any person skilled in the art can modify or easily conceive the technical solutions described in the foregoing embodiments or equivalent substitutes for some technical features within the technical scope disclosed in the present application; such modifications, changes or substitutions do not depart from the spirit and scope of the exemplary embodiments of the present application, and are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (10)
1. A block chain consensus method is applied to a block chain server, and the method comprises the following steps:
determining a main node of a consensus unit in the consensus process of the current round, wherein the consensus unit comprises a plurality of nodes which are divided into the main node and auxiliary nodes, and the consensus unit is used for describing the current state of a multi-copy system;
determining whether an update condition for updating the node reputation value is satisfied based on a consensus process between the primary node and the secondary node;
if the updating condition is met, updating the current reputation value of each node based on the current reputation value, successful consensus times and overtime times of the node;
determining the selected probability of the node based on the updated current reputation value of the node;
and selecting a new main node based on the selected probability of different nodes, switching to a next consensus unit by using the new main node, and performing next consensus in the next consensus unit.
2. The method of claim 1, wherein prior to determining the master node of the consensus unit in the current round of consensus, further comprising:
for each node in the consensus unit, distributing a corresponding initial reputation value to the node based on the node information of the node;
and selecting the node with the highest initial reputation value in the consensus unit as an initial main node.
3. The method of claim 1, wherein determining whether an update condition for updating the node reputation value is satisfied comprises:
determining whether the current round of consensus process is finished or whether the auxiliary node senses that the main node makes mistakes;
and if the current consensus process is finished or the secondary node senses that the primary node makes mistakes, determining that the updating condition for updating the reputation value of the node is met.
4. The method of claim 1, wherein prior to the updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus occurrences, and the number of timeouts, further comprising:
determining values of a successful reward factor and an overtime penalty factor;
determining whether the node successfully agrees with other nodes in the current round of agreement process;
if the consensus is successfully achieved, adding 1 to the number of successful consensus times of the node;
if the node fails to achieve consensus due to timeout, the number of times of timeout of the node is added by 1.
5. The method of claim 4, wherein updating the current reputation value of the node based on the current reputation value of the node, the number of successful consensus, and the number of timeouts comprises:
detecting whether the node has malicious behaviors in the consensus process;
if the malicious behavior exists, setting the current credit value of the node to be 0;
if the malicious behavior does not exist, calculating the product of the successful reward factor and the successful consensus times to obtain a successful consensus credit value;
calculating the product of the overtime penalty factor and the overtime times to obtain an overtime deduction credit value;
and calculating the sum of the current reputation value and the successful consensus reputation value of the node, and taking the difference between the sum and the overtime deduction reputation value as the updated current reputation value of the node.
6. The method of claim 1, wherein determining the probability of being selected for the node based on the updated current reputation value for the node comprises:
calculating the sum of the updated current reputation values of all nodes;
and taking the ratio of the updated current reputation value of the node to the sum of the updated current reputation values of all nodes as the selected probability of the node.
7. The method of claim 1, wherein electing a new master node based on the selected probabilities of the different nodes comprises:
and arranging the selected probabilities of different nodes in a descending order, and taking the node corresponding to the selected probability with the first rank as a new main node.
8. A blockchain consensus apparatus, comprising:
the system comprises a main node determining module, a joint recognizing unit and a judging module, wherein the main node determining module is used for determining a main node of the joint recognizing unit in the process of the joint recognizing in the current round, the joint recognizing unit comprises a plurality of nodes, the plurality of nodes are divided into a main node and an auxiliary node, and the joint recognizing unit is used for describing the current state of a multi-auxiliary system;
the updating condition determining module is used for determining whether an updating condition for updating the node reputation value is met or not based on a consensus process between the main node and the auxiliary node;
the reputation value calculation module is used for updating the current reputation value of each node based on the current reputation value, successful consensus times and overtime times of the node if the update condition is met;
the probability calculation module is used for determining the selected probability of the node based on the updated current reputation value of the node;
and the unit updating module is used for electing a new main node based on the selected probability of different nodes, switching to the next consensus unit by using the new main node, and performing the next consensus in the next consensus unit.
9. A blockchain consensus system, the system comprising: the system comprises a block chain server and a consensus unit, wherein the consensus unit comprises a plurality of nodes which are divided into a main node and a secondary node;
the blockchain server performing the blockchain consensus method as claimed in any one of claims 1 to 7;
the main node of the consensus unit receives the voting signature sent by the secondary node to generate new block information, and sends the new block information to the secondary node;
and the secondary node verifies the new block information by using a multiple signature algorithm, and if the verification is passed, the secondary node performs consensus on the data in the new block information.
10. An electronic device, comprising: a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating via the bus when an electronic device is operating, the processor executing the machine-readable instructions to perform the steps of the block chain consensus method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211393272.3A CN115834579A (en) | 2022-11-08 | 2022-11-08 | Block chain consensus method, device and system and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211393272.3A CN115834579A (en) | 2022-11-08 | 2022-11-08 | Block chain consensus method, device and system and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115834579A true CN115834579A (en) | 2023-03-21 |
Family
ID=85527228
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211393272.3A Pending CN115834579A (en) | 2022-11-08 | 2022-11-08 | Block chain consensus method, device and system and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115834579A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117527834A (en) * | 2024-01-04 | 2024-02-06 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
| CN117527266A (en) * | 2024-01-05 | 2024-02-06 | 杭州趣链科技有限公司 | Asynchronous network consensus method, device, electronic equipment and readable storage medium |
-
2022
- 2022-11-08 CN CN202211393272.3A patent/CN115834579A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117527834A (en) * | 2024-01-04 | 2024-02-06 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
| CN117527834B (en) * | 2024-01-04 | 2024-03-26 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
| CN117527266A (en) * | 2024-01-05 | 2024-02-06 | 杭州趣链科技有限公司 | Asynchronous network consensus method, device, electronic equipment and readable storage medium |
| CN117527266B (en) * | 2024-01-05 | 2024-05-17 | 杭州趣链科技有限公司 | Asynchronous network consensus method, device, electronic equipment and readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112039964B (en) | Node reputation consensus method based on block chain | |
| CN115834579A (en) | Block chain consensus method, device and system and electronic equipment | |
| WO2020069411A1 (en) | High throughput blockchain consensus systems and methods with low finalization time | |
| CN114422155B (en) | Proposal consensus execution method, block chain system, device and storage medium | |
| CN113660125B (en) | Consensus method and device based on random trusted committee | |
| EP3777018A1 (en) | Technique for computing a block in a blockchain network | |
| CN111817855B (en) | Electronic voting method and system based on Ether house block chain | |
| US20220278854A1 (en) | Unity Protocol Consensus | |
| CN111478772A (en) | Assembly line friendly signature and signature verification method, device and storage medium | |
| CN109919760A (en) | Byzantine failure tolerance common recognition algorithm based on voting mechanism | |
| CN115549931B (en) | Byzantine fault tolerance implementation method and system based on mimicry defense | |
| CN114338715A (en) | Data synchronization method, block chain system, terminal device and storage medium | |
| CN113132401A (en) | Data processing method and device based on block chain | |
| CN115225639B (en) | Changing method and device for consensus trusted cluster, computer equipment and medium | |
| CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
| CN111669267B (en) | Configuration method for consensus mechanism and endorsement strategy of block chain | |
| CN114615281B (en) | Block chaining and block outputting method based on small-scale committee and PoS protocol confirmation method | |
| CN114140233B (en) | Method and device for safely converting cross-slice view of slice block chain | |
| CN114422146B (en) | Method for anonymously sequencing main nodes of blockchain | |
| CN115378598A (en) | Multi-chain extensible secret election method based on disposable linkable ring signatures | |
| CN114077637B (en) | Method for implementing block chain of fragments | |
| Zhang et al. | Scalable and fault-tolerant selection method of verification and accounting nodes for permissionless blockchain | |
| CN117978547B (en) | TRP-PBFT consensus method, system, storage medium and equipment | |
| CN114466034B (en) | Block chain consensus method based on anonymous main node | |
| CN117527266B (en) | Asynchronous network consensus method, device, electronic equipment and readable storage medium |
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 |