CN113657898A

CN113657898A - Consensus method and system in alliance chain

Info

Publication number: CN113657898A
Application number: CN202111094918.3A
Authority: CN
Inventors: 李帅
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-06-05
Filing date: 2020-06-05
Publication date: 2021-11-16
Anticipated expiration: 2040-06-05
Also published as: CN113657898B; CN111401904A; WO2021244581A1; CN111401904B

Abstract

The specification discloses a consensus method and a system in a alliance chain, wherein the method comprises the following steps: the consensus main node selects a target transaction set from a managed transaction memory pool to generate a target offer and broadcasts the target offer to a consensus backup node in a alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set; the consensus master node sends the target transaction set to a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent transaction arrangement of the target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process; the consensus backup node receiving the target offer determines whether the target deal set matching the root hash in the target offer exists in a managed deal memory pool, and performs a consensus operation on the target offer when determined to exist.

Description

Consensus method and system in alliance chain

This application is a divisional patent application having the application number CN 2020105051787, application date 2020 of 06/05 and the name "consensus method and system in alliance chain".

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and a system for consensus in a federation chain.

Background

Taking a federation chain in a blockchain as an example, the federation chain is generally maintained by nodes (validators) designated by a federation, each node has a peer-to-peer right, and the nodes interact with each other through a distributed consensus protocol. However, since each node in the federation chain is peer-to-peer, the overall performance (e.g., throughput) of the system often does not exceed the upper limit of performance (throughput) of a single node. This results in a limited overall performance (i.e., throughput) of the federation chain, which in turn results in a limited application scenario.

At present, in order to solve the problem of low throughput, a fragmentation scheme (fragmentation) is adopted in many capacity expansion schemes, that is, each fragment is an individual chain, system data is distributed in different fragments, and all the fragments are combined together to provide an overall service. However, although the fragmentation scheme can improve the system throughput, it also introduces the problem of inter-fragmentation interaction.

Disclosure of Invention

The embodiment of the specification provides a consensus method and a consensus system in a alliance chain, so as to solve the problem that the overall throughput of the existing alliance chain is difficult to improve, and the overall performance is difficult to improve.

In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:

in a first aspect, a consensus method in a federation chain is provided, including:

the consensus main node selects a plurality of transaction sets from a managed transaction memory pool to generate a target offer and broadcasts the target offer to a consensus backup node in a alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of the transaction sets, and the transaction sets comprise ordered arrangement of transactions;

the consensus master node sends the multiple transaction sets to a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the multiple transaction sets are the same as the set arrangement and intra-set transaction arrangement of the multiple transaction sets in the root hash process;

the consensus backup node receiving the target offer determines whether the plurality of transaction sets matching a root hash in the target offer exist in a managed transaction memory pool, and performs a consensus operation on the target offer when determined to exist.

In a second aspect, a consensus method in a federation chain is provided, including:

the consensus main node selects a target transaction set from a managed transaction memory pool to generate a target offer and broadcasts the target offer to a consensus backup node in a alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set;

the consensus master node sends the target transaction set to a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent transaction arrangement of the target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process;

the consensus backup node receiving the target offer determines whether the target deal set matching the root hash in the target offer exists in a managed deal memory pool, and performs a consensus operation on the target offer when determined to exist.

In a third aspect, an alliance chain system is provided, which includes an consensus main node and a plurality of consensus backup nodes, wherein:

the consensus master node selects a plurality of transaction sets from a managed transaction memory pool to generate a target offer and broadcasts the target offer to the consensus backup node in a alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of the transaction sets, and the transaction sets comprise ordered transactions; sending the transaction sets to a consensus backup node in the federation chain through a managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the transaction sets are the same as the set arrangement and intra-set transaction arrangement of the transaction sets in the root hash process;

In a fourth aspect, an alliance chain system is provided, which includes an consensus primary node and a plurality of consensus backup nodes, wherein:

the consensus main node selects a target transaction set from a managed transaction memory pool to generate a target offer and broadcasts the target offer to the consensus backup node in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set; sending the target transaction set to a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent transaction arrangement of the target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process;

The embodiment of the specification can achieve at least the following technical effects by adopting the technical scheme:

the consensus main node can select a target transaction set from a managed transaction memory pool to generate a target offer and broadcast the target offer to the consensus backup node in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set; the consensus master node sends a target transaction set to a consensus backup node in a alliance chain through a managed transaction memory pool, wherein the transaction arrangement of the sent target transaction set is the same as the transaction arrangement of the target transaction set in the process of forming the root hash; the method includes receiving a consensus backup node of a target offer, determining whether a target transaction set matching a root hash in the target offer exists in a managed transaction memory pool, and performing a consensus operation on the target offer when determined to exist. When the consensus master node initiates the consensus operation, the root hash of the transaction set is transmitted to the consensus backup node instead of the original data of the transaction set, so that the bandwidth occupied by the transaction transmission is reduced; on the other hand, the transaction memory pool in each node can be expanded horizontally, so that the throughput in the consensus process is improved.

