CN110995439A - Block chain consensus method, electronic device and storage medium - Google Patents
Block chain consensus method, electronic device and storage medium Download PDFInfo
- Publication number
- CN110995439A CN110995439A CN201911138814.0A CN201911138814A CN110995439A CN 110995439 A CN110995439 A CN 110995439A CN 201911138814 A CN201911138814 A CN 201911138814A CN 110995439 A CN110995439 A CN 110995439A
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- proposal
- verification
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
- H04L2209/463—Electronic voting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Abstract
The invention discloses a block chain consensus method, an electronic device and a storage medium, after the consensus is divided into two mutually independent stages of proposal and verification, when a BFT verification algorithm causes view switching due to network and other reasons, although the BFT verification efficiency is lowered, the proposal stage is still continuously operated, and the speed of generating a proposal block by a packaging transaction is not reduced due to the blockage of verification by a system. If a plurality of proposal blocks are generated in the first stage, the plurality of proposal blocks can be verified at one time in the verification link in the second stage, thereby ensuring the processing performance of the system.
Description
Technical Field
The present invention relates to the field of block chain technologies, and in particular, to a block chain consensus method, an electronic apparatus, and a storage medium.
Background
In a block chain network using a BFT series algorithm as a consensus algorithm, a certain number of certificates are usually collated, and a system selects a plurality of nodes with the largest number of certificates as production nodes to participate in block generation. In a round of BFT algorithm, a chairful node is selected through a fair polling algorithm, and a proposal is initiated, wherein the proposal has a view number of the current round of consensus and a transaction list of the current round of consensus. The other nodes in the network vote on whether the agreed proposal is valid, any one of the production nodes collects a sufficient number (2f +1) of valid votes, and then deems the consensus to be reached, and then submits the block and broadcasts the block to the network. If one node does not agree with the proposal of the chairman node, the message of switching the view number is broadcasted to other common nodes so as to replace the chairman node and reinitiate the proposal.
In the existing consensus algorithm system, the BFT algorithm has the advantages of high consensus efficiency, low resource consumption, etc., but the BFT is easy to switch views due to the problem of network environment, and the efficiency of the consensus algorithm is seriously reduced due to the fact that the views are switched.
Disclosure of Invention
The present invention is directed to solving at least one of the problems of the prior art. Therefore, the invention provides a block chain consensus method, which can improve the efficiency of a consensus algorithm.
In a first aspect, an embodiment of the present invention provides a block chain consensus method, including the following steps:
constructing a consensus node pool;
executing a first stage and a second stage in parallel, wherein the first stage comprises selecting a proposal node from the consensus node pool and generating a proposal block by the proposal node, and the second stage comprises selecting a verification node from the consensus node pool and performing BFT verification on the proposal block by using the verification node;
and judging whether the proposal block passes the verification, if so, generating a final block.
The block chain consensus method according to the embodiment of the present invention at least has the following beneficial effects: after the consensus is divided into two mutually independent stages of proposal and verification, when the BFT verification algorithm causes view switching due to network and other reasons, although the BFT verification efficiency is lowered, the proposal stage is still operated continuously, and the system cannot reduce the speed of generating a proposal block by the packed transaction due to the blockage of verification. If a plurality of proposal blocks are generated in the first stage, the plurality of proposal blocks can be verified at one time in the verification link in the second stage, thereby ensuring the processing performance of the system.
In another specific embodiment of the present invention, the constructing of the consensus node pool comprises the following steps:
the application node sends a transaction application to become a consensus node and passes the certificate to the network mortgage;
the common user sends a transaction to vote for the application node;
counting the votes obtained by all the application nodes on the deadline, and selecting a preset number of application nodes as consensus nodes and adding the consensus nodes into a consensus node pool according to the ranking of the votes obtained from high to low.
In another specific embodiment of the present invention, the selecting a proposal node from the consensus node pool comprises the following steps:
obtaining the VRF value of the last proposal block;
converting a byte array of a preset digit in a VRF value into an index;
and selecting a proposal node in the consensus node pool by using the index.
In another specific embodiment of the present invention, the selecting the verification node from the consensus node pool includes the following steps:
according to the sequence number identified by the BFT in the current round, the remainder is calculated for the verification node number;
and indexing in the consensus node pool by using the remainder, and selecting a preset number of consensus nodes behind the index as the verification nodes in the current round.
In a second aspect, an embodiment of the present invention provides an electronic device, including: memory, processor and computer program stored on the memory and executable on the processor, the processor implementing a method of block chain consensus as described in any of the above first aspects when executing the program.
In a third aspect, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for performing a block chain consensus method as described in any one of the above first aspects.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
The above and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
fig. 1 is a flowchart of a block chain consensus method according to a first embodiment of the present invention;
FIG. 2 is a schematic diagram of a proposed node selection according to a third embodiment of the present invention;
fig. 3 is a schematic diagram of BFT verification node selection according to a fourth embodiment of the present invention;
FIG. 4 is a schematic diagram of a proposal block of a fifth embodiment of the present invention;
fig. 5 is a flowchart illustrating BFT verification on the proposed block according to a sixth embodiment of the present invention;
FIG. 6 is a diagram illustrating a final block according to a seventh embodiment of the present invention;
fig. 7 is a flowchart of a block chain consensus method according to a fifth embodiment of the present invention;
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary only for the purpose of explanation and should not be construed as limiting the invention.
In the description of the present invention, it should be understood that the orientation or positional relationship referred to in the description of the orientation, such as the upper, lower, front, rear, left, right, etc., is based on the orientation or positional relationship shown in the drawings, and is only for convenience of description and simplification of description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus, should not be construed as limiting the present invention.
In the description of the present invention, the meaning of a plurality of means is one or more, the meaning of a plurality of means is two or more, and larger, smaller, larger, etc. are understood as excluding the number, and larger, smaller, inner, etc. are understood as including the number. If the first and second are described for the purpose of distinguishing technical features, they are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated or implicitly indicating the precedence of the technical features indicated.
In the description of the present invention, unless otherwise explicitly limited, terms such as arrangement, installation, connection and the like should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in the present invention in combination with the specific contents of the technical solutions.
Interpretation of terms:
consensus: consensus is a core concept in blockchains. Refers to the process by which a group of computer nodes on a network agree upon a decision to produce a consistent action.
Byzantine error Byzantine Fault: byzantine error is a problem that in point-to-point network communication, a node fails to send a message, or a malicious node intentionally generates an error message to mislead other nodes, so that the network cannot achieve consensus or achieves wrong consensus.
The Byzantine error stems from the problem of the Byzantine general. Bzastidine is located in today's Turkey Istembul, the capital of the east Roman empire. Because the world of the Byzantine Roman empire is wide at that time, in order to achieve the purpose of defense, each army is far separated, and messages can be transmitted between general and general only by means of confidence difference. In the war, all general and officers in the Byzantine army must agree to a consensus to decide whether there is a chance to win to fight the enemy's battle. However, there is a possibility that traitors and enemy spys may be present within the military, again disrupting the overall military's order to the left and right of the military's decision. In making consensus, the results do not represent the opinion of most people. At this time, the byzantine problem has developed as a result of how the remaining loyal general agreed to the agreement without the influence of traitors, knowing that there are membership conspiracy.
Byzantine fault-tolerant algorithm: (BFT) Byzantine factory Tolerance. The method is a consensus algorithm for achieving consensus by mutually voting among nodes.
Practical Byzantine fault-tolerant algorithm: (PBFT) Practical Byzantine Fault Tolerance. Is an algorithm proposed in 1999 by MiguelCastro and barbarbarara Liskov to solve the inefficiency of the original byzantine fault-tolerant algorithm.
Verifiable random number: (VRF) Verifiable Random Function. Is an encryption scheme that maps an input to a verifiable pseudorandom output.
The chairman node: i.e. Primary node, is a node in the BFT algorithm for initiating a voting proposal.
Trading: i.e., (Tx) transactions, are basic business units on the blockchain, and each Transaction completes a business operation, such as a transfer, etc.
A transaction pool: namely Tx Pool, is a functional module in the node that accepts the transaction on the network and verifies the validity of the transaction.
And (3) node mortgage: to become a consensus node, a certain number of certificates need to be deposited on the blockchain network to qualify as a consensus node.
In the existing consensus algorithm system, the BFT algorithm has the advantages of high consensus efficiency, low resource consumption, etc., but the BFT is easy to switch views due to the problem of network environment, and the efficiency of the consensus algorithm is seriously reduced due to the fact that the views are switched. Meanwhile, in order to reduce the message amount of the consensus nodes, the BFT algorithm usually selects a few nodes to participate in the block generation in a node mortgage manner, which easily causes centralization of the system, increases the possibility of collusion and malignance of system nodes, and reduces the security of the system.
Based on this, the invention divides the consensus algorithm into a first stage and a second stage which are parallel, wherein the first stage only carries out proposal to generate a proposal block; and in the second stage, BFT verification is carried out on the proposed block generated in the first stage, a formal block is generated after the verification is passed, and the generated block is broadcasted outwards.
While the following text sets forth a number of different embodiments or examples for implementing different aspects of the invention, it should be understood that the following description is intended to be illustrative only and is not intended to be limiting.
Referring to fig. 1, a flowchart of a block chain consensus method according to a first embodiment of the present invention is provided, in which a block chain consensus method is provided, including the following steps:
constructing a consensus node pool;
executing a first stage and a second stage in parallel, wherein the first stage comprises the steps of selecting a proposal node from the consensus node pool, generating a proposal block by the proposal node, and adding the generated proposal block into the proposal block pool because the generation speed of the proposal block is inconsistent with the verification speed; selecting a verification node from the consensus node pool, selecting a proposal block from the proposal block pool, and performing BFT verification on the proposal block by using the verification node;
and judging whether the proposal block passes the verification, if so, generating a final block, chaining the final block, and deleting the chained proposal block from the proposal block pool.
For the above embodiment, it is determined whether the proposed block passes the verification, if not, a new round of BFT verification is started, and a proposed block is selected from the proposed block pool and BFT verification is performed on the proposed block by using the verification node until the proposed block passes the verification, a final block is generated, the final block is linked, and the linked proposed block is deleted from the proposed block pool.
The consensus algorithm is divided into a first stage and a second stage which are parallel, the first stage only carries out proposal, and a proposal block is generated; and in the second stage, BFT verification is carried out on the proposed block generated in the first stage, a formal block is generated after the verification is passed, and the generated block is broadcasted outwards. After the consensus is divided into two mutually independent nodes, namely proposal and verification, when the BFT verification algorithm causes view switching due to network and other reasons, although the BFT verification efficiency is lowered, the proposal stage is still operated continuously, and the system cannot reduce the speed of generating the proposal block by the packed transaction due to the blockage of the verification. If a plurality of proposal blocks are generated in the first stage, the plurality of proposal blocks can be verified at one time in the verification link in the second stage, thereby ensuring the processing performance of the system.
A second embodiment of the present invention provides a block chain consensus method, where the constructing of a consensus node pool in this embodiment includes the following steps:
the application node sends a transaction application to become a consensus node and passes the certificate to the network mortgage;
the common user sends a transaction to vote for the application node;
counting the votes obtained by all the application nodes on the deadline, and selecting a preset number of application nodes as consensus nodes and adding the consensus nodes into a consensus node pool according to the ranking of the votes obtained from high to low.
Each node on the network is considered as an ordinary user, when the ordinary users send transaction applications to become consensus nodes and pass certificates to the network at low voltage, the common users are considered as application nodes, the application nodes obtain high votes in voting and are selected to become consensus nodes, the consensus nodes are added into a consensus node pool, and the consensus nodes in the consensus node pool participate in proposal and BFT verification.
In this embodiment, the node sends a transaction application to become a consensus node, and a certain amount of certificates need to be deposited on the network when applying for the consensus node. When the consensus node has a behavior of doing malice, the mortgage is punished, and the mortgage is used as an economic punishment measure to maintain the network; the common user sends a transaction to vote for the application node; and counting the number of votes obtained by all the application nodes when the application nodes arrive at the deadline date, and selecting a certain number of nodes as the consensus nodes of the current round of the consensus period according to the sequence of the number of votes obtained from high to low.
Referring to fig. 2, a schematic diagram of a proposed node selection according to a third embodiment of the present invention is shown, where the third embodiment of the present invention provides a block chain consensus method, where the selecting a proposed node from the consensus node pool in this embodiment includes the following steps:
obtaining the VRF value of the last proposal block;
converting a byte array of a preset digit in a VRF value into an index;
and selecting a proposal node in the consensus node pool by using the index.
Specifically, the VRF value is a 32-byte array based on the VRF value of the last proposal block. And converting the byte array of a certain number of the front digits of the VRF value into a number, and using the number as an index to select the main proposal node in the consensus node pool. Examples are: if 32 nodes are shared in the consensus node pool, at least a byte array of the first 5 bytes (the power of 5 of 2 is equal to 32) needs to be selected in the VRF, and if a byte array of more than 5 bytes, such as 6 bytes (the maximum number that the array of 6 bytes can represent is 64, and the power of 6 of 2), the total number of the nodes needs to be complemented by numbers, so that the obtained index is ensured to fall within the range of the consensus node pool;
similarly, a byte array with a certain number of digits behind the byte array selected by the VRF main proposal node is selected as an index, and the alternative proposal node is selected;
and each consensus node can do the operations, and the current node is compared with the public keys of the selected main proposal node and the selected alternative nodes to determine whether the current node is the main proposal node, the alternative proposal node or the common node. Only the main proposal node and the alternative proposal nodes can participate in the proposal operation of the current block, and the block proposed by the common node cannot be accepted by the network;
if the current node is the main proposal node of the block, starting to propose the block and broadcasting the proposed block to other consensus nodes;
if the current node is the alternative proposal node and the proposal block sent by the main proposal node is not received after a certain time from the beginning of the block proposal, the alternative node starts the proposal block and broadcasts the proposal block to other common nodes.
In order to reduce the message amount of the consensus nodes, the traditional BFT algorithm usually selects a few nodes to participate in the block in a node mortgage mode, so that the system centralization is easily caused, the possibility that the system nodes collude and do malice is increased, and the safety of the system is reduced. In the embodiment, the proposal node is randomly selected by adopting the VRF algorithm, so that the possibility that a plurality of consensus nodes collude and do malice can be reduced, and the safety of the system is improved.
Referring to fig. 3, a schematic diagram of selecting a BFT verification node according to a fourth embodiment of the present invention is shown, where the fourth embodiment of the present invention provides a block chain consensus method, and in this embodiment, selecting a verification node from a consensus node pool includes the following steps:
according to the sequence number identified by the BFT in the current round, the remainder is calculated for the verification node number;
and indexing in the consensus node pool by using the remainder, and selecting a preset number of consensus nodes behind the index as the verification nodes in the current round.
Specifically, the number of BFT verification nodes is complemented according to the sequence number commonly identified by the current round of BFT; indexing in the consensus node pool by using the remainder, selecting a certain number of nodes after the index as the BFT verification nodes in the current round, and if the number of the nodes after the index is not enough, selecting the rest nodes from the head
Referring to fig. 4 and 7, fig. 4 is a schematic diagram of a proposal block according to a fifth embodiment of the present invention, the fifth embodiment of the present invention provides a block chain consensus method, in which the generation of a proposal block by the proposal node in this embodiment includes the following steps:
adding one to the block height based on the current block height;
setting the hash of the last proposal block of the proposal blocks as the hash of the current block, and connecting the hash of the last proposal block with the hash of the current block;
setting a proposal block timestamp as the current time;
setting a proposal person of the proposal block as a current node;
the proposal node uses the height of the last block plus the public key of the current proposal node as the seed data of the VRF to produce a VRF value and a VRF certificate, and the VRF value and the VRF certificate are placed on the head of the proposal block. The newly produced VRF value is used for determining the proposal node of the next proposal block, and the VRF proof is used for other nodes to verify the correctness of the currently newly generated VRF value, thereby ensuring that the selection of the next proposal node is not controlled by anyone.
Extracting transactions from a local transaction pool, packaging the transactions into a proposal block, and generating a transaction root according to a packaged transaction list;
the proposal node executes the packaged transaction and generates a state root according to the execution result, the state root is used for uniquely describing the state of the whole block chain ledger after all transactions in the current proposal block are executed, and whether the ledger data of different nodes are completely consistent can be confirmed by comparing the state roots;
the current node signs the generated proposal block by using a private key of the current node and attaches signature data to the proposal block;
the proposal node broadcasts the generated proposal block;
after receiving the proposal block, the other common identification nodes verify the validity of the proposal block, and the verification content comprises the following steps: whether the submitter of the proposal block is a legal submitter of the current height; verifying whether the newly produced VRF value is correct or not by using VRF certification on a proposal block; the current proposal height is the previous height plus one; whether the timestamp of the proposal block is greater than the last proposal block; whether the transaction root of the proposal block is correct; finally, executing all transactions in the proposal block, generating a state root, and comparing the state root with the state root on the proposal block to determine whether the state root is consistent; if any of the verifications fail, the generated proposal block is discarded.
Referring to fig. 5, which is a flowchart of performing BFT verification on the proposed block according to the sixth embodiment of the present invention, the sixth embodiment of the present invention provides a block chain consensus method, where performing BFT verification on the proposed block in this embodiment includes the following steps:
initializing view number V to 0;
the block height of a block to be verified (if a plurality of blocks with verification exist, the height of the first block is taken out) H plus the view number V is used for solving the balance of the number N of BFT verification nodes, and the chaise length node P of BFT verification is determined;
the chairman node packs a local proposal block Pb (possibly a plurality of proposal blocks), attaches additional data of the proposal such as the initial height of the proposal block, the current BFT consensus round number, the view number and the like to generate a verification Request message Request, and finally signs the verification message by using the private key of the chairman node and attaches the verification message.
Broadcasting a verification request message by a chairman node, simultaneously setting a timer, broadcasting a ViewChange message if consensus is not achieved after the timer expires, adding necessary information of current consensus on the ViewChange message, such as the number of the current consensus, adding one to the current view number, and simultaneously carrying a signature of a node on the ViewChange message;
meanwhile, the common BFT verification node N (non-chaudged node) starts a timer, and after the timer expires, if no consensus is achieved, the common BFT verification node N broadcasts a ViewChange message
And after receiving the proposal verification message Request sent by the agenda, the common verification node verifies the correctness of the Request message. The verification content comprises that whether the sending of the verification message Request is a chairman node of the current round or not; whether the initial height of the proposal block with verification is correct or not; if the verification fails, broadcasting a ViewChange message; and simultaneously verifying whether the proposal block exists in a local proposal block pool or not, if so, broadcasting a verification passing message Response which carries the round number, the view number and the hash of the verification request message of the current BFT and the signature information of the node. If the local proposal block pool does not have the proposal block in the request, waiting, synchronizing the block to other common nodes until a set timer is overtime, and sending a ViewChange message;
the common BFT verifies that the node receives 2f +1 Response verification passing messages, after the chairman node receives 2f Response messages, the node enters a Prepared state at the moment, and then broadcasts a verification confirmation Commit message, wherein the Commit message comprises basic information such as the number of the current consensus round, a view number, the Hash of a verification request message Requuset and the like, the signature of a Commit message sender on a proposal block and the signature information of a Commit message sender;
after all nodes receive 2f +1 Commit verification confirmation messages, the network is considered to have agreed, the Committed state is entered, then transaction execution results in the proposal block are submitted to a local database, signature information of the proposal block in the Commit message is collected, the collected signature information is attached to the proposal block to generate a final block, and a newly generated block is broadcasted to the network;
before the nodes reach consensus, if 2f +1 ViewChange messages are received and the new View numbers ViewNumbers are consistent, the current View number View is switched to the new number, a new chairman node P is reselected under the new View number, a BFT verification Request message Request is retransmitted, and the consensus is restarted. While the consensus node will discard BFT messages with a lower number than the current view. And simultaneously resetting a timer by the node, wherein the overtime time of the timer is doubled compared with the time under the last view number.
Referring to fig. 6, which is a schematic diagram of a final block according to a seventh embodiment of the present invention, the seventh embodiment of the present invention provides a block chain consensus method, wherein the generating of the final block in the embodiment includes the following steps:
the consensus node collects the signatures for the proposal block carried in 2f +1 Commit messages, appends these signatures to the proposal block, and adds the basic information of the current consensus round: if the number of the consensus round is numbered, the BFT verification node public key and the public key information of the next round of BFT verification node form a final block;
the nodes submit the newly generated blocks to a local account book and broadcast the blocks to the network;
all nodes, including the common identification node and the synchronization node, receive the new blocks broadcasted, and can confirm the validity of the blocks by verifying the public key signature carried on the blocks.
The embodiments of the present invention have been described in detail with reference to the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge of those skilled in the art without departing from the gist of the present invention.
Claims (6)
1. A block chain consensus method, comprising:
constructing a consensus node pool;
executing a first stage and a second stage in parallel, wherein the first stage comprises selecting a proposal node from the consensus node pool and generating a proposal block by the proposal node, and the second stage comprises selecting a verification node from the consensus node pool and performing BFT verification on the proposal block by using the verification node;
and judging whether the proposal block passes the verification, if so, generating a final block.
2. The method according to claim 1, wherein said constructing a consensus node pool comprises:
the application node sends a transaction application to become a consensus node and passes the certificate to the network mortgage;
the common user sends a transaction to vote for the application node;
counting the votes obtained by all the application nodes on the deadline, and selecting a preset number of application nodes as consensus nodes and adding the consensus nodes into a consensus node pool according to the ranking of the votes obtained from high to low.
3. The method of claim 1, wherein said selecting a proposal node from the pool of consensus nodes comprises:
obtaining the VRF value of the last proposal block;
converting a byte array of a preset digit in a VRF value into an index;
and selecting a proposal node in the consensus node pool by using the index.
4. The method of claim 1, wherein said selecting the verification node from the consensus node pool comprises:
according to the sequence number identified by the BFT in the current round, the remainder is calculated for the verification node number;
and indexing in the consensus node pool by using the remainder, and selecting a preset number of consensus nodes behind the index as the verification nodes in the current round.
5. An electronic device, comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein: the processor, when executing the program, implements a blockchain consensus method according to any one of claims 1 to 4.
6. A computer-readable storage medium storing computer-executable instructions, characterized in that: the computer-executable instructions are for performing a blockchain consensus method as recited in any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911138814.0A CN110995439A (en) | 2019-11-20 | 2019-11-20 | Block chain consensus method, electronic device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911138814.0A CN110995439A (en) | 2019-11-20 | 2019-11-20 | Block chain consensus method, electronic device and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110995439A true CN110995439A (en) | 2020-04-10 |
Family
ID=70085183
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911138814.0A Pending CN110995439A (en) | 2019-11-20 | 2019-11-20 | Block chain consensus method, electronic device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110995439A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111556133A (en) * | 2020-04-26 | 2020-08-18 | 布比（北京）网络技术有限公司 | Block chain consensus method and system, computer storage medium and electronic equipment |
| CN111666343A (en) * | 2020-06-12 | 2020-09-15 | 武汉斗鱼鱼乐网络科技有限公司 | Data uplink method, device and readable storage medium based on consensus mechanism |
| CN112182113A (en) * | 2020-10-23 | 2021-01-05 | 网易（杭州）网络有限公司 | Block chain consensus method, system, electronic device and storage medium |
| CN113824737A (en) * | 2021-11-22 | 2021-12-21 | 中国信息通信研究院 | Data processing method and device based on double certificates, block chain and storage medium |
| CN114389815A (en) * | 2021-12-06 | 2022-04-22 | 北京众享比特科技有限公司 | Method for electing nodes in a blockchain network and related product |
| CN114422155A (en) * | 2022-03-30 | 2022-04-29 | 杭州趣链科技有限公司 | Proposal consensus execution method, block chain system, device and storage medium |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN109005191A (en) * | 2018-08-31 | 2018-12-14 | 中国联合网络通信集团有限公司 | A kind of verification method and system, arbitration node, storage medium |
| CN109447810A (en) * | 2018-11-29 | 2019-03-08 | 杭州秘猿科技有限公司 | Parallel block chain common recognition method, system, electronic equipment and computer readable storage medium |
| CN110222537A (en) * | 2019-06-17 | 2019-09-10 | 北京艾摩瑞策科技有限公司 | Verification method and device applied to block chain link |
| CN110288479A (en) * | 2019-06-28 | 2019-09-27 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
| CN110289966A (en) * | 2019-06-19 | 2019-09-27 | 西南交通大学 | Anti-adaptive attack alliance's chain common recognition method based on Byzantine failure tolerance |
| US20190318338A1 (en) * | 2018-04-13 | 2019-10-17 | International Business Machines Corporation | Network node management on a blockchain |
-
2019
- 2019-11-20 CN CN201911138814.0A patent/CN110995439A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190318338A1 (en) * | 2018-04-13 | 2019-10-17 | International Business Machines Corporation | Network node management on a blockchain |
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN109005191A (en) * | 2018-08-31 | 2018-12-14 | 中国联合网络通信集团有限公司 | A kind of verification method and system, arbitration node, storage medium |
| CN109447810A (en) * | 2018-11-29 | 2019-03-08 | 杭州秘猿科技有限公司 | Parallel block chain common recognition method, system, electronic equipment and computer readable storage medium |
| CN110222537A (en) * | 2019-06-17 | 2019-09-10 | 北京艾摩瑞策科技有限公司 | Verification method and device applied to block chain link |
| CN110289966A (en) * | 2019-06-19 | 2019-09-27 | 西南交通大学 | Anti-adaptive attack alliance's chain common recognition method based on Byzantine failure tolerance |
| CN110288479A (en) * | 2019-06-28 | 2019-09-27 | 深圳市网心科技有限公司 | A kind of the common recognition method and relevant device of block chain data |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111556133A (en) * | 2020-04-26 | 2020-08-18 | 布比（北京）网络技术有限公司 | Block chain consensus method and system, computer storage medium and electronic equipment |
| CN111556133B (en) * | 2020-04-26 | 2023-03-14 | 布比（北京）网络技术有限公司 | Block chain consensus method and system, computer storage medium and electronic equipment |
| CN111666343A (en) * | 2020-06-12 | 2020-09-15 | 武汉斗鱼鱼乐网络科技有限公司 | Data uplink method, device and readable storage medium based on consensus mechanism |
| CN111666343B (en) * | 2020-06-12 | 2022-05-10 | 武汉斗鱼鱼乐网络科技有限公司 | Common-identification-mechanism-based data uplink method, device and readable storage medium |
| CN112182113A (en) * | 2020-10-23 | 2021-01-05 | 网易（杭州）网络有限公司 | Block chain consensus method, system, electronic device and storage medium |
| CN113824737A (en) * | 2021-11-22 | 2021-12-21 | 中国信息通信研究院 | Data processing method and device based on double certificates, block chain and storage medium |
| CN114389815A (en) * | 2021-12-06 | 2022-04-22 | 北京众享比特科技有限公司 | Method for electing nodes in a blockchain network and related product |
| CN114422155A (en) * | 2022-03-30 | 2022-04-29 | 杭州趣链科技有限公司 | Proposal consensus execution method, block chain system, device and storage medium |
| WO2023184881A1 (en) * | 2022-03-30 | 2023-10-05 | 杭州趣链科技有限公司 | Proposal consensus execution method, blockchain system, device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110995439A (en) | Block chain consensus method, electronic device and storage medium | |
| Chen et al. | Algorand agreement: Super fast and partition resilient byzantine agreement | |
| Gilad et al. | Algorand: Scaling byzantine agreements for cryptocurrencies | |
| Garay et al. | The bitcoin backbone protocol: Analysis and applications | |
| JP6883106B2 (en) | Distributed systems, message processing methods, nodes, clients and storage media | |
| CN108667614B (en) | Byzantine fault-tolerant method and implementation system thereof | |
| CN110198213B (en) | System based on secret shared random number consensus algorithm | |
| CN110796547A (en) | Improved practical Byzantine fault-tolerant system based on alliance block chain | |
| Sheng et al. | BFT protocol forensics | |
| CN112257095B (en) | Method for selecting alliance chain consensus node | |
| WO2021135934A1 (en) | Blockchain accounting method and apparatus, node and storage medium | |
| CN113612604B (en) | Asynchronous network-oriented safe distributed random number generation method and device | |
| CN113098694A (en) | Hybrid cross-chain consensus method | |
| CN113326516A (en) | Block chain consensus method, block chain system and computer equipment | |
| US20200204351A1 (en) | Method for information confirmation in distributed systems using hybrid byzantine agreement | |
| CN113132401A (en) | Data processing method and device based on block chain | |
| TW202034656A (en) | Method for generating secure randomness on blockchain | |
| CN113660125B (en) | Consensus method and device based on random trusted committee | |
| CN111414420A (en) | Improved PBFT block chain consensus method | |
| CN109685505A (en) | Byzantine failure tolerance common recognition optimization method based on association ring signatures | |
| CN113660272A (en) | Asynchronous consensus method and device for anti-Byzantine sequencing | |
| CN110445795A (en) | A kind of block chain certification uniqueness confirmation method | |
| CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
| CN116614519A (en) | Video and related information lightweight trusted uplink method based on optimization consensus algorithm | |
| Kuo et al. | Fair Byzantine agreements for blockchains |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200410 |
|
| RJ01 | Rejection of invention patent application after publication |