CN111275438A - Consensus method, device, equipment and storage medium for block chain network - Google Patents
Consensus method, device, equipment and storage medium for block chain network Download PDFInfo
- Publication number
- CN111275438A CN111275438A CN202010037474.9A CN202010037474A CN111275438A CN 111275438 A CN111275438 A CN 111275438A CN 202010037474 A CN202010037474 A CN 202010037474A CN 111275438 A CN111275438 A CN 111275438A
- Authority
- CN
- China
- Prior art keywords
- verification
- transaction
- node
- verification node
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application discloses a block chain network consensus method, a block chain network consensus device, a block chain network consensus equipment and a block chain network consensus storage medium. The method comprises the following steps: determining a master verification node and a plurality of ordinary verification nodes from a plurality of verification nodes; the main verification node and the common verification nodes carry out transaction set consensus to generate a plurality of latest closing blocks, and the transaction set is constructed by the main verification node; and the main verification node and the common verification nodes perform block consensus on the plurality of latest closed blocks to generate new blocks. The transaction consensus process dominated by the main verification node and the common verification node can improve the consensus efficiency of legal transactions.
Description
Technical Field
The present invention relates to the field of blockchain, and in particular, to a method, an apparatus, a device, and a storage medium for blockchain consensus.
Background
The essence of the block chain technology is a decentralized distributed data storage system, and with the maturity of the technology, the block chain technology has been widely applied to numerous fields such as finance, internet of things, social communication and the like. The block chain is composed of blocks, and each time data is written, a new block is generated.
After receiving data to be stored in the blockchain network, each node in the blockchain network is required to select a node for recording the data to be stored according to a certain rule so as to record the data to be stored, the process can be called a consensus process, which is a core mechanism of the blockchain network, and common consensus algorithms include a granted rights certification algorithm (DPOS) and a Practical Byzantine fault-tolerant algorithm (PBFT), and the like.
RPCA (English: Ripple Protocol consensus algorithm; Chinese: Ripple Protocol consistency algorithm) is a consensus algorithm used in a Ripple block chain network, and with the development of a block chain network technology, compared with consensus algorithms such as DPOS and PBFT, the RPCA consensus algorithm in the Ripple block chain network has the defect of obvious slow consensus speed.
Disclosure of Invention
In view of the above-mentioned drawbacks and deficiencies of the prior art, it is desirable to provide a consensus method, apparatus, device and storage medium for a blockchain network that can improve the efficiency of consensus.
In a first aspect, an embodiment of the present application provides a consensus method for a blockchain network, where the blockchain network includes a plurality of verification nodes, and the method includes:
determining a main verification node and a plurality of common verification nodes from the plurality of verification nodes, wherein the plurality of common verification nodes are the rest verification nodes except the main verification node in the plurality of verification nodes;
the main verification node and the common verification nodes carry out transaction set consensus to generate a plurality of latest closing blocks, and the transaction set is constructed by the main verification node;
and the main verification node and the common verification nodes perform block consensus on the plurality of latest closed blocks to generate new blocks.
In a second aspect, an embodiment of the present application provides a consensus apparatus for a blockchain network, where the blockchain network includes a plurality of verification nodes, and the apparatus includes:
a determining module configured to determine a main verification node and a plurality of common verification nodes from a plurality of verification nodes, the plurality of common verification nodes being the rest of the plurality of verification nodes except the main verification node;
the first consensus module is configured to perform consensus on a transaction set by the main verification node and the common verification nodes to generate a plurality of latest closing blocks, wherein the transaction set is constructed by the main verification node;
the second consensus module is configured to perform block consensus on the plurality of latest closed blocks by the main verification node and the plurality of common verification nodes to generate new blocks.
In a third aspect, an embodiment of the present application provides a computer device, where the computer device includes:
a processor;
a memory for storing executable instructions of the processor;
wherein the processor is configured to perform the consensus method of the blockchain network as in the first aspect.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the method for consensus on a blockchain network according to the first aspect is implemented.
The method, the device, the equipment and the storage medium for consensus of the blockchain network provided by the embodiment of the application can determine a main verification node and a plurality of common verification nodes from the plurality of verification nodes, the main verification node and the plurality of common verification nodes perform transaction set consensus to generate a plurality of latest closing blocks, the main verification node and the plurality of common verification nodes perform block consensus on the plurality of latest closing blocks to generate new blocks, and the transaction set consensus process dominated by the main verification node and the common verification nodes can improve the consensus efficiency of legal transactions to improve the generation efficiency of the new blocks in the blockchain network.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
fig. 1 is a flowchart of a block chain network consensus method according to an embodiment of the present application;
fig. 2 is a flowchart of another block chain network consensus method according to an embodiment of the present disclosure;
fig. 3 is a schematic structural diagram of a consensus device of a blockchain network according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of another consensus device of a blockchain network according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a consensus device of another blockchain network according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a consensus system of a blockchain network according to an embodiment of the present disclosure.
Detailed Description
The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
The embodiment of the application provides a block chain network consensus method, which can improve the efficiency of an RPCA (resilient packet access) consensus algorithm. The method may be applied in weakly decentralized blockchain networks, such as federation chains. The blockchain network includes a plurality of verification nodes, as shown in fig. 1, the method includes:
In this embodiment of the present application, the master verification node is any one of a plurality of verification nodes in the blockchain network, and the plurality of common verification nodes are the remaining verification nodes except for the master verification node in the plurality of verification nodes.
In the embodiment of the application, a transaction set is constructed by a main verification node, the transaction set is subjected to transaction set consensus by the main verification node and a plurality of common verification nodes, a plurality of latest closing blocks are generated, and the transaction set comprises legal transactions to be subjected to consensus.
And 103, carrying out block consensus on the plurality of latest closed blocks by the main verification node and the plurality of common verification nodes to generate new blocks.
To sum up, the consensus method for the blockchain network provided in the embodiment of the present application may determine a main verification node and a plurality of common verification nodes from the plurality of verification nodes, where the main verification node and the plurality of common verification nodes perform transaction set consensus to generate a plurality of latest closing blocks, and the main verification node and the plurality of common verification nodes perform block consensus on the plurality of latest closing blocks to generate new blocks.
The embodiment of the application provides a block chain network consensus method, which can improve the efficiency of an RPCA (resilient packet access) consensus algorithm. The method may be applied in weakly decentralized blockchain networks, such as federation chains. The blockchain network includes a plurality of verification nodes. As shown in fig. 2, the process includes:
In this embodiment of the present application, a plurality of verification nodes in the blockchain network may cooperate to perform transaction consensus on a received legitimate transaction, so as to generate a new block to store the legitimate transaction. The transaction consensus process includes a transaction set consensus process and a block consensus process. For each verification node, a transaction pool corresponding to the verification node can be established, and when a large number of legal transactions are received in the blockchain network, the transaction pool is used for buffering the large number of legal transactions, so that the data throughput of the blockchain network can be improved. The number of the plurality of verification nodes can be 3f +1, wherein f represents the number of the verification nodes which are allowed to have errors in the transaction consensus process.
In this step, the process of storing the received multiple valid transaction data into the transaction pool corresponding to each verification node may include:
step 2011, a verification node connected to the client receives at least one signed transaction message sent by the client.
In this embodiment of the application, one of the verification nodes in the blockchain network is connected to the client, and is configured to receive at least one signed transaction message sent by the client, where the signed transaction message may include a signed transaction, a timestamp, and a public signature key of the client, and the signed transaction is obtained by the client by signing transaction data with a private signature key of the client.
It should be noted that, when the verification node is connected to multiple clients, the signed transaction message may further include a client identifier to distinguish the signed transaction messages sent by different clients.
Step 2012, a message verification is performed on the at least one signed transaction message.
In this step, a verification node connected to the client may perform message verification on the at least one signed transaction message, which may include signature verification and transaction verification. The signature verification process may be: and acquiring a signature public key in the signature transaction message, verifying the signature transaction by using the signature public key, and if the verification is successful, passing the signature verification to acquire transaction data. The process of transaction verification may include: and verifying the timeliness verification and account consistency of the transaction. The process of the timeliness verification may be: whether the time length of the transaction entering the block chain network is smaller than a preset first time threshold is judged based on the timestamp in the signature transaction message, the first time threshold can be n times of the time length of the transaction consensus generation new block, and n is an integer greater than or equal to 1. If yes, the timeliness verification is passed; the process of consistency verification may be: and judging whether the field of the signature public key in the signature transaction message exists in a field list of an account address stored in a verification node connected with the client, if so, proving that the verification node can receive the transaction sent by the client, and the account consistency verification is passed.
The block chain network in the embodiment of the application belongs to a weak decentralized block chain network, a client of the block chain network is known and controllable, the probability of occurrence of error transaction data is low, in a message verification stage, verification of the content of the transaction data sent by the client is not needed, and the subsequent block consensus stage is directly verified, so that the time spent in the message verification stage is reduced, and the message verification efficiency is improved.
Step 2013, when the verification is passed, determining that the transaction data corresponding to the at least one signature transaction message is a legal transaction, and broadcasting the at least one legal transaction to other verification nodes.
In this step, when the verification passes, it is determined that the transaction data corresponding to the at least one signature transaction message is a legal transaction, a transaction number may be assigned to the at least one legal transaction, and the at least one legal transaction, the timestamp, and the transaction number corresponding to the at least one legal transaction are broadcast to other verification nodes; and when the verification fails, discarding the transaction data corresponding to the at least one signed transaction message when the transaction data is determined to be an illegal transaction.
Step 2014, the other verification nodes add at least one legitimate transaction to the transaction pool corresponding to each verification node.
And for other verification nodes, each verification node adds the at least one legal transaction and the transaction number corresponding to the at least one legal transaction to a transaction pool corresponding to the verification node for caching according to the sequence of the received timestamps of the at least one legal transaction from small to large, and waits for the at least one legal transaction to be identified.
It should be noted that, in this embodiment of the present application, for each verification node, a legal transaction message sent by a verification node that is not connected to the client may also be received, where the legal transaction message includes a legal transaction, a timestamp, and a transaction number corresponding to the legal transaction, and the legal transaction is cached in the transaction pool according to the method in step 2014, the legal transaction in the legal transaction message may be a transaction that is not identified in the previous round of transaction identification process, and the number of the legal transaction messages may be one or more, which is not described in detail in this embodiment of the present application.
In the embodiment of the application, after the plurality of verification nodes acquire at least one legal transaction, a transaction consensus stage is entered. Before transaction consensus is carried out, a main verification node and a plurality of common verification nodes are determined from a plurality of verification nodes to realize rapid consensus of a transaction set and improve efficiency of transaction consensus, wherein the main verification node is any one of the verification nodes, and the common verification nodes are the rest of the verification nodes except the main verification node.
Optionally, the process of determining the master verification node may be: the method comprises the steps of obtaining a view value (view) in a view switching mechanism (view-change), determining a sum value of the view value and a block number of a new block to be generated, determining a ratio of the sum value to the number of a plurality of verification nodes, and determining a node with the same node number and ratio as a main verification node. The determination process of the number of the master verification node can be expressed as:
leader_id＝(view+block_number)％node_num；
the view is a view value in a view switching mechanism, and after entering a transaction consensus stage, the view value in the view switching mechanism can be acquired, wherein the view value is an initialized view value after the previous transaction consensus is completed, and the initialized view value can be 0; the block _ number is a block number of a new block to be generated, and the block number is determined by solving a hash value based on the previous block number; node _ num is the number of multiple verification nodes in the blockchain network.
In the embodiment of the present application, the view switching mechanism is configured to re-determine a new main verification node when the main verification node fails to work normally, such as the main verification node goes down, sends an error message, or fails to send a message normally, so as to prevent the common identification process of the blockchain network from failing to be performed normally.
In this step, the process of transaction set consensus may include;
step 2031, the master verification node obtains at least one legal transaction to construct a transaction set based on the order in which the legal transactions are added to the first transaction pool.
The main verification node can select a specific number of legal transactions from the first transaction pool based on the sequence of the timestamps in the first transaction pool from small to large, determine the specific number of legal transactions and the transaction number of each legal transaction, and construct a transaction set; the specific number may be: and obtaining the number of the legal transactions within a preset legal transaction obtaining time threshold, or obtaining the number of the legal transactions less than or equal to a preset number threshold, wherein the first transaction pool is a transaction pool corresponding to the main verification node.
Step 2032, the master verification node broadcasts the first signature message to a plurality of common verification nodes.
The first signature message comprises a first signature transaction set and a main verification node number, and the first signature transaction set is obtained by the main verification node through signing the transaction set by using a common private key of the main verification node.
Step 2033, for each common verification node, when it is determined that the first signature message is sent by the main verification node and all valid transactions in the transaction set exist in the second transaction pool, broadcasting the second signature message to the main verification node and other common verification nodes.
In this embodiment of the present application, the second signature message includes a second signature transaction set, where the second signature transaction set is obtained by a common verification node signing a transaction set with a common private key of the common verification node, and the second transaction pool is a transaction pool corresponding to the common verification node.
In this step, after receiving the first signature message, the common verification node needs to determine whether the first signature message is sent by a main verification node selected in the current round of transaction consensus process, so as to prevent the common verification node from being mistakenly identified as the main verification node, which causes an error in the transaction consensus process. The process of determining whether the first signed message was sent by the master verification node is: comparing the number of the main verification node in the received first signature message with the number of the main verification node determined in the common verification node, and if the number of the main verification node is the same as the number of the main verification node determined in the common verification node, determining that the first signature message is sent by the main verification node; if not, the first signature message is discarded.
It should be noted that, in this embodiment of the present application, after receiving a legal transaction, each verification node may obtain a consensus public key list, where the consensus public key list records a node number of each verification node and a consensus public key corresponding to each verification node number.
Optionally, for each common verification node, after determining that the first signature message is sent by the main verification node, a consensus public key corresponding to the main verification node may be determined from the consensus public key list, and the first signature transaction set in the first signature message is verified by using the consensus public key, so as to obtain a transaction set constructed by the main verification node; further, whether all legal transactions in the transaction set exist in the second transaction pool or not needs to be judged, and when the legal transactions in the transaction set do not exist or partially exist in the second transaction pool, a transaction acquisition request is sent to a verification node connected with a common verification node to request for acquiring missing legal transactions in the second transaction pool; the transaction obtaining request can include a transaction number of a missing legal transaction, a verification node connected with a common verification node can obtain a legal transaction corresponding to the transaction number based on the transaction number and send the legal transaction to the common verification node, the common verification node can construct a transaction set identical to the transaction set sent by a main verification node, a common identification private key of the common verification node is used for signing the transaction set to obtain a second signature transaction set, the second signature message is broadcasted to a plurality of verification nodes, and the second signature message comprises a second signature transaction set.
Wherein, the process of judging whether all legal transactions in the transaction set exist in the second transaction pool is as follows: determining the transaction numbers of a specific number of legal transactions in the transaction set, comparing the specific number of transaction numbers with a transaction number list of a second transaction pool, wherein the transaction number list comprises all legal transactions, transaction numbers of the legal transactions, time stamps and other information in the second transaction pool, and determining that all legal transactions in the transaction set exist in the second transaction pool when the transaction numbers of the specific number of legal transactions can be found in the transaction number list; when the transaction number of the specific number of legal transactions cannot be found in the transaction number list or part of the transaction numbers can be found in the transaction number list, it is determined that no or part of the legal transactions in the transaction set exist in the second transaction pool.
Step 2034, when the number of the second signature messages received by the main verification node and each common verification node is greater than the preset signature number threshold, a transaction set consensus is reached.
For a main verification node and each common verification node in a block chain network, a second signature transaction set sent by the main verification node and/or the common verification nodes can be received, when the number of second signature messages received by the main verification node and each common verification node is larger than a preset signature number threshold value, transaction set consensus is achieved, and a plurality of latest closing blocks are generated and are determined after the main verification node and each verification node in the common verification nodes are subjected to transaction set consensus. For example, the preset signature number threshold may be 2f + 1.
It should be noted that, when the main verification node and the plurality of common verification nodes perform the transaction set consensus, each of the plurality of verification nodes further needs to determine whether the main verification node needs to be updated in order to prevent the transaction set consensus from failing to be achieved within a certain time due to the main verification node being down, sending an error message, or failing to send a message normally; when the master verification node needs to be updated, determining a master verification node from the plurality of verification nodes and updating the master verification node by the plurality of ordinary verification node methods in step 202 are performed until it is determined that the master verification node does not need to be updated.
Optionally, the process of determining whether the master verification node needs to be updated may be: the method comprises the steps that a first verification node judges whether a transaction set consensus is not achieved within a preset time threshold, the first verification node is any one of a plurality of verification nodes, preferably a common verification node, if the transaction set consensus is achieved, a view switching message is constructed, the view switching message is stored and broadcasted to a second verification node, the view switching signature message is obtained by the first verification node through signing of the view switching message by using a consensus private key of the first verification node, the view switching message comprises a view value to be updated, the view value to be updated is a view value in a view switching mechanism and is added with 1, and the second verification node is the rest of the plurality of verification nodes except the first verification node; for each second verification node, when the second verification node verifies the view switching signature message sent by the first verification node, acquiring a view switching message; when the number of the nodes acquiring the view switching message in the plurality of verification nodes is larger than a preset node number threshold, the main verification node is determined to be required to be updated, and the view value to be updated is determined as the view value in the view switching mechanism, wherein the view switching message.
For example, assuming that the blockchain network includes m verification nodes, in the transaction set consensus process, the view value in the view switching mechanism is 0, if the first verification node determines that the transaction set consensus is not achieved within the preset time threshold, a view switching message is constructed, the view switching message is stored, and a view switching signature message is broadcast to the second verification node, where the view value to be updated in the view switching message is the view value in the view switching mechanism plus 1, and the view value to be updated is 1; m-1 second verification nodes can receive the view switching signature message, and for each second verification node, when the second verification node verifies the view switching signature message sent by the first verification node, the view switching message is obtained; assuming that the number of nodes, which acquire the view switching message constructed by the verification node A, in the multiple verification nodes is greater than a preset node number threshold, it is determined that the master verification node needs to be updated, and a view value 1 to be updated is determined as a view value 1 in a view switching mechanism.
In this step, the master verification node and the plurality of ordinary verification nodes perform block consensus on the determined plurality of latest closed blocks, and for each verification node, the process of performing block consensus may be: sequentially acquiring state information of each legal transaction according to the sequence of the timestamps of at least one legal transaction in the transaction set from small to large, and constructing a state set, wherein the state information can be account data information of an account corresponding to the legal transaction; calculating a block hash value by using the block number of the new block to be generated, the hash value of the transaction set, the hash value of the state set, the hash value of the parent block, the timestamp and the like; and signing the block hash value by using the common private key of the verification node to obtain a signature block hash value, and broadcasting the signature block hash value to other verification nodes.
Furthermore, each verification node may receive the signature block hash values sent by other verification nodes, may determine the consensus public key corresponding to the other node from the consensus public key list, and verify the signature block hash value by using the consensus public key to obtain a plurality of block hash values corresponding to the other verification nodes; calculating a ratio value of the block hash value corresponding to each other verification node and the block hash value of the verification node, when the ratio value corresponding to a certain verification node is greater than a ratio threshold, determining that the latest closing block corresponding to the verification node is the latest block, and initializing a view value in a view switching mechanism to be 0, wherein the ratio value can be 80%.
To sum up, the block chain network consensus method provided in this embodiment of the present application may store a plurality of received valid transaction data in a transaction pool corresponding to each verification node, so as to improve data throughput of the block chain network, determine a main verification node, perform transaction set consensus based on the main verification node and a plurality of common verification nodes, and when the transaction set consensus is over and the main verification node needs to be updated, return to perform the above operation to update the main verification node until it is determined that the main verification node does not need to be updated, generate a plurality of latest closing blocks, perform block consensus on the plurality of latest closing blocks, and generate a new block. The main verification node and the common verification node are used for leading, and the transaction consensus process of monitoring time by the view switching mechanism can improve the consensus efficiency of legal transactions so as to improve the generation efficiency of new blocks in the blockchain network.
The embodiment of the application provides a consensus device for a block chain network, which can improve the efficiency of an RPCA (resilient packet access) consensus algorithm. The apparatus may be applied in a weakly decentralized blockchain network, such as a federation chain, the blockchain network including a plurality of authentication nodes, as shown in fig. 3, the apparatus 30 including:
a determining module 301 configured to determine a main verification node and a plurality of common verification nodes from a plurality of verification nodes, wherein the plurality of common verification nodes are the rest verification nodes except the main verification node;
a first consensus module 302 configured to perform a transaction set consensus between the main verification node and the plurality of common verification nodes, and generate a plurality of latest closed blocks, wherein the transaction set is constructed by the main verification node;
the second consensus module 303 is configured to perform block consensus on the plurality of last closed blocks by the master verification node and the plurality of ordinary verification nodes to generate new blocks.
Optionally, the determining module 301 is configured to:
acquiring a view value in a view switching mechanism;
the sum value of the view value and the block number of the new block to be generated is determined,
determining a ratio of the sum to a number of the plurality of verification nodes;
and determining the node with the equal node number and ratio as the main verification node.
Optionally, the first consensus module 301 is configured to:
the main verification node acquires at least one legal transaction to construct a transaction set based on the sequence of adding the legal transactions to a first transaction pool, wherein the first transaction pool is a transaction pool corresponding to the main verification node;
the main verification node broadcasts a first signature message to a plurality of common verification nodes, the first signature message comprises a first signature transaction set and a main verification node number, and the first signature transaction set is obtained by the main verification node through signing the transaction set by using a common identification private key of the main verification node;
for each common verification node, when the first signature message is determined to be sent by the main verification node and all legal transactions in a transaction set exist in a second transaction pool, broadcasting the second signature message to the main verification node and other common verification nodes, wherein the second signature message comprises a second signature transaction set, the second signature transaction set is obtained by the common verification node by using a common identification private key of the common verification node to sign the transaction set, and the second transaction pool is a transaction pool corresponding to the common verification node;
and when the number of the second signature messages received by the main verification node and each common verification node is greater than a preset signature number threshold value, transaction set consensus is achieved.
Optionally, as shown in fig. 4, the apparatus 300 further includes:
a determining module 304 configured to determine, by each of the plurality of verification nodes, whether the master verification node needs to be updated;
when the master verification node needs to be updated, the determining module 301 is configured to perform determining one master verification node and a plurality of common verification nodes from the plurality of verification nodes until it is determined that the master verification node does not need to be updated.
Optionally, the determining module 304 is configured to:
the method comprises the steps that a first verification node judges whether a transaction set consensus is not achieved within a preset time threshold, wherein the first verification node is any one of a plurality of verification nodes;
if so, constructing a view switching message, storing and broadcasting the view switching signature message to a second verification node, wherein the view switching signature message is obtained by the first verification node by signing the view switching message by using a common private key of the first verification node, the view switching message comprises a view value to be updated, the view value to be updated is the view value in a view switching mechanism plus 1, and the second verification node is the rest verification nodes except the first verification node in the plurality of verification nodes;
for each second verification node, when the second verification node verifies the view switching signature message sent by the first verification node, acquiring a view switching message;
when the number of the nodes acquiring the view switching message in the plurality of verification nodes is larger than a preset node number threshold, it is determined that the main verification node needs to be updated, and the view value to be updated is determined as the view value in the view switching mechanism.
Optionally, the first consensus module 301 is further configured to: :
and when the legal transactions in the transaction set do not exist or partially exist in the second transaction pool, sending a transaction acquisition request to an authentication node connected with the common authentication node to request to acquire the missing legal transactions in the second transaction pool.
Optionally, as shown in fig. 5, the apparatus 300 further includes:
a storage module 305 configured to store the received at least one legal transaction by each authentication node into a transaction pool corresponding to each authentication node.
Optionally, the storage module 305 is configured to:
the method comprises the steps that a verification node connected with a client receives at least one signature transaction message sent by the client, wherein the signature transaction message comprises a signature transaction, and the signature transaction is obtained by the client by utilizing a signature private key of the client to sign transaction data;
performing message verification on at least one signed transaction message;
when the verification is passed, determining that the transaction data corresponding to the at least one signature transaction message is legal transaction, and broadcasting the at least one legal transaction to other verification nodes;
the other authentication nodes add at least one legitimate transaction to a transaction pool corresponding to each authentication node.
To sum up, the consensus device for a blockchain network provided in this embodiment of the present application may store a plurality of received valid transaction data in a transaction pool corresponding to each verification node, so as to improve data throughput of the blockchain network, determine a main verification node, perform transaction set consensus based on the main verification node and a plurality of common verification nodes, and when the transaction set consensus is over time and it is determined that the main verification node needs to be updated, return to perform the above operation to update the main verification node until it is determined that the main verification node does not need to be updated, generate a plurality of latest closing blocks, perform block consensus on the plurality of latest closing blocks, and generate a new block. The main verification node and the common verification node are used for leading, and the transaction consensus process of monitoring time by the view switching mechanism can improve the consensus efficiency of legal transactions so as to improve the generation efficiency of new blocks in the blockchain network.
Fig. 6 is a diagram illustrating a computer system according to an exemplary embodiment, which includes a Central Processing Unit (CPU)401 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)402 or a program loaded from a storage section into a Random Access Memory (RAM) 403. In the RAM403, various programs and data necessary for system operation are also stored. The CPU401, ROM402, and RAM403 are connected to each other via a bus 404. An input/output (I/O) interface 405 is also connected to bus 404.
The following components are connected to the I/O interface 405: an input section 406 including a keyboard, a mouse, and the like; an output section including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 408 including a hard disk and the like; and a communication section 409 including a network interface card such as a LAN card, a modem, or the like. The communication section 409 performs communication processing via a network such as the internet. Drivers are also connected to the I/O interface 405 as needed. A removable medium 411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 410 as necessary, so that a computer program read out therefrom is mounted into the storage section 408 as necessary.
In particular, the processes described above in fig. 1-2 may be implemented as computer software programs, according to embodiments of the present application. For example, various embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section, and/or installed from a removable medium. The above-described functions defined in the system of the present application are executed when the computer program is executed by a Central Processing Unit (CPU) 401.
It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of methods, apparatus, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves. The described units or modules may also be provided in a processor, and may be described as: a processor includes a determination module, a first consensus module, and a second consensus module. Where the names of these units or modules do not in some cases constitute a limitation of the unit or module itself, for example, the determination module may also be described as "determination module for determining one master authentication node and a plurality of ordinary authentication nodes from among the plurality of authentication nodes".
As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method for recognizing a blockchain network as described in the above embodiments.
The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by a person skilled in the art that the scope of the invention as referred to in the present application is not limited to the embodiments with a specific combination of the above-mentioned features, but also covers other embodiments with any combination of the above-mentioned features or their equivalents without departing from the inventive concept. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.
Claims (11)
1. A consensus method for a blockchain network comprising a plurality of verification nodes, the method comprising:
determining a main verification node and a plurality of common verification nodes from the plurality of verification nodes, wherein the plurality of common verification nodes are the rest verification nodes except the main verification node;
the main verification node and the common verification nodes perform transaction set consensus to generate a plurality of latest closing blocks, and the transaction set is constructed by the main verification node;
the master verification node and the plurality of ordinary verification nodes perform block consensus on the plurality of latest closed blocks to generate new blocks.
2. The method of claim 1, wherein determining a master authentication node and a plurality of common authentication nodes from the plurality of authentication nodes comprises:
acquiring a view value in a view switching mechanism;
determining a sum value of the view value and a block number of a new block to be generated,
determining a ratio of the sum to the number of the plurality of verification nodes;
and determining the node with the node number equal to the ratio as the main verification node.
3. The method of claim 1, wherein the master authentication node and the plurality of common authentication nodes perform a transaction set consensus comprising:
the main verification node acquires at least one legal transaction to construct a transaction set based on the sequence of adding the legal transactions to a first transaction pool, wherein the first transaction pool is a transaction pool corresponding to the main verification node;
the master verification node broadcasts a first signature message to the plurality of common verification nodes, wherein the first signature message comprises a first signature transaction set and a master verification node number, and the first signature transaction set is obtained by the master verification node through signing the transaction set by using a common identification private key of the master verification node;
for each common verification node, when it is determined that the first signature message is sent by the main verification node and all legal transactions in the transaction set exist in a second transaction pool, broadcasting a second signature message to the main verification node and other common verification nodes, wherein the second signature message comprises a second signature transaction set, the second signature transaction set is obtained by the common verification node by signing the transaction set by using a common identification private key of the common verification node, and the second transaction pool is a transaction pool corresponding to the common verification node;
and when the number of the second signature messages received by the main verification node and each common verification node is greater than a preset signature number threshold value, transaction set consensus is achieved.
4. The method of claim 1, wherein when the master authentication node and a plurality of common authentication nodes agree on a set of transactions, the method further comprises:
each verification node in the plurality of verification nodes judges whether the master verification node needs to be updated;
when the master verification node needs to be updated, the step of determining one master verification node and a plurality of common verification nodes from the plurality of verification nodes is executed until the master verification node is determined not to need to be updated.
5. The method of claim 4, wherein each of the plurality of verification nodes determining whether the master verification node needs to be updated comprises:
a first verification node judges whether the transaction set consensus is not reached within a preset time threshold, wherein the first verification node is any one of the verification nodes;
if so, constructing a view switching message, storing and broadcasting the view switching signature message to a second verification node, wherein the view switching signature message is obtained by the first verification node by signing the view switching message by using a common identification private key of the first verification node, the view switching message comprises a view value to be updated, the view value to be updated is a view value in a view switching mechanism plus 1, and the second verification node is the rest verification nodes except the first verification node in the plurality of verification nodes;
for each second verification node, when the second verification node verifies the view switching signature message sent by the first verification node, acquiring the view switching message;
when the number of the nodes acquiring the view switching message in the plurality of verification nodes is larger than a preset node number threshold, determining that the main verification node needs to be updated, and determining the view value to be updated as the view value in the view switching mechanism.
6. The method of claim 3, further comprising:
and when the legal transactions in the transaction set do not exist or partially exist in the second transaction pool, sending a transaction acquisition request to the verification node connected with the common verification node to request to acquire the legal transactions missing in the second transaction pool.
7. The method according to any of claims 1 to 5, wherein prior to determining a master authentication node and a plurality of ordinary authentication nodes from the plurality of authentication nodes, the method further comprises:
and each verification node stores the received at least one legal transaction into a transaction pool corresponding to each verification node.
8. The method of claim 7, wherein each of the authentication nodes stores the received at least one valid transaction in a transaction pool corresponding to each authentication node, comprising:
the method comprises the steps that a verification node connected with a client receives at least one signature transaction message sent by the client, wherein the signature transaction message comprises a signature transaction, and the signature transaction is obtained by the client by utilizing a signature private key of the client to sign transaction data;
performing message verification on the at least one signed transaction message;
when the verification is passed, determining that the transaction data corresponding to the at least one signature transaction message is a legal transaction, and broadcasting the at least one legal transaction to other verification nodes;
and the other verification nodes add the at least one legal transaction to a transaction pool corresponding to each verification node.
9. An apparatus for consensus in a blockchain network comprising a plurality of verification nodes, the apparatus comprising:
a determining module configured to determine a master verification node and a plurality of common verification nodes from the plurality of verification nodes, the plurality of common verification nodes being the rest of the plurality of verification nodes except the master verification node;
a first consensus module configured to perform a transaction set consensus between the main verification node and the plurality of common verification nodes, generating a plurality of latest closed blocks, the transaction set being constructed by the main verification node;
a second consensus module configured to perform block consensus on the plurality of last closed blocks by the main verification node and the plurality of common verification nodes to generate new blocks.
10. A computer device, characterized in that the computer device comprises:
a processor;
a memory for storing executable instructions of the processor;
wherein the processor is configured to perform the block chain network consensus method according to any one of claims 1 to 8.
11. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method of consensus of a blockchain network according to any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010037474.9A CN111275438B (en) | 2020-01-14 | 2020-01-14 | Consensus method, device, equipment and storage medium of block chain network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010037474.9A CN111275438B (en) | 2020-01-14 | 2020-01-14 | Consensus method, device, equipment and storage medium of block chain network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111275438A true CN111275438A (en) | 2020-06-12 |
| CN111275438B CN111275438B (en) | 2023-04-28 |
Family
ID=71001859
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010037474.9A Active CN111275438B (en) | 2020-01-14 | 2020-01-14 | Consensus method, device, equipment and storage medium of block chain network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111275438B (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112884579A (en) * | 2021-02-08 | 2021-06-01 | 京东数科海益信息科技有限公司 | Block chain transaction consensus method and device |
| CN112907369A (en) * | 2021-02-08 | 2021-06-04 | 网易（杭州）网络有限公司 | Block chain-based data consensus method and device, electronic equipment and storage medium |
| CN113269645A (en) * | 2021-05-28 | 2021-08-17 | 中邮信息科技(北京)有限公司 | Transaction information scheduling method, device, medium and electronic equipment for block chain |
| CN113381861A (en) * | 2021-06-16 | 2021-09-10 | 哈尔滨工业大学 | Improved Ripple consensus method suitable for unlicensed chain |
| CN114691687A (en) * | 2021-12-30 | 2022-07-01 | 北京连琪科技有限公司 | Method for verifying block state certification |
| CN115225639A (en) * | 2022-09-15 | 2022-10-21 | 杭州趣链科技有限公司 | Changing method and device of consensus trusted cluster, computer equipment and medium |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106656974A (en) * | 2016-10-17 | 2017-05-10 | 江苏通付盾科技有限公司 | Block chain grouping consensus method and system |
| US20170344987A1 (en) * | 2016-05-24 | 2017-11-30 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees |
| US20180101560A1 (en) * | 2016-10-07 | 2018-04-12 | International Business Machines Corporation | Establishing overlay trust consensus for blockchain trust validation system |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
| US20180240114A1 (en) * | 2017-02-22 | 2018-08-23 | Alibaba Group Holding Limited | Transaction verification in a consensus network |
| US20190173667A1 (en) * | 2016-12-23 | 2019-06-06 | Cloudminds (Shenzhen) Robotics Systems Co., Ltd. | Block generation method, device and blockchain network |
| CN109995536A (en) * | 2019-03-15 | 2019-07-09 | 广州杰赛科技股份有限公司 | A kind of block chain common recognition method, apparatus and readable storage medium storing program for executing |
| CN110597839A (en) * | 2019-09-20 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and storage medium |
| CN110602138A (en) * | 2019-09-26 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Data processing method and device for block chain network, electronic equipment and storage medium |
-
2020
- 2020-01-14 CN CN202010037474.9A patent/CN111275438B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170344987A1 (en) * | 2016-05-24 | 2017-11-30 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees |
| US20180101560A1 (en) * | 2016-10-07 | 2018-04-12 | International Business Machines Corporation | Establishing overlay trust consensus for blockchain trust validation system |
| CN106656974A (en) * | 2016-10-17 | 2017-05-10 | 江苏通付盾科技有限公司 | Block chain grouping consensus method and system |
| US20190173667A1 (en) * | 2016-12-23 | 2019-06-06 | Cloudminds (Shenzhen) Robotics Systems Co., Ltd. | Block generation method, device and blockchain network |
| US20180240114A1 (en) * | 2017-02-22 | 2018-08-23 | Alibaba Group Holding Limited | Transaction verification in a consensus network |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
| CN109995536A (en) * | 2019-03-15 | 2019-07-09 | 广州杰赛科技股份有限公司 | A kind of block chain common recognition method, apparatus and readable storage medium storing program for executing |
| CN110597839A (en) * | 2019-09-20 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and storage medium |
| CN110602138A (en) * | 2019-09-26 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Data processing method and device for block chain network, electronic equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 宋焘谊: "区块链共识算法的比较研究" * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112884579A (en) * | 2021-02-08 | 2021-06-01 | 京东数科海益信息科技有限公司 | Block chain transaction consensus method and device |
| CN112907369A (en) * | 2021-02-08 | 2021-06-04 | 网易（杭州）网络有限公司 | Block chain-based data consensus method and device, electronic equipment and storage medium |
| CN113269645A (en) * | 2021-05-28 | 2021-08-17 | 中邮信息科技(北京)有限公司 | Transaction information scheduling method, device, medium and electronic equipment for block chain |
| CN113269645B (en) * | 2021-05-28 | 2024-05-17 | 中邮信息科技(北京)有限公司 | Transaction information scheduling method and device of blockchain, medium and electronic equipment |
| CN113381861A (en) * | 2021-06-16 | 2021-09-10 | 哈尔滨工业大学 | Improved Ripple consensus method suitable for unlicensed chain |
| CN114691687A (en) * | 2021-12-30 | 2022-07-01 | 北京连琪科技有限公司 | Method for verifying block state certification |
| CN115225639A (en) * | 2022-09-15 | 2022-10-21 | 杭州趣链科技有限公司 | Changing method and device of consensus trusted cluster, computer equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111275438B (en) | 2023-04-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111275438B (en) | Consensus method, device, equipment and storage medium of block chain network | |
| CN108683539B (en) | Block chain network management method, block chain network management device, block chain network management medium and electronic equipment | |
| CN108900364B (en) | Block chain network management method, block chain network management device, block chain network management medium and electronic equipment | |
| CN109361740B (en) | Block generation method, device, equipment and medium of block chain | |
| CN108550037B (en) | File processing method and device based on block chain | |
| US10880285B2 (en) | Self-driving vehicle test authentication | |
| CN108390872B (en) | Certificate management method, device, medium and electronic equipment | |
| CN112714192B (en) | Data synchronization method and device, computer readable medium and electronic equipment | |
| EP4216077A1 (en) | Blockchain network-based method and apparatus for data processing, and computer device | |
| JP2023509889A (en) | Blockchain-based data detection method and device, computer device and program | |
| CN109376534B (en) | Method and apparatus for detecting applications | |
| CN112134883B (en) | Method, device and related product for carrying out rapid authentication on trust relationship between nodes based on trusted computing | |
| CN112070608B (en) | Information processing method, device, medium and electronic equipment | |
| CN112631550A (en) | Block chain random number generation method, device, equipment and computer storage medium | |
| CN112104709A (en) | Intelligent contract processing method, device, medium and electronic equipment | |
| CN112749968B (en) | Service data recording method and device based on block chain | |
| CN113127569A (en) | Consensus method and device for block chain system, electronic equipment and storage medium | |
| CN111679978B (en) | Program testing method, program testing device, electronic equipment and storage medium | |
| CN109005208B (en) | Method and device for pushing information | |
| CN112182113A (en) | Block chain consensus method, system, electronic device and storage medium | |
| CN112132574A (en) | Block chain data checking method, data processing method, device and equipment | |
| CN116723200B (en) | Cluster changing method and device, electronic equipment and computer readable storage medium | |
| CN111310242B (en) | Method and device for generating device fingerprint, storage medium and electronic device | |
| CN113254210A (en) | OFD file signature verification method, system and equipment based on cloud service | |
| CN110322350B (en) | Method, device, equipment and storage medium for cutting hollow block in consensus network |
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 |