The consensus master node can select a plurality of transaction sets from a managed transaction memory pool to generate a target offer and broadcast the target offer to the consensus backup node in the alliance chain, wherein the offer comprises a root hash formed by ordered arrangement of transactions of the transaction sets, and the transaction sets comprise the ordered arrangement of the transactions; the consensus master node sends a plurality of transaction sets to the consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the transaction sets are the same as the set arrangement and intra-set transaction arrangement of the transaction sets in the root hash process; the method includes receiving a consensus backup node for a target proposal, determining whether a plurality of transaction sets matching a root hash in the target proposal exist in a managed transaction memory pool, and performing a consensus operation on the target proposal when the determination exists. When the consensus master node initiates the consensus operation, the root hash of the transaction set is transmitted to the consensus backup node instead of the original data of the transaction set, so that the bandwidth occupied by the transaction transmission is reduced; on the other hand, the transaction memory pool in each node can be expanded horizontally, so that the throughput in the consensus process is improved.

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 of a process for processing a transaction in a federation chain according to the prior art;

fig. 2 is a schematic flow chart illustrating an implementation of a consensus method in a federation chain according to an embodiment of the present disclosure;

FIG. 3 is a diagram illustrating a consensus method in a federation chain applied to an actual scenario according to an embodiment of the present disclosure;

FIG. 4 is a flow chart illustrating an implementation of another consensus method in a federation chain, according to an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of an alliance chain system provided in an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of an alliance chain system 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, for the example of a federation chain, a federation chain is usually only for members of a particular group and limited third parties, and internally designates a plurality of preselected nodes (validators) as billers, and the generation of each block is determined by the plurality of preselected nodes, and each preselected node has the right to peer. A plurality of preselected nodes interact, typically using a distributed consensus protocol, to achieve consensus on each proposal to be recorded into a newly generated block.

Most federation chains currently deal with collected transactions through a State Machine Replication model (SMR). As shown in fig. 1, which is a schematic diagram of a process for processing a transaction in an existing federation chain, in the SMR model, consensus processing of the transaction includes: 1. receiving a transaction from a client, 2, carrying out consensus processing on the transaction, 3, executing the transaction after consensus by a state machine, and 4, returning an execution result of the transaction to the client. Obviously, in the existing process of processing transactions in a federation chain, the two processes of the stage 1 and the stage 4 do not occupy the transmission bandwidth of the system because the transmission of transactions between nodes is not involved, and therefore capacity expansion is not generally needed.

While the phase 2 relates to the transaction transmission between the nodes, which occupies the transmission bandwidth of the system, and the phase 3 relates to the transaction execution, which consumes the processing resources of the system, and the processing phases of the two transactions will be the entry points for system capacity expansion. If only the stage 3 is expanded, the stage 2 becomes a bottleneck of improving the overall performance of the system through the expansion of the system. Therefore, how to separate the data transmission module and the consensus module in the stage 2 is to fundamentally solve the problem that the stage 2 is a single-point bottleneck problem of improving the overall performance of the system, so as to ensure that the system is arbitrarily expanded in the horizontal direction, which is a problem to be solved urgently.

In order to solve the problem that the overall throughput of the existing alliance chain is difficult to improve and the overall performance of the system is difficult to improve, an embodiment of the specification provides an consensus method in the alliance chain, wherein a consensus main node can select a target transaction set from a managed transaction memory pool to generate a target proposal and broadcast the target proposal to consensus backup nodes in the alliance chain, and the target proposal comprises a root hash formed by ordered arrangement of transactions of the target transaction set; the consensus master node sends a target transaction set to a consensus backup node in a alliance chain through a managed transaction memory pool, wherein the transaction arrangement of the sent target transaction set is the same as the transaction arrangement of the target transaction set in the process of forming the root hash; the method includes receiving a consensus backup node of a target offer, determining whether a target transaction set matching a root hash in the target offer exists in a managed transaction memory pool, and performing a consensus operation on the target offer when determined to exist.

When the consensus master node initiates the consensus operation, the root hash of the transaction set is transmitted to the consensus backup node instead of the original data of the transaction set, so that the bandwidth occupied by the transaction transmission is reduced; on the other hand, the transaction memory pool in each node can be expanded horizontally, so that the throughput in the consensus process is improved.

Specifically, when the consensus master node selects a plurality of transaction sets from the managed transaction memory pool to generate a target offer, an implementation flow diagram of a consensus method in a federation chain according to one or more embodiments of the present specification is shown in fig. 2, and includes:

step 210, the consensus master node selects multiple transaction sets from the managed transaction memory pool to generate a target offer, and broadcasts the target offer to the consensus backup node in the alliance chain, where the target offer includes a root hash formed by ordered arrangement of the multiple transaction sets, and the multiple transaction sets include the ordered transactions.

The transaction storage pool of the consensus master node stores a plurality of transaction aggregates, and when the transaction aggregates stored in the transaction storage pool are multiple, the transaction aggregates comprise both the aggregate of collected transactions from the client and the transaction aggregate forwarded by one or more consensus backup nodes. Specifically, the consensus master node stores a transaction set sent by the client and a transaction set sent by at least one consensus backup node; and the consensus backup node stores at least one transaction set sent by the client, transaction sets forwarded by other consensus backup nodes of the alliance chain, and transaction sets sent by the consensus main node.

