CN112035886B - Block chain consensus method, device, consensus node, system and storage medium - Google Patents
Block chain consensus method, device, consensus node, system and storage medium Download PDFInfo
- Publication number
- CN112035886B CN112035886B CN202010901332.2A CN202010901332A CN112035886B CN 112035886 B CN112035886 B CN 112035886B CN 202010901332 A CN202010901332 A CN 202010901332A CN 112035886 B CN112035886 B CN 112035886B
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- nodes
- block chain
- check
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Accounting & Taxation (AREA)
- Economics (AREA)
- General Business, Economics & Management (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Development Economics (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Retry When Errors Occur (AREA)
Abstract
The embodiment of the application provides a block chain consensus method, a block chain consensus device, a block chain consensus node, a block chain consensus system and a storage medium, wherein block data is verified to generate a plurality of pieces of first verification information, a plurality of pieces of second verification information sent by other consensus nodes in a normal state are received, the second verification information is obtained by verifying the block data, and the block data is added to the block chain according to the plurality of pieces of first verification information and the plurality of pieces of second verification information. According to the scheme, each common identification node in the normal state generates a plurality of pieces of verification information, the common identification node in the normal state can receive enough verification information under the condition that the common identification node in the fault state exists, and whether block data are added into a block chain or not can be determined according to the received information.
Description
Technical Field
The embodiment of the present application relates to the technical field of financial technology (Fintech) and blockchain, and in particular, to a method, an apparatus, a node, a system, and a storage medium for consensus of blockchain.
Background
A block chain (Blockchain) is a decentralized distributed account book system, a consensus mechanism is used as a part of a block chain technology, the latest block can be accurately added to the block chain, block chain information stored by nodes is consistent and not forked, and even malicious attacks can be resisted.
In the prior art, after the verification of a new block is completed, the consensus node in the block chain network verifies the generated new block, and each consensus node needs to broadcast the verification result to other consensus nodes in the block chain network, and after receiving the verification results of the other consensus nodes, each consensus node can determine the validity of the new block. When there are too many fault common-identification nodes in the block chain network, the success rate of achieving common identification is reduced, and the common-identification efficiency of the block chain is low. When the above problems are met, the prior art generally rebuilds the consensus node or rebuilds the blockchain according to the data or blockchain of the consensus node which is backed up.
However, the recovery time is long by reconstructing the consensus node or reconstructing the block chain.
Disclosure of Invention
The embodiment of the application provides a block chain consensus method, a block chain consensus device, a block chain consensus node, a block chain consensus system and a storage medium, so as to improve the success rate of consensus achieved when a fault consensus node exists.
In a first aspect, the present application provides a block chain consensus method, including:
verifying the block data to generate a plurality of pieces of first verification information, wherein the block data is generated by packaging transaction data;
receiving a plurality of second check messages sent by other common identification nodes in a normal state, wherein the second check messages are obtained by checking the block data;
and adding the block data into the block chain according to the plurality of first check information and the plurality of second check information.
Optionally, verifying the block data to generate a plurality of pieces of first verification information specifically includes:
checking the block data to obtain a checking result;
encrypting the verification results by using a plurality of private keys respectively to generate a plurality of first verification information;
each private key is used for encrypting the verification result to generate first verification information.
Optionally, after encrypting the verification result with a plurality of private keys respectively to generate a plurality of first verification information, the method further includes:
and adding a node identifier corresponding to the private key in each piece of first check information so that other common nodes decrypt the first check information by using the node identifiers.
Optionally, adding the block data to the block chain according to the plurality of first check information and the plurality of second check information, specifically including:
when the plurality of first check information and the plurality of second check information meet a first preset condition, sending a plurality of first submission requests to each other consensus node;
receiving a plurality of second submission requests sent by each other consensus node;
the block data is added to the block chain according to the first plurality of commit requests and the second plurality of commit requests.
Optionally, adding the block data to the block chain according to the first submission requests and the second submission requests includes:
when the ratio of the third consensus number to the total number of all consensus nodes in the blockchain reaches (2f + 1)/(3f + 1), adding the blockchain to the blockchain;
wherein the third consensus number is a sum of the number of first commit requests and the number of second commit requests.
Optionally, the plurality of first check information and the plurality of second check information satisfy a first preset condition, which specifically includes:
the ratio of the first consensus quantity to the total number of all consensus nodes in the block chain reaches (2f + 1)/(3f + 1);
the first consensus number is the sum of a second consensus number and the first check information, the second consensus number is obtained by counting second check information which is the same as the first check information, and f is a positive integer.
Optionally, the ratio between the number of other common nodes in the normal state and the total number of all nodes in the block chain is less than or equal to (2f + 1)/(3f + 1), where f is a positive integer.
Optionally, the number of the second check information generated by each other consensus node is the same as the number of the first check information generated by the consensus node.
Optionally, the amount of the first verification information conforms to the following formula:
wherein k represents the number of the first check information, x represents the number of the consensus nodes in the normal state, (3f + 1) is the total number of all the consensus nodes in the block chain, and k, f and x are positive integers.
In a second aspect, the present application provides an apparatus for block chain consensus, including:
the processing module is used for verifying the block data to generate a plurality of pieces of first verification information, wherein the block data is generated by packaging and processing the transaction data;
the receiving module is used for receiving a plurality of second check messages sent by other common nodes in a normal state, wherein the second check messages are obtained by checking the block data;
the processing module is further configured to add the block data to the block chain according to the plurality of first parity information and the plurality of second parity information.
In a third aspect, the present application provides a consensus node, including:
a memory for storing a program;
a processor for executing a program stored in the memory, the processor being adapted to perform the method of consensus of block chains according to the first aspect as well as alternative aspects when the program is executed.
In a fourth aspect, the present application provides a blockchain system, including a plurality of consensus nodes, wherein each consensus node includes a memory and a server;
a memory for storing a program;
a processor for executing a program stored in the memory, the processor being adapted to perform the method of consensus on block chains according to the first aspect and alternative aspects when the program is executed.
In a fifth aspect, the present application provides a computer-readable storage medium having stored thereon computer-executable instructions, which, when executed by a processor, are configured to implement the method for block chain consensus according to the first aspect or the alternative.
When a fault-state consensus node exists in a block chain, each normal-state consensus node generates a plurality of verification information and broadcasts the verification information to other consensus nodes, so that the consensus nodes in the normal state can receive enough verification information under the condition that the fault-state consensus nodes exist, and whether block data are added into the block chain can be determined according to the received information. Especially, when the number of consensus nodes in the block chain is 3f +1 and the number of consensus nodes in the fault state exceeds f, x represents the node in the normal state by generating (2f + 1)/x verification information for each consensus node. Each consensus node can receive verification information exceeding 2f +1, so that nodes in a fault state in a block chain system can continue consensus when the fault-tolerant upper limit of a practical Byzantine fault-tolerant consensus algorithm is exceeded.
Drawings
Fig. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a block chain consensus method according to another embodiment of the present application;
fig. 3 is a schematic flowchart of a block chain consensus method according to another embodiment of the present application;
fig. 4A is a state diagram of a blockchain system according to another embodiment of the present application;
fig. 4B is a state diagram of a blockchain system according to another embodiment of the present application;
fig. 4C is a state diagram of a block chain system according to another embodiment of the present application;
fig. 4D is a state diagram of a block chain system according to another embodiment of the present application;
FIG. 5 is a diagram illustrating a data structure of a signature request according to another embodiment of the present application;
FIG. 6 is a data structure diagram of a submit request according to another embodiment of the present application;
fig. 7 is a schematic structural diagram of a consensus device according to another embodiment of the present application;
fig. 8 is a schematic structural diagram of a consensus node according to another 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 some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
A blockchain is a distributed storage system that is commonly maintained and trusted by multiple nodes. The block chain bottom layer is a chain formed by a series of blocks, each block records the hash value of the block besides the data of the block, and the chained data structure is formed in this way. A chunk consists of a chunk header and a chunk body, where the chunk header definition includes important fields such as the height of the chunk, the hash value of the last chunk, and the chunk body primarily stores transaction data. The block chain uses a cryptographic mode to ensure the safety of data transmission and access, and uses a chain structure to ensure that the data on the chain cannot be tampered.
As shown in fig. 1, the blockchain system provided by an embodiment of the present invention includes a plurality of node servers 102 and a terminal device 101. The node servers 102 are consensus nodes in a blockchain system. The consensus node has a complete copy of the ledger and has the ability to participate in block chain consensus and maintain the ledger.
The terminal Device 101 may be any one of a Mobile phone, a tablet computer, a notebook computer, a palm computer, a Mobile Internet Device (MID), a wearable Device, and the like as a user terminal.
When transaction data need to be uploaded to the blockchain system, the blockchain system is requested to pack the uploaded data into blockchain data, and the blockchain data is written into the blockchain. After the terminal device uploads data to the blockchain network, a consensus node that packs transaction data into new blockchain data may be selected from the blockchain network. The consensus node which packages the transaction data to generate new block data is called a main consensus node, and other consensus nodes are called duplicate consensus nodes.
New block data may need to be identified before it can be added to the block chain. After the master consensus node generates the new block data, the new block data needs to be broadcast to the other consensus nodes in the block chain system, so that each consensus node can verify the new block.
Taking a Practical Byzantine Fault Tolerant (PBFT) consensus algorithm as an example, according to whether a consensus node is a malicious node, the consensus node can be further divided into a Byzantine node and a non-Byzantine node. The Byzantine node is a malicious node and cannot normally participate in consensus. The non-Byzantine node is an honest node and can normally participate in consensus. When the total number of consensus nodes in the block chain system is 3f +1, the block chain system can only realize the consensus normally when the number of non-Byzantine nodes reaches 2f + 1. Also, when the byzantine node exceeds f, the blockchain system cannot be normally identified. That is, the maximum fault-tolerant node number of the block chain using the PBFT consensus algorithm is f, and if the number of node servers in a fault state in the block chain exceeds f due to network failure, equipment damage, and the like, the block chain cannot be subjected to consensus.
In the prior art, two schemes are mainly adopted to deal with the condition that nodes in a fault state exceed the fault tolerance upper limit of a PBFT algorithm. One of the schemes is to reconstruct the consensus node according to backup data, wherein the backup data includes data such as a private key, a certificate, and configuration of the node. And the newly-established consensus node can be connected with other consensus nodes, and data in the block chain can be acquired. Another solution is to rearrange new blockchains.
However, the prior art approach of rearranging nodes or rearranging block chains requires a relatively long recovery time.
The embodiment of the application provides a block chain consensus method, a block chain consensus device, a block chain consensus node, a block chain consensus system and a storage medium, and aims to improve the success rate of consensus when a node in a fault state exists. The inventive concept of the present application is: when there is a node in the block chain that is in a failure state, for example: when the node server is damaged, the disk is formatted or the network is abnormal, each common node in the normal state generates a plurality of verification information and broadcasts the verification information to all the common nodes, so that each node in the normal state can receive enough verification information, common identification can be performed according to the verification information, the common node or the block chain does not need to be reconstructed, and the fault recovery capability of the block chain system is improved. After the consensus node in the fault state returns to normal, the consensus node can continue to participate in consensus by configuring and synchronizing the latest block data.
As shown in fig. 2, another embodiment of the present application provides a block chain consensus method, where an execution subject of the consensus algorithm is a consensus node, and the consensus node may be a main consensus node or a duplicate consensus node. The consensus method comprises the following steps:
s201, the consensus node verifies the block data to generate a plurality of pieces of first verification information.
The block data is generated by packaging transaction data uploaded by the terminal device, and if the common node is a main common node, after the node receives the transaction data uploaded by the terminal device, the transaction data needs to be packaged into the block data, and the block data also needs to be broadcast to other common nodes, so that the other common nodes can verify the block data.
When the consensus node checks the block data, a plurality of first check messages need to be generated, and all the first check messages are broadcasted to other consensus nodes. That is, each of the other identified nodes may receive all the first check information transmitted by the identified node.
S202, each other node verifies the block data to generate a plurality of pieces of second verification information.
When each other consensus node checks the block data, it is also necessary to generate a plurality of second check messages and broadcast all the second check messages to the consensus nodes except for the other consensus nodes.
S203, the consensus node receives a plurality of second check messages sent by each of the other consensus nodes in the normal state.
The second verification information is obtained by verifying the block data by other common identification nodes, the common identification node in the fault state cannot send the second verification information to the common identification node due to the fault of the common identification node, and at this time, the second verification information sent by other common identification nodes in the normal state can only be received.
S204, the common identification node adds the block data to the block chain according to the first check information and the second check information.
The consensus node counts the consensus number of the second check information which is the same as the first check information generated by the consensus node and the second check information sent by other consensus nodes, and determines whether the sum of the first check information and the counted consensus number reaches 2f + 1. When 2f +1 is reached, then multiple commit requests are broadcast to the other respective consensus nodes to request that block data be added to the block chain. When the total number of the submission requests generated by the consensus node and the submission requests sent by the other consensus nodes reaches 2f +1, adding the block data into the block chain.
In the block chain consensus method provided by the embodiment of the application, each consensus node in a normal state generates a plurality of pieces of verification information to be broadcast to other consensus nodes, so that the consensus nodes in the normal state can receive enough verification information, consensus can be performed according to the verification information, the consensus success rate when a node in a fault state exists is improved, the consensus nodes or the block chains do not need to be reconstructed, and the fault recovery speed is higher.
As shown in fig. 3, another embodiment of the present application provides a block chain consensus method, where an execution subject of the consensus algorithm is a consensus node, and the consensus node may be a primary consensus node or a duplicate consensus node. The consensus method comprises the following steps:
s301, the consensus node verifies the block data to generate a plurality of pieces of first verification information.
And a plurality of private keys are arranged in each consensus node, one of the private keys is selected as a main private key, and the other private keys are shadow private keys.
Each node in the block chain system is provided with two modes, namely a normal mode and a recovery mode. The switching condition of the normal mode and the recovery mode can be determined according to requirements. Preferably, when the total number of all nodes in the block chain system is 3f +1 and the number of nodes in a fault state exceeds f, the recovery mode is started. Otherwise, each node in the blockchain is in a normal mode.
When the blockchain system is in a normal mode and the consensus node needs to perform consensus, the consensus node does not read the shadow private key and only reads the main private key. After the block data is verified to obtain a verification result, the verification result is encrypted by using the main private key to generate verification information.
When the blockchain system is in a recovery mode, when the consensus node needs to perform consensus, the consensus node reads the main private key and the shadow private key. After the block data is verified to obtain a verification result, the verification result is encrypted by using the main private key and all shadow private keys to generate a plurality of pieces of first verification information. That is, each private key is used to encrypt the verification result to generate a first verification information. The number of the first check information generated by the consensus node is the same as the number of the private keys.
Preferably, after the hash operation is performed on the verification result, the private key is used to encrypt the operation result of the hash operation to obtain the first verification information.
After the first check information is subjected to the private key pair, a node identifier corresponding to the private key is added to each piece of first check information, so that other common nodes can decrypt the first check information by using the node identifiers.
The node identifier may be a serial number uniquely identifying the node, or may be a node index, and the serial number of the node is quickly determined by the node index.
Considering that the consensus node is generally a 64-byte binary string, the field contained in the verification message consumes part of the network bandwidth, a node index is introduced, each consensus node maintains a common consensus node list, the node index records the position of the serial number of each consensus node in the list, when the verification message packet is sent, the node index is only needed to be carried, and other nodes can index the serial number of the node from the common consensus node list, so that the message is verified.
S302, each other node verifies the block data to generate a plurality of pieces of second verification information.
And a plurality of private keys are also arranged in other nodes, one of the plurality of private keys is selected as a main private key, and other private keys are shadow private keys.
Each node in the block chain system is provided with two modes, namely a normal mode and a recovery mode. The switching conditions between the normal mode and the recovery mode, and the manner of generating the verification information in the normal mode and the recovery mode are the same as those of the node in S301, and are not described again here.
Preferably, when in the recovery mode, the number of the second check information generated by each other common node is the same as the number of the first check information generated by the common node. That is, the number of the private keys arranged in each other consensus node is the same as the number of the private keys arranged in the consensus node.
Preferably, when in the recovery mode, the amount of the first check information conforms to the following formula:
where k denotes the number of the first check information, and x denotes the number of the common nodes in the normal state. (3f + 1) is the total number of all consensus nodes in the block chain, and f is a positive integer.
By enabling each consensus node to generate (2f + 1)/x verification information, each consensus node can receive the verification information exceeding 2f +1, so that when the fault-tolerant upper limit of the practical Byzantine fault-tolerant consensus algorithm is exceeded by the nodes in the fault state in the block chain system, consensus can be continued.
S303, the consensus node receives a plurality of second check messages sent by each of the other consensus nodes in the normal state.
The step has already been described in detail in S203, and is not described again here.
Preferably, the ratio between the number of other consensus nodes in the normal state and the total number of all nodes in the block chain is less than or equal to (2f + 1)/(3f + 1), where f is a positive integer. That is, the node in fault state in the block chain system exceeds the fault tolerance upper limit of the practical Byzantine fault tolerance consensus algorithm.
S304, when the first check information and the second check information meet a first preset condition, the consensus node sends a first submission request to each other consensus node.
Wherein, a plurality of first check-up information and a plurality of second check-up information satisfy first predetermined condition, specifically include: the ratio of the first consensus quantity to the total number of all consensus nodes in the block chain reaches (2f + 1)/(3f + 1). The first consensus number is the sum of a second consensus number and the first check information, the second consensus number is obtained by counting second check information which is the same as the first check information, and f is a positive integer.
The commit requests are used for requesting to add block data to the block chain, and when the recovery mode is in the recovery mode, the number of the first commit requests generated by the consensus node is the same as the number of the first verification information generated by the consensus node.
When in normal mode, a consensus node generates only one commit request.
And S305, receiving a plurality of second submission requests sent by each other consensus node.
And determining whether to generate a plurality of second submission requests by each of the other consensus nodes according to the verification information generated by the other consensus node and the verification information sent by the nodes in the normal state except the other consensus nodes. The determination condition for determining whether to generate the second commit request is the same as in S204, and is not described herein again.
When the common identification nodes are in the recovery mode, the number of the second submission requests generated by other common identification nodes is the same as the number of the first verification information generated by other common identification nodes, and all the submission requests generated by the common identification nodes are broadcast to the common identification nodes except the common identification nodes. When in the normal mode, one other consensus node generates only one submission request, i.e. broadcasts one submission request only to consensus nodes other than itself.
S306, adding the block data into the block chain according to the first submission requests and the second submission requests.
Wherein, when the ratio of the third consensus number to the total number of all consensus nodes in the blockchain reaches (2f + 1)/(3f + 1), the blockchain is added with the blockchain. Wherein the third consensus number is a sum of the number of first commit requests and the number of second commit requests.
That is, the total number of all consensus nodes in the block chain is 3f +1, and when the total number of the commit requests generated by the consensus node itself and the commit requests sent by other consensus nodes is received reaches 2f +1, the block data is added to the block chain. Otherwise, the block data cannot be added to the block chain.
In the consensus algorithm provided by the embodiment of the application, by configuring a plurality of private keys in each consensus node, when the consensus node is in a recovery mode, a plurality of verification information can be generated according to the configured private keys and broadcasted to other nodes, so that each consensus node in a normal state can receive enough verification information for consensus, and the success rate of consensus when a node in a fault state exists is improved.
Another embodiment of the present application provides a block chain consensus method. As shown in fig. 4A, the blockchain system includes 4 common nodes, which are respectively labeled as common node 1 to common node 4. Each consensus node is configured with a primary private key (indicated by solid lines) and a shadow private key (indicated by dashed lines).
When all the consensus nodes can work normally, each consensus node does not read the shadow private key and only reads the main private key.
The condition for each common node in the normal state to switch from the normal mode to the recovery mode is that more than 1 common node in the failure state is present.
As shown in fig. 4B, when all the data of the consensus node 3 is lost, the network of the consensus node 4 fails. The common node 3 and the common node 4 both have faults, more than 1 common node in the fault state exists, and the common node 1 and the common node 2 enter a recovery mode.
As shown in fig. 4C, the consensus node 1 and the consensus node 2 read the primary private key and the shadow private key, and perform the consensus method as follows.
As shown in fig. 4D, when the network of the consensus node 4 is repaired, the number of nodes in the failure state is reduced to 1, and the consensus node 1, the consensus node 2, and the consensus node 4 enter the normal mode.
Wherein, the consensus node 2 is another consensus node. The consensus method comprises the following steps:
s401, the block data is verified by the consensus node to generate a plurality of pieces of first verification information.
The consensus node 1 serves as a main consensus node in the block chain, encapsulates the latest block data into a data packet, and broadcasts the latest block data to all other consensus nodes.
The consensus node 1 checks the latest block data to obtain a check result, performs hash operation on the check result, and encrypts the hash value of the check result by using a main private key and a shadow private key respectively to obtain two pieces of first check information. And broadcasting the two pieces of first check information to other common identification nodes. As shown in fig. 5, the consensus node 1 encapsulates two pieces of first check information in the same check request.
S402, each other node verifies the block data to generate a plurality of second verification messages.
After receiving the data packet broadcast by the formula node 1, the consensus node 2 analyzes the latest block data. And verifying the block data to obtain a verification result, performing hash operation on the verification result, and encrypting the hash value of the verification result by using a main private key and a shadow private key respectively to obtain two pieces of second verification information. And broadcasts the two second check-up messages to other consensus nodes. As shown in fig. 5, the consensus node 1 encapsulates two pieces of first check information in the same check request.
And S403, the consensus node receives a plurality of pieces of second check-up information sent by each other consensus node in the normal state.
Wherein, the consensus node 1 receives the two pieces of second verification information sent by the consensus node 2.
S404, when the first check information and the second check information meet a first preset condition, the consensus node sends a first submission request to each other consensus node.
When at least one of the two pieces of second verification information received by the consensus node 1 is the same as the first verification information generated by the consensus node 1, the consensus node 1 signs the submitted information by using the main private key and the shadow private key respectively to generate two first submission requests. And broadcasts the generated two first submission requests to other consensus nodes. As shown in fig. 6, the consensus node 1 encapsulates two first commit requests in the same commit request.
S405, receiving a plurality of second submission requests sent by each other consensus node.
When at least one of the two pieces of first verification information received by the consensus node 2 is the same as second verification information generated by the consensus node, the consensus node 2 signs the submitted information by using the primary private key and the shadow private key respectively to generate two second submission requests. And broadcasts the generated two second submission requests to the other consensus nodes.
S406, adding the block data into the block chain according to the first submission requests and the second submission requests.
The consensus node 1 receives two second submission requests from the consensus node 2, combines the first submission requests generated by the consensus node with the first submission requests generated by the consensus node, collects 4 submission requests, and stores the block data into the block chain if the number of the submission requests exceeds 3.
In the consensus method provided by the embodiment of the application, the recovery mode is entered when the number of the failed nodes exceeds the fault tolerance upper limit of the PBFT consensus algorithm, so that the nodes in the normal state can be rapidly subjected to consensus continuously, and the recovery rate is high. And when the fault node is recovered to be normal, the fault node can be quickly identified with other nodes.
As shown in fig. 7, another embodiment of the present application provides a block chain consensus apparatus 500, where the consensus apparatus 500 includes:
the processing module 501 is configured to verify block data to generate a plurality of first verification information, where the block data is generated by performing a packaging process on transaction data;
a receiving module 502, configured to receive multiple pieces of second check information sent by each other common node in a normal state, where the second check information is obtained by checking the block data;
the processing module 501 is further configured to add the block data to the block chain according to the plurality of first check information and the plurality of second check information.
Optionally, the processing module 501 is specifically configured to:
checking the block data to obtain a checking result;
encrypting the verification results by using a plurality of private keys respectively to generate a plurality of first verification information;
each private key is used for encrypting the verification result to generate first verification information.
Optionally, the processing module 501 is further configured to:
and adding a node identifier corresponding to the private key in each piece of first check information so that other common identification nodes decrypt the first check information by using the node identifiers.
Optionally, the processing module 501 is specifically configured to:
when the first check information and the second check information meet a first preset condition, sending a first submission request to each other consensus node;
receiving a plurality of second submission requests sent by each other consensus node;
block data is added to the block chain according to the first plurality of commit requests and the second plurality of commit requests.
Optionally, the processing module 501 is specifically configured to:
when the ratio of the third consensus number to the total number of all consensus nodes in the blockchain reaches (2f + 1)/(3f + 1), adding the blockchain to the blockchain;
wherein the third consensus number is a sum of the number of first commit requests and the number of second commit requests.
Optionally, the plurality of first check information and the plurality of second check information satisfy a first preset condition, which specifically includes:
the ratio of the first consensus number to the total number of all consensus nodes in the block chain reaches (2f + 1)/(3f + 1);
the first consensus number is the sum of a second consensus number and the first check information, the second consensus number is obtained by counting second check information which is the same as the first check information, and f is a positive integer.
Optionally, the ratio between the number of other common nodes in the normal state and the total number of all nodes in the block chain is less than or equal to (2f + 1)/(3f + 1), where f is a positive integer.
Optionally, the number of the second check information generated by each other consensus node is the same as the number of the first check information generated by the consensus node.
Optionally, the amount of the first verification information conforms to the following formula:
wherein k represents the number of the first check information, x represents the number of the consensus nodes in the normal state, (3f + 1) is the total number of all the consensus nodes in the block chain, and k, f and x are positive integers.
As shown in fig. 8, an electronic device 600 provided in another embodiment of the present application includes: a transmitter 601, a receiver 602, a memory 603, and a processor 604.
A transmitter 601 for transmitting instructions and data;
a receiver 602 for receiving instructions and data;
a memory 603 for storing computer-executable instructions;
the processor 604 is configured to execute computer executable instructions stored in the memory to implement the steps performed by the block chain consensus method in the above embodiments. Reference may be made specifically to the related description in the foregoing block chain consensus method embodiment.
Alternatively, the memory 603 may be separate or integrated with the processor 604. When the memory 603 is separately provided, the electronic device further includes a bus for connecting the memory 603 and the processor 604.
Another embodiment of the present application provides a blockchain system, which includes a plurality of common nodes, wherein each common node includes a memory and a server;
a memory for storing a program;
and a processor configured to execute the program stored in the memory, wherein when the program is executed, the processor is configured to perform the method for recognizing a blockchain performed by the electronic device.
Another embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the processor executes the computer-executable instructions, the method for block chain consensus performed by an electronic device as described above is implemented by the electronic device.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art will understand that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and these modifications or substitutions do not depart from the scope of the technical solutions of the embodiments of the present application.
Claims (11)
1. A method for block chain consensus, comprising:
verifying block data to generate a plurality of pieces of first verification information, wherein the block data is generated by packaging transaction data;
receiving a plurality of second check messages sent by other common identification nodes in a normal state, wherein the second check messages are obtained by checking the block data;
when the plurality of first check information and the plurality of second check information meet a first preset condition, sending a plurality of first submission requests to each other consensus node;
receiving a plurality of second submission requests sent by each of the other consensus nodes;
when the ratio of the third consensus quantity to the total number of all consensus nodes in the blockchain reaches (2f + 1)/(3f + 1), adding the blockchain to the blockchain;
wherein the third consensus number is a sum of the number of the first submission requests and the number of the second submission requests, and f is a positive integer.
2. The method of claim 1, wherein the verifying the block data to generate a plurality of first verification information includes:
checking the block data to obtain a checking result;
encrypting the check result by using a plurality of private keys respectively to generate a plurality of first check information;
each private key is used for encrypting the verification result to generate the first verification information.
3. The method according to claim 2, wherein after said encrypting the verification result with a plurality of private keys respectively to generate a plurality of first verification information, the method further comprises:
and adding a node identifier corresponding to the private key in each piece of first check information, so that the other common identification nodes decrypt the first check information by using the node identifiers.
4. The method according to claim 1, wherein the first check-up messages and the second check-up messages satisfy a first preset condition, and specifically includes:
the ratio of the first consensus number to the total number of all consensus nodes in the block chain reaches (2f + 1)/(3f + 1);
the first consensus quantity is the sum of a second consensus quantity and the quantity of the first check information, the second consensus quantity is obtained by counting the second check information which is the same as the first check information, and f is a positive integer.
5. The method of claim 1, wherein a ratio between the number of other consensus nodes in a normal state and the total number of all nodes in the block chain is less than or equal to (2f + 1)/(3f + 1), where f is a positive integer.
6. The method according to claim 1, wherein the number of the second check-up information generated by each of the other consensus nodes is the same as the number of the first check-up information generated by the consensus node.
7. The method of claim 6, wherein the amount of the first check-up information is in accordance with the following formula:
wherein k represents the number of the first check information, x represents the number of the consensus nodes in the normal state, (3f + 1) is the total number of all the consensus nodes in the block chain, and k, f and x are positive integers.
8. An apparatus for block chain consensus, comprising:
the processing module is used for verifying block data to generate a plurality of pieces of first verification information, wherein the block data is generated by packaging transaction data;
a receiving module, configured to receive multiple pieces of second check information sent by each other common node in a normal state, where the second check information is obtained by checking the block data;
the processing module is further configured to add the tile data to the tile chain according to the first check information and the second check information;
the processing module is specifically configured to send a plurality of first submission requests to each of the other consensus nodes when the plurality of first check information and the plurality of second check information satisfy a first preset condition;
receiving a plurality of second submission requests sent by each of the other consensus nodes;
when the ratio of the third consensus number to the total number of all consensus nodes in the blockchain reaches (2f + 1)/(3f + 1), adding the blockchain to the blockchain;
wherein the third consensus number is a sum of the number of first commit requests and the number of second commit requests, and f is a positive integer.
9. A consensus node, comprising:
a memory for storing a program;
a processor for executing the program stored by the memory, the processor being configured to perform the block chain consensus method as claimed in any one of claims 1 to 7 when the program is executed.
10. A blockchain system comprising a plurality of consensus nodes, wherein each consensus node comprises a memory and a server;
a memory for storing a program;
a processor for executing the program stored by the memory, the processor being configured to perform the block chain consensus method as claimed in any one of claims 1 to 7 when the program is executed.
11. A computer-readable storage medium having stored thereon computer-executable instructions for implementing the block chain consensus method according to any one of claims 1 to 7 when executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010901332.2A CN112035886B (en) | 2020-08-31 | 2020-08-31 | Block chain consensus method, device, consensus node, system and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010901332.2A CN112035886B (en) | 2020-08-31 | 2020-08-31 | Block chain consensus method, device, consensus node, system and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112035886A CN112035886A (en) | 2020-12-04 |
| CN112035886B true CN112035886B (en) | 2023-01-10 |
Family
ID=73586670
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010901332.2A Active CN112035886B (en) | 2020-08-31 | 2020-08-31 | Block chain consensus method, device, consensus node, system and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112035886B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113542251B (en) * | 2021-07-09 | 2023-07-21 | 中国工商银行股份有限公司 | Data reporting method and device |
| CN114239025A (en) * | 2021-12-20 | 2022-03-25 | 深圳前海微众银行股份有限公司 | Data processing method and device based on block chain |
| CN114254050B (en) * | 2022-03-02 | 2022-06-07 | 恒生电子股份有限公司 | Block chain network consensus preloading method, device, equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109257427A (en) * | 2018-09-26 | 2019-01-22 | 网宿科技股份有限公司 | A kind of method for processing business and system based on block chain |
| CN109669986A (en) * | 2018-12-12 | 2019-04-23 | 深圳乐信软件技术有限公司 | Blacklist sharing method, device, equipment and storage medium based on block chain |
| CN111444211A (en) * | 2020-03-26 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Block chain consensus node checking method, device, equipment and storage medium |
| CN111523899A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Consensus method of alliance chain, data verification method, device and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018112948A1 (en) * | 2016-12-23 | 2018-06-28 | 深圳前海达闼云端智能科技有限公司 | Block generation method and device, and blockchain network |
-
2020
- 2020-08-31 CN CN202010901332.2A patent/CN112035886B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109257427A (en) * | 2018-09-26 | 2019-01-22 | 网宿科技股份有限公司 | A kind of method for processing business and system based on block chain |
| CN109669986A (en) * | 2018-12-12 | 2019-04-23 | 深圳乐信软件技术有限公司 | Blacklist sharing method, device, equipment and storage medium based on block chain |
| CN111444211A (en) * | 2020-03-26 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Block chain consensus node checking method, device, equipment and storage medium |
| CN111523899A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Consensus method of alliance chain, data verification method, device and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112035886A (en) | 2020-12-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111543026B (en) | System for performing master node change in distributed network | |
| EP3566392B1 (en) | Achieving consensus among network nodes in a distributed system | |
| CN110178340B (en) | Recovery processing of network nodes in distributed systems | |
| CN112035886B (en) | Block chain consensus method, device, consensus node, system and storage medium | |
| CN110059494B (en) | Privacy protection method for block chain transaction data and block chain system | |
| TWI737392B (en) | Computer-implemented method for processing blockchain data by a blockchain node of a blockchain network in a trusted execution environment (tee), system communicating shared blockchain data and apparatus for communicating shared blockchain data | |
| TWI729880B (en) | Shared blockchain data storage based on error correction coding in trusted execution environments | |
| TWI720918B (en) | Consenus of shared blockchain data storage based on error correction code | |
| TWI759791B (en) | Method, system and apparatus of shared blockchain data storage based on error correction code | |
| KR102396737B1 (en) | Prioritize storage of shared blockchain data | |
| CN112600678B (en) | Data processing method, device, equipment and storage medium | |
| CN111095218B (en) | Method, system and device for storing shared block chain data based on error correction coding | |
| KR20210045353A (en) | Indexing and recovery of encoded blockchain data | |
| CN116881045A (en) | Block chain data recovery method, device and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |