CN112991067B - Block chain consensus method, device and system - Google Patents
Block chain consensus method, device and system Download PDFInfo
- Publication number
- CN112991067B CN112991067B CN202110462870.0A CN202110462870A CN112991067B CN 112991067 B CN112991067 B CN 112991067B CN 202110462870 A CN202110462870 A CN 202110462870A CN 112991067 B CN112991067 B CN 112991067B
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- transaction
- contract
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000012790 confirmation Methods 0.000 claims abstract description 91
- 230000008859 change Effects 0.000 claims abstract description 85
- 230000000977 initiatory effect Effects 0.000 claims abstract description 14
- 230000000694 effects Effects 0.000 claims description 23
- 238000010200 validation analysis Methods 0.000 claims description 8
- 230000002159 abnormal effect Effects 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 3
- 238000012795 verification Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 238000012545 processing Methods 0.000 description 8
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
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
- 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Technology Law (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The specification discloses a block chain consensus method, a block chain consensus device and a block chain consensus system, wherein the block chain consensus method is applied to a block chain system in a pipeline mode, and the block chain consensus method comprises the following steps: the consensus main node generates a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change; the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a block aiming at the transaction of the contract changed by the invoking node; and if the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
Description
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, and a system for blockchain consensus.
Background
A federation chain is typically maintained collectively by federation-designated nodes, with multiple nodes collectively recording transactions on the chain. Usually, a block on the chain records a batch of transactions, and the generation of the block often needs to go through the following processes: collect transaction → deal consensus → deal execution → write block. In most of the existing implementations of alliance chain, a node performs the four-stage process for the next block after completing the four stages for the previous block. For the above situation, an optimization scheme is to perform pipelined transformation on the above four stages, such as transforming each of the above four stages into: collect transaction pipeline → transaction consensus pipeline → transaction execution pipeline → write block pipeline. In this way, after each pipeline completes the corresponding processing of the previous block, the processing flow of the next block can be performed, and the generation flow of the previous block does not need to be completely completed.
In this case, node changes such as node addition, node deletion, or node information update occur in the federation chain, and the changed node may not be able to act on the block being generated immediately, but rather act late. Therefore, it is desirable to provide a feasible consensus scheme applicable to changed nodes.
Disclosure of Invention
The embodiment of the specification provides a block chain consensus method, a block chain consensus device and a block chain consensus system.
In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:
in a first aspect, a block chain consensus method is provided, which is applied to a block chain system in a pipeline manner, and includes:
the consensus main node generates a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a block aiming at the transaction of the contract changed by the invoking node;
and if the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
In a second aspect, an electronic device is provided, including:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
receiving confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a blocky for the transaction of the contract changed by the calling node;
and if receiving confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
In a third aspect, a computer-readable storage medium is presented, the computer-readable storage medium storing one or more programs that, when executed by an electronic device that includes a plurality of application programs, cause the electronic device to:
generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
receiving confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a blocky for the transaction of the contract changed by the calling node;
and if receiving confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
In a fourth aspect, a consensus device in a pipeline manner is provided, including:
the block generating module is used for generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
the receiving module is used for receiving confirmation messages sent by other common identification nodes in the blockchain system, and the confirmation messages are used for confirming that the common identification nodes sending the confirmation messages generate blocks aiming at the transaction of the contract changed by the calling node;
and the consensus module is used for initiating consensus operation of a target proposal to the consensus node after the transaction of the contract changed by the calling node is validated if receiving confirmation messages sent by at least 2f other consensus nodes, wherein the target proposal is the proposal after the transaction of the contract changed by the calling node is validated.
In a fifth aspect, a pipeline block chain system is provided, which includes: a consensus master node is established, wherein,
the consensus main node generates a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus nodes sending the confirmation messages generate blocks aiming at the transaction of the contracts changed by the calling nodes;
and if the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, initiating consensus operation of a target proposal to the consensus node after the transaction of the contract changed by the calling node takes effect, wherein the target proposal is the proposal after the transaction of the contract changed by the calling node takes effect.
The embodiment of the specification can achieve at least the following technical effects by adopting the technical scheme:
based on the solution of the embodiment of the present specification, after generating a block corresponding to a first proposal of a transaction of a contract involving a change of a call node, a consensus node in a pipeline-type blockchain system can send a confirmation message to a consensus master node, where the consensus master node, after receiving confirmation messages sent by at least 2f other consensus nodes, initiates a consensus operation of a target proposal to the consensus node after the transaction of the contract involving the change of the call node takes effect, where the target proposal is a proposal after the transaction of the contract involving the change of the call node takes effect, so that after the target proposal achieves consensus in the blockchain system, the consensus operation is performed on the proposal after the target proposal based on the consensus node after the transaction of the contract involving the change of the call node takes effect. According to the scheme, after the transaction of the contract of the calling node change is blocked in 2f +1 common identification nodes in the blockchain system, a pair of interactions of confirmation messages of the transaction blocking of the contract of the calling node change is added in the blockchain system, the time for the contract of the calling node change to take effect is effectively determined, and the effectiveness of the node change is further ensured.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:
FIG. 1 is a schematic diagram illustrating a process for generating blocks in a federation chain according to the prior art;
fig. 2 is a schematic diagram of a pipelined block generation scheme provided in an embodiment of the present disclosure;
fig. 3 is a schematic flow chart illustrating an implementation of a block chain consensus method according to an embodiment of the present disclosure;
FIG. 4 is a block chain system in a pipeline manner according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of a pipeline-type consensus device according to an embodiment of the present disclosure.
Detailed Description
In order to make the purpose, technical solutions and advantages of this document more clear, the technical solutions of this specification will be clearly and completely described below with reference to specific embodiments of this specification and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of this document, and not all embodiments. All other embodiments obtained by a person skilled in the art without making any inventive step based on the embodiments in this description belong to the protection scope of this document.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
As described in the background, the generation process of a tile in a tile chain typically includes four operations: 1. collecting transaction, 2, transaction consensus, 3, transaction execution, 4, writing block. Currently, in most alliance chains, only one operation can be performed at a time during the process of processing collected transactions to generate blocks. Fig. 1 is a schematic diagram of a block generation process in a blockchain according to the prior art, as shown in fig. 1, which is one operation of transaction collection, transaction consensus, transaction execution and block generation.
In order to solve the problem of low block generation efficiency caused by the situation in fig. 1, in the consensus algorithm scenario with the consensus master node, since not all consensus nodes will perform the step of collecting transactions, the 3 stages except the collecting transactions can be streamlined. If each of the three stages is modified into: transaction consensus pipeline → transaction execution pipeline → write block pipeline. In this way, after each pipeline completes the corresponding processing of the previous block, the processing flow of the next block can be performed without waiting for the generation flow of the previous block to be completely completed. Fig. 2 is a schematic diagram of a pipelined block generation scheme according to an embodiment of the present disclosure. In fig. 2, for simplicity, it is assumed that the time spent for each proposed consensus operation and other operations is consistent (often inconsistent in practice). Block N is generated based on the nth proposed write block reaching consensus, block N +1 is generated based on the N +1 th proposed write block reaching consensus, block N +2 is generated based on the N +2 th proposed write block reaching consensus, and block N +3 is generated based on the N +3 th proposed write block reaching consensus.
The generation process of the block N to the block N +2 shown in FIG. 2 is as follows:
(1) and carrying out consensus operation on the Nth proposal by a consensus node in the block chain through the transaction consensus pipeline.
(2) Carrying out consensus operation on the (N + 1) th proposal by a consensus node in the block chain through a transaction consensus pipeline; at the same time, the node performs the transaction execution operations on the Nth agreed-upon proposal in parallel through the transaction execution pipeline. It should be appreciated that to avoid conflict between resources performing the same operation in the consensus node, the transaction consensus pipeline of the consensus node performs the consensus operation on the N +1 th proposal at this time, after the consensus operation has been completed on the nth proposal.
(3) Performing consensus operation on the (N + 2) th proposal by a consensus node in the block chain through a transaction consensus pipeline; meanwhile, the consensus node performs transaction execution operations on the (N + 1) th consensus proposal in parallel through the transaction execution pipeline; meanwhile, the consensus node writes the block data generated after the Nth proposal is executed into the persistent storage in parallel through the write block pipeline. It should be understood that to avoid conflict between resources performing the same operation in the consensus node, the transaction consensus pipeline of the consensus node performs the consensus operation on the N +2 th proposal at this time, after the consensus operation has been completed on the N +1 th proposal; the transaction execution pipeline performs the transaction execution operation on the N +1 st consensus proposal after the transaction execution operation has been completed on the Nth consensus proposal.
(4) Carrying out consensus operation on the (N + 3) th proposal by a consensus node in the block chain through a transaction consensus pipeline; meanwhile, the consensus node performs transaction execution operations on the (N + 2) th agreed proposal in parallel through the transaction execution pipeline; meanwhile, the consensus node writes the block data generated after the (N + 1) th proposal is executed into the persistent storage in parallel through the write block pipeline. It should be understood that to avoid conflict between resources performing the same operation in the consensus node, the transaction consensus pipeline of the consensus node performs the consensus operation on the N +3 th proposal at this time, after the consensus operation has been completed on the N +2 th proposal; the transaction execution pipeline performs the transaction execution operation on the N +2 th consensus proposal after the transaction execution operation has been completed on the N +1 th consensus proposal; the proposed write block operation after the write block pipeline performs the operation on the (N + 1) th transaction is after the proposed write block operation after performing the operation on the nth transaction has completed.
By analogy, block N +1, block N +2 … …, and so on are generated in sequence.
It should be appreciated that in the embodiment shown in FIG. 2 described above, it is often desirable for the time period of each operation to be consistent for each proposal.
However, in the pipelined scheme of FIG. 2, the block number corresponding to the block being written to may lag behind the block number corresponding to the block being identified. As mentioned previously, it is assumed in FIG. 2 that the elapsed time for each proposed consensus operation and other operations is consistent, and in practice often inconsistent. In the process, node change conditions such as node addition, node deletion or node information update occur in the federation chain. Generally, the node change takes effect after the block writing is completed, but each current ongoing pipeline operation is still executed according to the original node condition and should not be changed.
In addition, the last pipeline operation executed by using the old consensus node condition should use the same consensus node in the next pipeline instead of using the changed consensus node. That is, the changed consensus node cannot or should not act on the block being generated immediately, for example, when the different consensus nodes generate blocks at different speeds, and therefore the consensus node change should act after a time delay. Meanwhile, as a blockchain network serves as a distributed database, it is necessary to keep storing the same blockchain account book at each consensus node. Different consensus nodes need to enable the same changed node configuration starting from the same block, otherwise it may result in inconsistent accounts on different consensus nodes.
In view of this, an implementation flow diagram of a block chain consensus method provided in one or more embodiments of the present specification is shown in fig. 3, and includes:
at step 310, the consensus master node generates a first block corresponding to a first offer, the first offer including a transaction to invoke a contract for a node change.
The alliance administration account number in the block chain generally has the authority of maintaining node change. After the block chain platform code of the block chain is started, when the node change is needed, the transaction for calling the node change contract can be submitted by the governance account number of the block chain. In the transaction of the contract for invoking the node change, the contract for deploying the node change can be invoked, and operations such as addition, deletion, information update and the like of the consensus node are performed in the block chain. By initiating a transaction that invokes a contract for a node change, events for the node change can be credited in the blockchain, and each consensus node can be made to perform the transaction and take effect on the same block, i.e., each consensus node takes effect on changes to the node at the same pace. A transaction is initiated that invokes a contract for a node change, and information related to the node change may be included in parameters of the transaction. In general, a federation governance account in a blockchain may be an account with administrative privileges.
Optionally, the contract for the node change is used to drive a consensus node in the blockchain system to perform an operation of the node change validation based on a transaction invoking the contract for the node change.
Optionally, the transaction of the contract invoking the node change includes change information of at least one consensus node in the blockchain system.
Wherein the change information of at least one consensus node in the blockchain system comprises at least one of the following:
deleting at least one consensus node in the blockchain system;
updating information of at least one consensus node in the blockchain system;
changing at least one non-common node in a blockchain system into a common node in the blockchain system;
adding at least one node outside the blockchain system as a consensus node into the blockchain system.
Specifically, the role of the original consensus master node may be changed, for example, the previous consensus master node may be changed to a consensus backup node, and one of the consensus backup nodes is reselected as the consensus master node. Or, the configuration information such as the IP address, the public and private key pair and the like in at least one common node in the block chain can be updated.
It should be noted that the consensus algorithm in the embodiments of the present specification may include at least one of a random, a Practical Byzantine Fault Tolerance (PBFT), a BFT-SMaRt (chinese name: performance improvement of a state machine replication scheme based on Byzantine Fault Tolerance), and other consensus algorithms with a consensus master node. The block generation flow of the pipeline-type blockchain system corresponding to the consensus algorithm with consensus master nodes is shown in fig. 2.
Taking the consensus algorithm as PBFT for example, the consensus master node in the blockchain system initiates consensus on the first proposal in the blockchain, and specifically may send the first proposal to a plurality of consensus backup nodes in the blockchain. And if the consensus backup node or the consensus backup node receives effective votes of not less than 2f +1 nodes for the first proposal, the consensus master node and the consensus backup node successfully achieve the consensus operation on the first proposal in the blockchain system, wherein f is the maximum number of allowed abnormal consensus nodes in the blockchain.
It should be appreciated that during a consensus operation, the consensus nodes in the blockchain receive no less than 2f +1 consensus nodes to effectively vote for the first proposal, and successfully agree on the first proposal, while the 2f +1 consensus nodes are not typically all of the consensus nodes in the blockchain. There may also be consensus nodes in the blockchain that are not consensus on the first proposal. In order to synchronize the node change transaction including the node change information to the consensus nodes that are not consensus on the first proposal, the method provided by the embodiment of the present specification further includes, after the consensus nodes generate the first block corresponding to the first proposal:
the consensus master node receives a block synchronization request from a consensus node in the block chain system, wherein the consensus node is not in consensus with the first proposal, and the block synchronization request is sent when the consensus node which is not in consensus with the first proposal determines that the first block is legal;
the consensus master node sends information recorded in the first block to the consensus node that does not agree to the first proposal in response to a block synchronization request for the consensus node that does not agree to the first proposal, such that the consensus node that does not agree to the first proposal generates a new block based on the information recorded in the first block.
Wherein, whether the first block is legal or not can be verified according to the corresponding consensus certificate of the first block. The consensus certificate corresponding to the first block may include a list of consensus nodes participating in a consensus operation on the first block.
Specifically, a common node in the blockchain system that is not common to the first proposal can copy the first block from the common node as the new block of the node.
It should be understood that the first proposal is a proposal initiated by the consensus master node for consensus in the blockchain system, and when the consensus master node generates the first block corresponding to the first proposal, it indicates that the first proposal has achieved consensus in the blockchain system. At this time, other consensus nodes in the blockchain system also continue to generate blocks corresponding to the first offer after performing pipeline operations on the transaction for the first offer.
In step 320, the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, the confirmation messages being used to confirm that the consensus node sending the confirmation message has generated a block for a transaction of a contract invoking a node change.
In order to achieve that most consensus nodes agree on the timing of taking effect of a transaction of a contract invoking a node change in the blockchain system, after a consensus node in the blockchain system has generated a block for the transaction of a contract invoking a node change, a round of interaction may be conducted in the blockchain system for a message confirming that the block corresponding to the first proposal has been generated. In particular, after the consensus nodes in the blockchain system have generated blocks for transactions of contracts for which the calling node changed, each consensus node may send a confirmation message to the consensus master node for confirming that the consensus node sending the confirmation message has generated blocks for transactions of contracts for which the calling node changed.
Optionally, in order to facilitate effective validation of the confirmation message, the confirmation message may carry a signature of an identifier of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the invoking node;
wherein the identity of the block generated by the consensus node sending the confirmation message for the transaction of the contract altered by the invoking node is generated based on at least one of:
the block number of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the calling node;
the invoking node alters a hash value of a transaction of a contract.
It should be understood that the block numbers of blocks generated in the blockchain system for transactions of contracts that invoke the same change in node, and the hash values of transactions of contracts that invoke the change in node, should be consistent. The consensus master node may perform valid validation on the received confirmation message for the identification of the block generated for the transaction of the contract altered by the invoking node carried in the received confirmation message.
And 330, if the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node takes effect, and the target proposed is the proposal after the transaction of the contract changed by the calling node takes effect.
It will be appreciated that if the consensus master node receives acknowledgement messages sent by at least 2f other consensus nodes, plus acknowledgement messages generated by itself, the consensus master node collects at least 2f +1 acknowledgement messages, i.e. the blocks that most consensus nodes in the blockchain system have generated for a transaction of a contract changed by the invoking node.
Optionally, in order to verify the validity of the received acknowledgement message, the embodiments of the present specification may verify the received acknowledgement message based on a signature carried in the acknowledgement message. If the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a target proposal to the consensus node after the transaction of the contract changed by the calling node takes effect, wherein the target proposal comprises the following steps:
the common identification main node verifies the signature carried in the confirmation message sent by other common identification nodes in the block chain;
and if the consensus main node receives confirmation messages sent by other consensus nodes of which at least 2f signatures pass the verification, the consensus main node initiates a target proposal to the consensus node after the transaction of the contract changed by the calling node is validated.
Optionally, in order for other consensus nodes in the blockchain to confirm the transaction content of the contract of the invoking node change that needs to be validated, the consensus master node may generate a target proposal based on the block number of the block generated by the transaction of the contract of the invoking node change. Specifically, the consensus master node initiates a target-proposed consensus operation in the blockchain system, comprising:
the consensus main node packs the block number of the block generated by the transaction of the contract changed by the calling node to obtain a target proposal;
the consensus master node initiates a target-proposed consensus operation in the blockchain system.
After the target proposal reaches consensus in the blockchain system, it indicates that the node change information in the transaction of the contract invoking the node change has been validated. At this time, the consensus node which previously participated in consensus in the blockchain system stops performing consensus operation on the proposal after the target proposal, and performs consensus operation on the proposal after the target proposal by the consensus node after the transaction of the contract which calls the node change takes effect.
Assuming that the transaction of the contract for which the calling node changes includes adding a consensus node in the blockchain, performing consensus operation on the proposal after the target proposal by the consensus node after the transaction of the contract for which the calling node changes takes effect. Specifically, the node which originally participates in consensus and the added consensus node perform consensus operation on the proposal after the target proposal.
Based on the solution of the embodiment of the present specification, after generating a block corresponding to a first proposal of a transaction of a contract involving a change of a call node, a consensus node in a pipeline-type blockchain system can send a confirmation message to a consensus master node, where the consensus master node, after receiving confirmation messages sent by at least 2f other consensus nodes, initiates a consensus operation of a target proposal to the consensus node after the transaction of the contract involving the change of the call node takes effect, where the target proposal is a proposal after the transaction of the contract involving the change of the call node takes effect, so that after the target proposal achieves consensus in the blockchain system, the consensus operation is performed on the proposal after the target proposal based on the consensus node after the transaction of the contract involving the change of the call node takes effect. According to the scheme, after the transaction of the contract of the calling node change is blocked in 2f +1 common identification nodes in the blockchain system, a pair of interactions of confirmation messages of the transaction blocking of the contract of the calling node change is added in the blockchain system, the time for the contract of the calling node change to take effect is effectively determined, and the effectiveness of the node change is further ensured.
Fig. 4 is a schematic structural diagram of a block chain system 400 in a pipeline manner according to an embodiment of the present disclosure. Referring to fig. 4, in one software implementation, a pipelined blockchain system 400 may include a consensus master node 401, wherein:
the consensus master node 401 generates a first block corresponding to a first offer, where the first offer includes a transaction of a contract for invoking a node change;
the consensus master node 401 receives a confirmation message sent by other consensus nodes in the blockchain system, where the confirmation message is used to confirm that the consensus node sending the confirmation message has generated a block for the transaction of the contract changed by the transfer node;
if the consensus master node 401 receives confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a consensus operation of a target proposal to the consensus node after the transaction of the contract changed by the calling node takes effect, wherein the target proposal is the proposal after the transaction of the contract changed by the calling node takes effect.
Optionally, in an embodiment, the confirmation message carries a signature of an identifier of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the transfer node;
wherein the identity of the block generated by the consensus node sending the confirmation message for the transaction of the contract altered by the invoking node is generated based on at least one of:
the block number of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the calling node;
the invoking node alters a hash value of a transaction of a contract.
Optionally, in an embodiment, the consensus master node 401 is configured to:
verifying signatures carried in confirmation messages sent by other common identification nodes in the block chain;
if at least 2f confirmation messages sent by other consensus nodes with signatures passing verification are received, the consensus master node 401 initiates a target proposal to the consensus node after the transaction of the contract changed by the invoking node is validated.
Optionally, in an embodiment, the consensus master node 401 is configured to:
packing the block number of the block generated by the transaction of the contract changed by the calling node to obtain the target proposal;
initiating a consensus operation of the target proposal in the blockchain system.
Optionally, in an embodiment, the contract of the node change is used to drive a consensus node in the blockchain system to perform an operation of node change validation based on a transaction that invokes the contract of the node change.
Optionally, in an embodiment, after the consensus host node 401 generates the first block corresponding to the first offer, the consensus host node 401 is further configured to:
receiving a block synchronization request from a consensus node in the blockchain system that does not agree on the first proposal, the block synchronization request being sent when the consensus node that does not agree on the first proposal determines that the first block is legitimate;
in response to a block synchronization request for a consensus node that the first proposal does not agree, sending information recorded in the first block to the consensus node that does not agree on the first proposal, such that the consensus node that does not agree on the first proposal generates a new block based on the information recorded in the first block.
Optionally, in an embodiment, the transaction of the contract for invoking the node change includes change information of at least one consensus node in the blockchain system.
Optionally, in an embodiment, the change information of at least one consensus node in the blockchain system includes at least one of:
deleting at least one consensus node in the blockchain system;
updating information of at least one consensus node in the blockchain system;
changing at least one non-common node in the blockchain system into a common node in the blockchain system;
adding at least one node outside the blockchain system as a consensus node into the blockchain system.
The block chain system 400 in a pipeline manner can implement the method of the embodiment of the method in fig. 3, and reference may be made to the block chain consensus method in the embodiment shown in fig. 3, which is not described again.
Fig. 5 is a schematic structural diagram of an electronic device provided in an embodiment of the present specification. Referring to fig. 5, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 5, but this does not indicate only one bus or one type of bus.
And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.
Alternatively, the processor reads a corresponding computer program from the non-volatile memory into the memory and then runs the computer program, thereby forming a pipeline-type consensus device on a logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:
generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
receiving confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a blocky for the transaction of the contract changed by the calling node;
and if receiving confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
The block chain consensus method disclosed in the above-mentioned embodiment of fig. 3 may be implemented in or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in one or more embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with one or more embodiments of the present disclosure may be embodied directly in hardware, in a software module executed by a hardware decoding processor, or in a combination of the hardware and software modules executed by a hardware decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
The electronic device may further perform the block chain consensus method of fig. 3, which is not described herein again.
Of course, besides the software implementation, the electronic device in this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Furthermore, the present specification embodiments also propose a computer-readable storage medium storing one or more programs, the one or more programs including instructions.
Optionally, the above instructions, when executed by a portable electronic device including a plurality of application programs, can cause the portable electronic device to perform the method of the embodiment shown in fig. 3, and is specifically configured to perform the following method:
generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change;
receiving confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a blocky for the transaction of the contract changed by the calling node;
and if receiving confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated.
Fig. 6 is a schematic structural diagram of a pipeline-type consensus apparatus 600 according to an embodiment of the present disclosure. In a specific application, the pipeline-type consensus device 600 may be a consensus main node in a blockchain system, or the consensus device may be deployed on a consensus main node in a blockchain system. Referring to fig. 6, in a software implementation, a pipeline consensus apparatus 600 may comprise:
a block generation module 601, configured to generate a first block corresponding to a first offer, where the first offer includes a transaction of a contract for invoking a node change;
a receiving module 602, configured to receive a confirmation message sent by another consensus node in the blockchain system, where the confirmation message is used to confirm that the consensus node sending the confirmation message has generated a block for a transaction of a contract changed by the invoking node;
and the consensus module 603, if receiving confirmation messages sent by at least 2f other consensus nodes, initiates a consensus operation of a target proposal to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposal is the proposal after the transaction of the contract changed by the calling node is validated.
Optionally, the confirmation message carries a signature of a block identifier generated by a consensus node sending the confirmation message for a transaction of a contract changed by the transfer node;
wherein the identity of the block generated by the consensus node sending the confirmation message for the transaction of the contract altered by the invoking node is generated based on at least one of:
the block number of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the calling node;
the invoking node alters a hash value of a transaction of a contract.
Optionally, the consensus module 603 is configured to:
verifying signatures carried in confirmation messages sent by other common identification nodes in the block chain;
initiating the target proposed consensus operation in the blockchain system if acknowledgement messages sent by other consensus nodes are received for which at least 2f signatures are verified.
Optionally, the consensus module 603 is configured to:
packing the block number of the block generated by the transaction of the contract changed by the calling node to obtain the target proposal;
initiating a consensus operation of the target proposal in the blockchain system.
Optionally, the contract for node change is used to drive a consensus node in the blockchain system to perform an operation of node change validation based on a transaction invoking the contract for node change.
Optionally, the transaction of the contract for invoking node change includes change information of at least one consensus node in the blockchain system.
Optionally, the change information of at least one consensus node in the blockchain system includes at least one of:
deleting at least one consensus node in the blockchain system;
updating information of at least one consensus node in the blockchain system;
changing at least one non-common node in the blockchain system into a common node in the blockchain system;
adding at least one node outside the blockchain system as a consensus node into the blockchain system.
The pipeline-mode consensus device 600 can implement the method of the embodiment of the method of fig. 3, and specifically refer to the block chain consensus method of the embodiment shown in fig. 3, which is not described in detail.
In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
Claims (9)
1. A block chain consensus method is applied to a block chain system in a pipeline mode, and comprises the following steps:
the consensus main node generates a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change, and the contract for calling node change is used for driving the consensus node in the blockchain system to execute the operation of node change validation based on the transaction of the contract for calling node change;
the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus node sending the confirmation messages generates a block aiming at the transaction of the contract changed by the invoking node;
if the consensus master node receives confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposed after the transaction of the contract changed by the calling node is validated, and f is the maximum number of allowed abnormal consensus nodes in the blockchain system.
2. The method of claim 1, wherein the confirmation message carries a signature of an identification of a block generated by a consensus node sending the confirmation message for a transaction of a contract altered by the invoking node;
wherein the identity of the block generated by the consensus node sending the confirmation message for the transaction of the contract altered by the invoking node is generated based on at least one of:
the block number of a block generated by the consensus node sending the confirmation message for the transaction of the contract changed by the calling node;
the invoking node alters a hash value of a transaction of a contract.
3. The method of claim 2, if the consensus host node receives acknowledgement messages sent by at least 2f other consensus nodes, the consensus host node initiating a target proposal to the consensus node after the transaction of the contract changed by the invoking node takes effect, comprising:
the common identification main node verifies the signature carried in the confirmation message sent by other common identification nodes in the block chain;
and if the consensus master node receives confirmation messages sent by other consensus nodes of which at least 2f signatures pass verification, the consensus master node initiates a target proposal to the consensus node after the transaction of the contract changed by the calling node is validated.
4. The method of claim 1, the consensus master node initiating the goal-proposed consensus operation in the blockchain system, comprising:
the consensus main node packs the block number of a block generated by the transaction of the contract changed by the calling node to obtain the target proposal;
the consensus master node initiates the target proposed consensus operation in the blockchain system.
5. The method of claim 1, after the consensus master node generates a first block corresponding to a first offer, the method further comprising:
the consensus master node receiving a block synchronization request from a consensus node in the blockchain system that does not agree on the first proposal, the block synchronization request being sent when the consensus node that does not agree on the first proposal determines that the first block is legitimate;
the consensus master node sends information recorded in the first block to the consensus node that does not agree on the first proposal in response to a block synchronization request for the consensus node that does not agree on the first proposal, such that the consensus node that does not agree on the first proposal generates a new block based on the information recorded in the first block.
6. A method according to any one of claims 1 to 5 wherein the transaction for the contract invoking the node change includes change information for at least one consensus node in the blockchain system.
7. The method of claim 6, wherein the change information of at least one consensus node in the blockchain system comprises at least one of:
deleting at least one consensus node in the blockchain system;
updating information of at least one consensus node in the blockchain system;
changing at least one non-common node in the blockchain system into a common node in the blockchain system;
adding at least one node outside the blockchain system as a consensus node into the blockchain system.
8. A pipeline-mode consensus device, comprising:
the block generation module is used for generating a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change, and the contract for calling node change is used for driving a consensus node in a blockchain system to execute the operation of node change validation based on the transaction of the contract for calling node change;
the receiving module is used for receiving confirmation messages sent by other common identification nodes in the blockchain system, and the confirmation messages are used for confirming that the common identification nodes sending the confirmation messages generate blocks aiming at the transaction of the contract changed by the calling node;
and if receiving confirmation messages sent by at least 2f other consensus nodes, initiating a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated, and f is the maximum number of the abnormal consensus nodes allowed in the blockchain system.
9. A pipelined blockchain system, comprising: a consensus master node is established, wherein,
the consensus main node generates a first block corresponding to a first proposal, wherein the first proposal comprises a transaction of a contract for calling node change, and the contract for calling node change is used for driving the consensus node in the blockchain system to execute the operation of node change validation based on the transaction of the contract for calling node change;
the consensus master node receives confirmation messages sent by other consensus nodes in the blockchain system, wherein the confirmation messages are used for confirming that the consensus nodes sending the confirmation messages generate blocks aiming at the transaction of the contracts changed by the calling nodes;
and if receiving confirmation messages sent by at least 2f other consensus nodes, the consensus master node initiates a target proposed consensus operation to the consensus node after the transaction of the contract changed by the calling node is validated, wherein the target proposed is the proposal after the transaction of the contract changed by the calling node is validated, and f is the maximum number of allowed abnormal consensus nodes in the blockchain system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110462870.0A CN112991067B (en) | 2021-04-28 | 2021-04-28 | Block chain consensus method, device and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110462870.0A CN112991067B (en) | 2021-04-28 | 2021-04-28 | Block chain consensus method, device and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112991067A CN112991067A (en) | 2021-06-18 |
| CN112991067B true CN112991067B (en) | 2021-08-03 |
Family
ID=76340452
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110462870.0A Active CN112991067B (en) | 2021-04-28 | 2021-04-28 | Block chain consensus method, device and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112991067B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113377798A (en) * | 2021-07-07 | 2021-09-10 | 支付宝(杭州)信息技术有限公司 | Block chain consistency processing method, block chain node and block chain system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
| CN110727731A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for adding node in block chain network and block chain system |
| CN111147261A (en) * | 2019-12-31 | 2020-05-12 | 南京可信区块链与算法经济研究院有限公司 | Method and system for using HotStuff consensus algorithm in block chain |
| CN111221639A (en) * | 2020-01-09 | 2020-06-02 | 杭州趣链科技有限公司 | Block pipeline execution method of block chain platform |
| CN111444210A (en) * | 2020-03-26 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Block chain consensus node management method, device, equipment and storage medium |
-
2021
- 2021-04-28 CN CN202110462870.0A patent/CN112991067B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110727731A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for adding node in block chain network and block chain system |
| CN110569309A (en) * | 2019-09-17 | 2019-12-13 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchains |
| CN111147261A (en) * | 2019-12-31 | 2020-05-12 | 南京可信区块链与算法经济研究院有限公司 | Method and system for using HotStuff consensus algorithm in block chain |
| CN111221639A (en) * | 2020-01-09 | 2020-06-02 | 杭州趣链科技有限公司 | Block pipeline execution method of block chain platform |
| CN111444210A (en) * | 2020-03-26 | 2020-07-24 | 腾讯科技（深圳）有限公司 | Block chain consensus node management method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112991067A (en) | 2021-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108764870B (en) | Transaction processing method and device based on block chain and electronic equipment | |
| CN108648078B (en) | Transaction preprocessing method and device and electronic equipment | |
| JP6882474B2 (en) | Systems and methods for detecting replay attacks | |
| CN107395557B (en) | Service request processing method and device | |
| JP6905059B2 (en) | Systems and methods for detecting replay attacks | |
| CN109886681A (en) | Block chain common recognition method and common recognition system | |
| CN110659988A (en) | Parallel processing method and device for block chain consensus and execution and electronic equipment | |
| WO2019219306A1 (en) | Identifying faults in a blockchain ordering service | |
| CN113037817B (en) | Method and device for starting intelligent contract, electronic equipment and storage medium | |
| US11366932B2 (en) | Consensus method and data verification method, apparatus, and system of consortium blockchain | |
| CN112887436B (en) | Consensus method, consensus node and block chain system of pipeline mode | |
| TWI737118B (en) | Method, device and electronic equipment for reconciliation based on alliance chain | |
| US20230275771A1 (en) | Pre-execution of block chain transaction in parallel during block consensus | |
| CN112700248B (en) | Block chain consensus method, device and system based on Byzantine fault-tolerant algorithm | |
| CN112991067B (en) | Block chain consensus method, device and system | |
| US11228446B2 (en) | Blockchain-based reconciliation method and apparatus and electronic device | |
| TW202038122A (en) | Blockchain-based service processing method and apparatus, and electronic device | |
| CN112988470B (en) | Consensus method, consensus node and system in alliance chain | |
| CN110675148B (en) | Synchronization method and system for verification node set and electronic equipment | |
| CN109409899B (en) | Transaction verification method, device and system | |
| CN108710658B (en) | Data record storage method and device | |
| CN110009348B (en) | Block chain proxy signature method and system and electronic equipment | |
| CN112351085A (en) | Network resource safety sharing method | |
| CN112991066A (en) | Consensus method and device in alliance chain and electronic equipment | |
| CN111030826A (en) | Certificate revocation method and device for block chain network and electronic equipment |
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 |