It should be understood that the transaction sets need to be identified before writing the newly generated block.

Optionally, since the transaction sets are all data to be written into the newly generated block, in order to distinguish transaction sets of different batches, that is, to distinguish data written into different blocks, the transaction memory pool in the embodiment of the present specification further stores block numbers to be written corresponding to the transaction sets. Specifically, the consensus master node selects a plurality of transaction sets from a managed transaction memory pool to generate a target offer, and the method comprises the following steps:

the consensus main node selects a plurality of transaction sets corresponding to the same block number from a managed transaction memory pool;

the consensus master node generates a goal offer based on a plurality of sets of transactions corresponding to the same block number.

It should be understood that transactions corresponding to the same block number are collected into the same batch of data, and should be identified in a round of identification operation.

It should be understood that, in order to ensure that the set of transactions from the client collected by the transaction memory pool meets the condition for initiating the consensus, the consensus master node in this embodiment may further determine whether the collected set of transactions meets the preset transaction collection condition before initiating the consensus. Specifically, the consensus master node generates a target offer based on the plurality of transaction sets corresponding to the same block number, including:

and if the consensus main node determines that the plurality of transaction sets corresponding to the same block number meet the preset transaction collection condition, generating a target proposal based on the plurality of transaction sets corresponding to the same block number.

Optionally, the preset transaction collection condition includes at least one of:

the collected transaction number is greater than or equal to a preset number;

the period of collecting transactions is greater than or equal to a specified collection period;

the size of the collected transactions is greater than or equal to the specified capacity.

It should be understood that, in order to avoid that the transmission of the original data of the transaction set occupies the transmission bandwidth of the consensus master node, the original data of the transaction set in the embodiment of the present specification, that is, the original data of the multiple transaction sets corresponding to the root hash in the target offer, may be sent by the transaction memory pool of the consensus master node to the transaction memory pool of the consensus backup node in the federation chain. Specifically, the consensus master node sends a plurality of transaction sets to a transaction memory pool of the consensus backup node in the federation chain through the transaction memory pool of the consensus master node, the target offer includes a root hash formed by ordered arrangement of the plurality of transaction sets, and the plurality of transaction sets include the ordered arrangement of transactions.

Optionally, as an implementation manner, the signature information carried in the target offer may also be a root hash, that is, the signature information obtained by the consensus master node signing the root hash through its private key. In this case, after receiving the target offer, the consensus backup node may decrypt the signature information of the root hash through the paired public key to obtain the root hash.

Optionally, as another embodiment, the target offer may also carry hash values of transactions included in multiple transaction sets, for example, if the multiple transaction sets include transactions 1 to 4, the target offer may carry hash values of transaction 1, transaction 2, transaction 3, and transaction 4.

Optionally, the consensus master node broadcasts the target offer carrying the root hash to the consensus backup node through the transaction memory pool, and may specifically transmit the target offer carrying the root hash to the consensus backup node through gosssip (periodic broadcast message) transmission.

Step 220, the consensus master node sends a plurality of transaction sets to the consensus backup node in the alliance chain through the managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the transaction sets are the same as those of the transaction sets in the domestic root hash process.

It should be understood that, in order to avoid that a plurality of transaction sets corresponding to target offers to be identified are directly transmitted between nodes to occupy too much network transmission bandwidth of the consensus master node, in the embodiment of the present specification, the transaction memory pool managed by the consensus master node may send the transaction sets to the transaction memory pool of the consensus backup node in the blockchain. Specifically, the consensus master node may invoke the transaction memory pool of the node, and broadcast the transaction sets corresponding to the target offer to the transaction memory pool of the consensus backup node in the blockchain.

In order to ensure the order of transmitting the transaction sets corresponding to the target offer to the consensus backup node and the order of the transaction data included in the transaction sets, thereby speeding up the determination of the transaction sets matching the root hash in the target offer, the consensus master node in the embodiment of the present specification may send the transaction sets to the consensus backup node in the federation chain in a serialized form through a managed transaction memory pool. Suppose that the consensus master node transmits tx 1-tx 8 to the consensus backup node, the 8 transactions can be serialized to obtain a transmission data, and the consensus backup node receives tx 1-tx 8 and performs corresponding deserialization to determine the sequence of the 8 transactions. It should be understood that the consensus backup node may receive an ordered set of transactions, and the transactions in the transaction set are also ordered.

Of course, other means of transmission may be used. For example, the transactions in the transaction sets are transmitted respectively, the ordered hash sequences of the transactions in each transaction set and the ordered hash sequences of the transaction sets are transmitted, the order of the transactions in the sets is guaranteed through the ordered hash sequences of the transactions in the transaction sets, and the order between the transaction sets is guaranteed through the ordered hash sequences of the transaction sets.

Step 230, receiving the consensus backup node of the target proposal, determining whether a plurality of transaction sets matching the root hash in the target proposal exist in the managed transaction memory pool, and executing the consensus operation on the target proposal when the determination exists.

Optionally, in order to improve the verification efficiency, the target offer further carries a block number to be written in the target offer to be written, a consensus backup node that receives the target offer determines whether multiple transaction sets matching a root hash in the target offer exist in a managed transaction memory pool, including:

the common recognition backup node receiving the target proposal obtains a transaction set corresponding to the block number to be written from a managed transaction memory pool based on the block number to be written carried in the target proposal;

if the consensus backup node of the target proposal is received, and the acquired root hash of the transaction set corresponding to the block number to be written is consistent with the root hash in the target proposal, determining that a plurality of transaction sets matched with the root hash in the target proposal exist in the managed transaction memory pool; or

And if the consensus backup node of the target proposal is received, and the acquired root hash of the transaction set corresponding to the block number to be written is inconsistent with the root hash in the target proposal, determining that a plurality of transaction sets matched with the root hash in the target proposal do not exist in the managed transaction memory pool.

It should be understood that, in order to accurately verify whether multiple transaction sets matching the root hash in the destination proposal exist in the transaction memory pool in the consensus backup node, in addition to the block number to be written in the destination proposal, the transaction sets stored in the transaction memory pool should also carry the identifier of the sending node, and after multiple transaction sets corresponding to the block number to be written in the destination proposal are obtained from the transaction memory pool of the consensus backup node, the corresponding root hash may be generated according to the node identifiers corresponding to the transaction sets.

Optionally, after the consensus backup node receiving the target proposal determines that the plurality of transaction sets matching the root hash in the target proposal do not exist in the managed transaction memory pool, in order to be able to continue the consensus operation on the target proposal, the method further includes:

the consensus backup node receiving the target proposal obtains a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus main node through the managed transaction memory pool; or

And the consensus backup node receiving the target proposal acquires a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool managed by the consensus backup node which agrees with the target proposal through the managed transaction memory pool.

Optionally, in order to improve efficiency of querying the missed transaction set, a routing information may be further maintained in the consensus master node and the consensus backup node in the embodiment of the present specification, where the routing information is used to indicate to which consensus backup node the transaction memory pool of the consensus master node sends the transaction set corresponding to which block number. Specifically, the step of acquiring, by the consensus backup node that receives the target offer, a transaction set that corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus master node through the managed transaction memory pool includes:

the consensus backup node receiving the target proposal determines a missed transaction set from the consensus main node based on the routing information;

and the consensus backup node receiving the target proposal obtains the missed transaction set from the transaction memory pool of the consensus main node through the transaction memory pool.

Optionally, in order to ensure a certain timeliness, after receiving the consensus backup node of the target offer and determining that the plurality of transaction sets matching the root hash in the target offer do not exist in the managed transaction memory pool, the method further includes:

and the consensus backup node which receives the target proposal acquires a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool in a specified time period.

And if the common-recognition backup node of the target proposal is received and the transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired in the appointed time period, initiating view switching operation in the alliance chain.

It should be understood that, in order to avoid delaying excessive time in a round of consensus operation to affect the consensus operation of the subsequent block data, in the embodiment of the present specification, if the consensus backup node receiving the target proposal passes through the managed transaction memory pool and does not obtain the transaction set corresponding to the block number to be written and not in the managed transaction memory pool from the transaction memory pool of the consensus master node within a specified time period.

And if the consensus backup node of the target proposal is received, determining that a plurality of transaction sets matched with the root hash in the target proposal exist in the managed transaction memory pool, and executing consensus operation on the target proposal.

It should be noted that, because the transaction memory pools in the consensus main node and the consensus backup node may be expanded horizontally, and the number of the consensus backup nodes in the federation chain is usually multiple, the number of the transaction memory pools in the consensus main node and each of the consensus backup nodes may be the same or different, the number of the transaction memory pools in the consensus main node and the consensus backup node may be increased according to the actual performance improvement requirement, and when the number of the transaction memory pools in the same node is multiple, the information between the multiple transaction memory pools is intercommunicated.

Optionally, the number of the transaction memory pools in the consensus master node is at least one;

the number of the transaction memory pools in the consensus backup node is at least one.

Optionally, when the number of the transaction memory pools in the consensus main node is multiple, the information intercommunication is performed between the multiple transaction memory pools of the consensus main node;

and when the number of the transaction memory pools in the consensus backup node is multiple, the information intercommunication is carried out among the transaction memory pools of the consensus backup node.

That is to say, when there are a plurality of transaction memory pools in the consensus master node or the consensus backup node, information among the transaction memory pools in the same node is intercommunicated, and specifically, routing information of one transaction memory pool may be maintained in a controller in the node or the transaction memory pool, and the routing information of the transaction memory pool may specifically store which transaction sets are stored in which transaction memory pool.

For example, a first transaction set and a second transaction set are stored in the consensus master node, and two transaction memory pools, namely a transaction memory pool 1 and a transaction memory pool 2, are provided in the consensus master node, where the first transaction set is stored in the transaction memory pool 1, and the second transaction set is stored in the transaction memory pool 2, and then the routing information of the transaction memory pool may store the mapping relationship.

It should be noted that the consensus algorithm in the embodiments of the present specification includes at least one of Raft, Practical Byzantine Fault-tolerant algorithm (PBFT), BFT-SMaRt (chinese name: performance improvement of state machine replication scheme based on Byzantine Fault Tolerance), and honeypot Byzantine Fault-tolerant algorithm. The following describes in detail the process of performing consensus operation on the target offer by the consensus backup node receiving the target offer, taking a consensus algorithm in the federation chain as PBFT as an example.

The method comprises the steps that a consensus main node sends a PRE-PREPARE message aiming at a target proposal and a signature of the PRE-PREPARE message to a consensus backup node in a alliance chain, wherein the format of the PRE-PREPARE message is < PRE-PREPARE, v, n, d >, v is a view number, d is a root hash formed by a plurality of transaction sets corresponding to the target proposal, and n is [ H, H ] within a certain range interval;

after receiving the PRE-PREPARE message for the target proposal, the consensus backup node verifies the PRE-PREPARE message, mainly verifying the following: whether the signature of the PRE-prefix message by the consensus master node is correct, whether a plurality of transaction sets matched with d exist in a transaction memory pool managed by the consensus master node, whether n is in an interval [ H, H ], whether the consensus backup node receives a PRE-prefix message which is under the same v and has a number of n, but has a different signature;

after the received PRE-PREPARE message is verified by the consensus backup node, a PREPARE message is sent to other nodes in a federation chain including a consensus primary node, wherein the format of the message is < PREPARE, v, n, d, i >, m is the same as the content of the PRE-PREPARE message, i is the number of the current consensus backup node, and the < PREPARE, v, n, d, i > is signed at the same time;

after receiving the PREPARE message, the consensus primary node and other consensus backup nodes in the federation chain mainly perform the following checks: whether the signature of the PREPARE message is correct, whether the node receiving the PREPARE message has received n under the same view, whether n is within the interval [ H, H ], and whether d is the same as d in the received PRE-PREPARE message. Discarding the message if at least one of the verifications fails;

if the common identification primary node and other common identification backup nodes in the alliance chain receive the PREPARE messages of not less than 2f +1 nodes and the verification is passed, sending COMMIT messages and message signatures to other nodes in the alliance chain, wherein the format is < COMMIT, v, n, d, i >, and the v, n, d, i have the same content as the PREPARE messages;

after receiving the COMMIT message, the nodes in the federation chain verify the COMMIT message, mainly checking the following items: whether the signature of the COMMIT message is correct, whether n under the same view is received, whether a plurality of transaction sets matched with d exist in a transaction memory pool managed by the COMMIT message, and whether n is in an interval [ H, H ].

Optionally, after the consensus backup node receiving the target proposal performs consensus operation on the target proposal, if nodes in a federation chain receive valid verification messages for the target proposal from not less than 2f +1 nodes, generating a block in which a plurality of transaction sets corresponding to the target proposal are recorded; wherein f is the maximum number of abnormal nodes allowed in the federation chain.

It should be understood that the nodes in the federation chain described herein may be consensus master nodes in the federation chain or consensus backup nodes in the federation chain.

Specifically, if the nodes in the alliance chain receive the COMMIT messages sent by not less than 2f +1 nodes and all the messages pass the verification, it indicates that most nodes in the current alliance chain have agreed on the target proposal, and at this time, a block in which a plurality of transaction sets corresponding to the target proposal are recorded may be generated in the node.

The method provided in the embodiment of the present specification is described in detail below with reference to a schematic flow diagram of applying the consensus method in the federation chain shown in fig. 3 to an actual scenario, where it is assumed that the schematic view of the scenario shown in fig. 3 is a consensus master node and a consensus backup node in the federation chain, and only one consensus backup node is shown in fig. 3, it should be understood that in the actual application, the number of consensus backup nodes is often multiple, where one consensus backup node is taken as an example, and the processing of other consensus backup nodes is similar to the processing of the consensus backup node, and will not be described again here. As shown in fig. 3, the consensus process in the federation chain includes:

s1, the controller in the consensus master node verifies whether the transaction sets collected in the transaction memory pool satisfy a predetermined transaction collection condition, such as whether the number of transactions in the transaction sets is greater than or equal to a predetermined number, whether the collection period of the transaction sets is greater than or equal to a predetermined collection period, and/or whether the size of the transaction sets is greater than or equal to a predetermined capacity, and so on.

If the controller in the consensus master node verifies the multiple transaction sets, S2 is executed, otherwise, collection of transactions from the client in the transaction sets is continued. When the controller in the consensus master node collects a transaction set, the controller also allocates a block number to be written into the collected transaction set, and the transaction memory pool in the consensus master node receives a transaction set forwarded by the consensus backup node while collecting a transaction set from the client, wherein the forwarded transaction set also corresponds to the block number to be written into.

And S2, the controller in the consensus master node acquires a transaction set corresponding to the same block number from the transaction memory pool.

As shown in fig. 3, since the consensus master node includes 3 transaction memory pools, the routing information of the transaction memory pools can be obtained as to which transaction memory pools the transaction sets corresponding to the same block number are obtained from.

S3, the controller in the consensus master node generates a root hash based on the plurality of transaction sets.

S4, the consensus module of the consensus master node initiates a target offer carrying the root hash in the federation chain based on the root hash, and specifically may send a PBFT Pre-prefix message (assuming that the consensus mode is PBFT) to the consensus module of the consensus backup node.

And S5, the transaction memory pool of the consensus master node sends a transaction set for generating the root hash in the target proposal to the transaction memory pool of the consensus backup node, wherein the target proposal carries the root hash and the block number to be written.

And S6, the consensus backup node acquires data such as the root hash and the block number to be written in the target proposal from the consensus main node.

S7, the consensus backup node acquires a transaction set corresponding to the block number to be written in the target proposal from the transaction memory pool, generates a corresponding root hash according to the transaction set corresponding to the block number to be written in the target proposal, verifies whether the root hash in the target proposal is consistent with the root hash generated by the transaction set corresponding to the block number to be written in the target proposal, if so, continues to execute the consensus operation on the target proposal, and if not, executes S8.

And S8, the transaction memory pool of the consensus backup node sends a query to the consensus master node within a specified time period, wherein the query is about a transaction set which corresponds to the block number to be written in the target proposal and is not in the managed transaction memory pool.

If the consensus backup node inquires a transaction set which corresponds to the block number to be written in the target proposal and is not in the managed transaction memory pool within the specified time period, S7 is executed, and after the consensus backup node passes the verification, consensus operation on the target proposal is continuously executed; and if the common identification backup node does not inquire the transaction set which corresponds to the block number to be written in the target proposal and is not in the managed transaction memory pool in the designated time period, executing view switching operation.

Specifically, when the consensus master node selects a transaction set from the managed transaction memory pool to generate a target offer, an implementation flow diagram of a consensus method in a federation chain according to one or more embodiments of the present specification is shown in fig. 4, and includes:

step 410, the consensus master node selects a target transaction set from the managed transaction memory pool to generate a target offer and broadcasts the target offer to the consensus backup node in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set;

step 420, the consensus master node sends the target transaction set to a consensus backup node in a federation chain through a managed transaction memory pool, wherein the transaction arrangement of the sent target transaction set is the same as the transaction arrangement of the target transaction set in the process of forming the root hash;

step 430, receiving the consensus backup node of the target proposal, determining whether a target transaction set matching the root hash in the target proposal exists in the managed transaction memory pool, and executing consensus operation on the target proposal when the determination exists.

Optionally, after receiving the consensus backup node of the target offer and determining whether a target transaction set matching the root hash in the target offer exists in the managed transaction memory pool, the method further includes:

the consensus backup node receiving the target proposal obtains a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus main node through the managed transaction memory pool; and/or

And the common-recognition backup node receiving the target proposal acquires a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the common-recognition backup node which agrees with the target proposal through the managed transaction memory pool.

Optionally, after receiving the consensus backup node of the target offer and determining that the plurality of transaction sets matching the root hash in the target offer do not exist in the managed transaction memory pool, the method further includes:

Optionally, if a consensus backup node of the target offer is received and a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired within a specified time period, initiating a view switching operation in the federation chain.

Optionally, after the consensus backup node receiving the target proposal performs the consensus operation on the target proposal, the method further includes:

if the nodes in the alliance chain receive effective verification messages aiming at the target proposal from not less than 2f +1 nodes, generating a block recorded with a plurality of transaction sets corresponding to the target proposal; wherein f is the maximum number of abnormal nodes allowed in the federation chain.

The specific implementation of the steps related to the embodiment shown in fig. 4 may refer to the specific implementation of the corresponding steps in the embodiments shown in fig. 2 to fig. 3, and one or more embodiments in this specification are not described herein again.

Fig. 5 is a schematic structural diagram of a federation chain system 500 provided in an embodiment of the present specification. Referring to fig. 5, in one software implementation, a federation chain system 500 may include a consensus master node 510 and a plurality of consensus backup nodes 520, wherein:

the consensus master node 510 selects a plurality of transaction sets from the managed transaction memory pool to generate a target offer, and broadcasts the target offer to the consensus backup node in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of the transaction sets, and the transaction sets comprise ordered transactions; sending the transaction sets to a consensus backup node in the federation chain through a managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the transaction sets are the same as the set arrangement and intra-set transaction arrangement of the transaction sets in the root hash process;

the consensus backup node 520 that receives the target proposal, determines whether the plurality of transaction sets matching the root hash in the target proposal exist in a managed transaction memory pool, and performs a consensus operation on the target proposal when determined to exist.

Optionally, in an embodiment, the consensus master node 510 is configured to:

selecting a plurality of transaction sets corresponding to the same block number from a managed transaction memory pool;

generating a destination offer based on the plurality of sets of transactions corresponding to the same block number.

Optionally, in an embodiment, the consensus master node 510 is configured to:

and if the plurality of transaction sets corresponding to the same block number are determined to meet the preset transaction collection condition, generating a target proposal based on the plurality of transaction sets corresponding to the same block number.

Optionally, in one embodiment, the preset transaction collection condition includes at least one of:

the collected transaction number is greater than or equal to a preset number;

Optionally, in an implementation manner, the destination offer further carries a block number to be written in, and the consensus backup node 520 that receives the destination offer is configured to:

acquiring a transaction set corresponding to the block number to be written from a managed transaction memory pool based on the block number to be written carried in the target proposal;

if the obtained root hash of the transaction set corresponding to the block number to be written is consistent with the root hash in the target proposal, determining that the transaction sets matched with the root hash in the target proposal exist in a managed transaction memory pool; or

And if the obtained root hash of the transaction set corresponding to the block number to be written is not consistent with the root hash in the target proposal, determining that the transaction sets matched with the root hash in the target proposal do not exist in the managed transaction memory pool.

Optionally, in an embodiment, after determining that the plurality of transaction sets matching the root hash in the target offer do not exist in the managed transaction memory pool, the consensus backup node 520 that receives the target offer is further configured to:

acquiring a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus master node through the managed transaction memory pool; and/or

And acquiring a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus backup node which agrees with the target proposal through the managed transaction memory pool.

Alternatively, in one embodiment,

if the

node

510 or 520 in the alliance chain receives valid verification messages aiming at the target proposal from not less than 2f +1 nodes, generating a block recorded with a plurality of transaction sets corresponding to the target proposal; wherein f is the maximum number of abnormal nodes allowed in the federation chain.

The consensus backup node 520 receiving the target proposal, after determining that the plurality of transaction sets matching the root hash in the target proposal do not exist in the managed transaction memory pool, the consensus backup node 520 receiving the target proposal is further configured to:

and acquiring a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool in a specified time period.

Optionally, in an embodiment, the consensus backup node 520 is configured to:

and if the transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired within a specified time period, initiating view switching operation in the alliance chain.

Optionally, in an embodiment, the number of the transaction memory pools in the consensus master node is at least one;

Optionally, in an embodiment, when the number of the transaction memory pools in the consensus main node is multiple, the multiple transaction memory pools of the consensus main node intercommunicate with each other;

and when the number of the transaction memory pools in the consensus backup node is multiple, the information intercommunication among the transaction memory pools of the consensus backup node is realized.

The federation chain system 500 can implement the method of the embodiment of the method in fig. 2 to 3, and specifically refer to the consensus method in the federation chain of the embodiment shown in fig. 2 to 3, which is not described again.

Fig. 6 is a schematic structural diagram of a federation chain system 600 provided in an embodiment of the present specification. Referring to fig. 6, in one software implementation, a federation chain system 600 may include a consensus primary node 610 and a plurality of consensus backup nodes 620, wherein:

the consensus master node 610 selects a target transaction set from a managed transaction memory pool to generate a target offer and broadcasts the target offer to the consensus backup nodes in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set; sending the target transaction set to a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent transaction arrangement of the target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process;

the consensus backup node 620 that receives the target proposal, determines whether the target transaction set matching the root hash in the target proposal exists in a managed transaction memory pool, and performs a consensus operation on the target proposal when determined to exist.

Optionally, in an implementation manner, the destination offer further carries a block number to be written in, and the consensus backup node 620 that receives the destination offer is configured to:

if the obtained root hash of the transaction set corresponding to the block number to be written is consistent with the root hash in the target proposal, determining that the target transaction set matched with the root hash in the target proposal exists in a managed transaction memory pool; or

And if the obtained root hash of the transaction set corresponding to the block number to be written is not consistent with the root hash in the target proposal, determining that the target transaction set matched with the root hash in the target proposal does not exist in a managed transaction memory pool.

Optionally, in an embodiment, the consensus backup node 620 that receives the target proposal is configured to:

acquiring the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus master node through the managed transaction memory pool; and/or

And acquiring the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus backup node which agrees with the target proposal through the managed transaction memory pool.

Optionally, in an embodiment, after determining that the target transaction set matching the root hash in the target offer does not exist in the managed transaction memory pool, the consensus backup node 620 that receives the target offer is further configured to:

and acquiring the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool in a specified time period.

and if the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired within a specified time period, initiating view switching operation in the alliance chain.

Optionally, in one embodiment, the consensus backup node 620 that received the target proposal, after performing the consensus operation on the target proposal,

if the

node

610 or 620 in the federation chain receives valid verification messages for the target proposal from not less than 2f +1 nodes, generating a block recorded with the target transaction set corresponding to the target proposal; wherein f is the maximum number of abnormal nodes allowed in the federation chain.

The federation chain system 600 can implement the method of the embodiment of the method in fig. 4, which may specifically refer to the consensus method in the federation chain of the embodiment shown in fig. 4 and is not described again.

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

1. A method of consensus in a federation chain, comprising:

the consensus master node sends the transaction sets to a transaction memory pool of a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent set arrangement and intra-set transaction arrangement of the transaction sets are the same as the set arrangement and intra-set transaction arrangement of the transaction sets in the root hash process;

2. The method of claim 1, the consensus master node selecting a plurality of sets of transactions from a managed transaction memory pool to generate a goal offer, comprising:

the consensus master node generates a target offer based on the plurality of sets of transactions corresponding to the same block number.

3. The method of claim 2, the consensus master node generating a goal offer based on the plurality of sets of transactions corresponding to the same block number, comprising:

and if the consensus main node determines that the plurality of transaction sets corresponding to the same block number meet a preset transaction collection condition, generating a target proposal based on the plurality of transaction sets corresponding to the same block number.

4. The method of claim 3, wherein the destination offer further carries a block number to be written,

the consensus backup node receiving the target offer determining whether the plurality of transaction sets matching the root hash in the target offer exist in a managed transaction memory pool, comprising:

if the consensus backup node of the target proposal is received, and the acquired root hash of the transaction set corresponding to the block number to be written is consistent with the root hash in the target proposal, determining that the transaction sets matched with the root hash in the target proposal exist in a managed transaction memory pool; or

And if the acquired root hash of the transaction set corresponding to the block number to be written is not consistent with the root hash in the target proposal after the consensus backup node of the target proposal is received, determining that the transaction sets matched with the root hash in the target proposal do not exist in a managed transaction memory pool.

5. The method of claim 4, upon receiving the consensus backup node for the target proposal, determining that the plurality of transaction sets matching the root hash in the target proposal are not present in the managed transaction memory pool, the method further comprising:

acquiring a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus main node through the managed transaction memory pool by the consensus backup node receiving the target proposal; and/or

And the common recognition backup node receiving the target proposal acquires a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the common recognition backup node which agrees with the target proposal through the managed transaction memory pool.

6. The method of claim 4, upon receiving the consensus backup node for the target proposal, determining that the plurality of transaction sets matching the root hash in the target proposal are not present in the managed transaction memory pool, the method further comprising:

7. The method of claim 6, further comprising:

and if the common-recognition backup node of the target proposal is received and a transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired in a specified time period, initiating view switching operation in the alliance chain.

8. The method according to claim 1 to 7,

the number of the transaction memory pools in the consensus master node is at least one;

9. The method of claim 8, wherein the first and second light sources are selected from the group consisting of,

when the number of the transaction memory pools in the consensus main node is multiple, the information intercommunication is carried out among the multiple transaction memory pools of the consensus main node;

10. The method of claim 1, after the consensus backup node receiving the target proposal performs a consensus operation on the target proposal, the method further comprising:

11. A method of consensus in a federation chain, comprising:

the consensus master node sends the target transaction set to a transaction memory pool of a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the sent transaction arrangement of the target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process;

12. The method of claim 11, wherein the destination offer further carries a block number to be written,

the method for determining whether the target transaction set matched with the root hash in the target proposal exists in a managed transaction memory pool comprises the following steps:

if the consensus backup node of the target proposal is received, and the acquired root hash of the transaction set corresponding to the block number to be written is consistent with the root hash in the target proposal, determining that the target transaction set matched with the root hash in the target proposal exists in a managed transaction memory pool; or

And if the acquired root hash of the transaction set corresponding to the block number to be written is not consistent with the root hash in the target proposal after the consensus backup node of the target proposal is received, determining that the target transaction set matched with the root hash in the target proposal does not exist in a managed transaction memory pool.

13. The method of claim 12, upon receiving the consensus backup node for the target proposal, determining that the target transaction set does not exist in the managed transaction memory pool that matches the root hash in the target proposal, the method further comprising:

acquiring the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the consensus main node through the managed transaction memory pool by the consensus backup node receiving the target proposal; and/or

And the common identification backup node receiving the target proposal acquires the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool from the transaction memory pool of the common identification backup node which agrees with the target proposal through the managed transaction memory pool.

14. The method of claim 12, upon receiving the consensus backup node for the target proposal, determining that the target transaction set does not exist in the managed transaction memory pool that matches the root hash in the target proposal, the method further comprising:

and the common-recognition backup node which receives the target proposal acquires the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool within a specified time period.

15. The method of claim 14, the method further comprising:

and if the common-recognition backup node of the target proposal is received and the target transaction set which corresponds to the block number to be written and is not in the managed transaction memory pool is not acquired in a specified time period, initiating view switching operation in the alliance chain.

16. The method according to any one of claims 12 to 15,

17. The method of claim 16, wherein the step of selecting the target,

18. The method of claim 12, after the consensus backup node receiving the target proposal performs a consensus operation on the target proposal, the method further comprising:

if the nodes in the alliance chain receive valid verification messages aiming at the target proposal from not less than 2f +1 nodes, generating a block recorded with the target transaction set corresponding to the target proposal; wherein f is the maximum number of abnormal nodes allowed in the federation chain.

19. An alliance chain system comprising an consensus primary node and a plurality of consensus backup nodes, wherein:

20. An alliance chain system comprising an consensus primary node and a plurality of consensus backup nodes, wherein:

the consensus main node selects a target transaction set from a managed transaction memory pool to generate a target offer and broadcasts the target offer to the consensus backup node in the alliance chain, wherein the target offer comprises a root hash formed by ordered arrangement of transactions of the target transaction set; sending the target transaction set to a transaction memory pool of a consensus backup node in the alliance chain through a managed transaction memory pool, wherein the transaction arrangement of the sent target transaction set is the same as the transaction arrangement of the target transaction set in the root hash process;