CN115664724A - Consensus method in block chain system, block chain system and consensus node - Google Patents

Abstract

An embodiment of the present specification provides a consensus method in a blockchain system, and a consensus node, including: sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool; acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks; and distributing the proposed block to other common identification nodes respectively, so that each common identification node acquires a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node respectively, and performs common identification processing on the acquired transaction list.

Description

Consensus method in block chain system, block chain system and consensus node

Technical Field

The embodiment of the present specification belongs to the technical field of a block chain, and in particular, relates to a consensus method in a block chain system, and a consensus node.

Background

The blockchain is a decentralized, distributed ledger that does not require trust of third parties. The block chain technology has the characteristics of multi-party writing, public transparency, non-tampering and the like. Block chains can be classified into public chains, alliance chains, and private chains according to different admission mechanisms. The alliance chain has an access control function, and only authorized nodes can join the alliance chain network, so that the alliance chain is safer and more efficient than the public chain network, and is mainly used for mutual cooperation among enterprises or institutions.

The block chain technology-based established alliance chain consisting of authoritative nodes is beneficial to breaking a data island, forms a credible record memory certificate among all alliance members, ensures the non-tampering property of uplink data, and realizes the cooperation of cross-region and cross-department.

One measure of blockchain performance is TPS (Transactions Per Second). The higher the TPS, the faster the transaction can be executed, verified and validated on the blockchain. Early public chain TPS were generally low and far from meeting the needs. The TPS of the alliance chain is generally greatly improved compared with the public chain, but is still obviously lower than a centralized transaction system, particularly the alliance chain with higher decentralization degree. It can be seen that the performance of the blockchain is a bottleneck that hinders the large-scale popularization of blockchain technology.

TPS is determined by two factors: the number of transactions each tile contains and the speed at which the tile is issued by the overall system. The greater the number of transactions per block, the faster the block-out speed, and the higher the TPS. However, these two parameters cannot be increased at will. As the blocks become larger, the time to propagate to the full network also increases. If the block out interval is too short to allow most nodes in the system to receive the newly released block, the block chain security is compromised. For a public chain represented by a PoW consensus protocol, a fork may occur in this case, resulting in some transactions that may be rolled back. Federation chains, since the identity and number of nodes participating in consensus can be controlled, can employ traditional distributed consensus protocols to generate blocks. In general, the number of the common nodes of the federation chain is much smaller than that of the public chain, and the bandwidth condition of the nodes is better, so the TPS is also much higher than that of the public chain. However, the transmission delay increases after the blocks in the alliance chain increase, and for the alliance chain network with large-scale nodes (for example, hundreds or even thousands of nodes), the block increase may result in a longer transaction execution time, the time for verifying the signature in the consensus protocol may also increase, and meanwhile, the drastic increase of the messages sent between the nodes may also cause network congestion, further increase the block transmission time, reduce the efficiency of achieving the consensus, and also affect the block output time of the next block.

It can be seen that the efficiency of consensus on blocks, whether public or alliance, has a large impact on TPS for a block-chain system. Therefore, how to improve the efficiency of the consensus on the blocks is very important for improving the performance of the blockchain system.

Disclosure of Invention

The present specification proposes a consensus method in a blockchain system, the method being applied to a master node selected from a plurality of consensus nodes participating in consensus in the blockchain system; wherein, in the local transaction pool of each of the plurality of consensus nodes, a local sub-chain is maintained respectively; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the method comprises the following steps:

sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identifiers corresponding to respective subblocks in the set of subblocks;

and respectively distributing the proposed block to other common identification nodes, so that each common identification node respectively acquires a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node, and performs common identification processing on the acquired transaction list.

The present specification further provides a consensus method in a blockchain system, where a plurality of consensus nodes participating in consensus in the blockchain system include an elected master node; the method is applied to any consensus node in the plurality of consensus nodes except the master node; wherein, in the local transaction pool of each of the plurality of consensus nodes, a local sub-chain is maintained respectively; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the method comprises the following steps:

sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

acquiring an proposed block transmitted by the main node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

and acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool, and performing consensus processing on the acquired transaction list.

The present specification further provides a block chain system, which includes a plurality of common nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in a local transaction pool of each of the plurality of common nodes; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; wherein:

the main node is used for broadcasting the local sub-chain maintained in the local transaction pool to other various consensus nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool; acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks; distributing the proposed blocks to other common nodes respectively;

the other common nodes except the main node broadcast the local sub-chain maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool; and acquiring the proposed block transmitted by the main node, acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool, and performing consensus processing on the acquired transaction list.

The present specification further provides a consensus node in a blockchain system, where the blockchain system includes a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in a local transaction pool of each of the plurality of common nodes; the local sub-chain comprises a plurality of sub-blocks created by the respective consensus nodes based on transactions stored in a local transaction pool; the method comprises the following steps:

the first sending module is used for sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool;

the creating module is used for acquiring a sub-block set from each local sub-chain maintained in the local transaction pool and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks;

and the transmission module is used for respectively distributing the proposed blocks to other common identification nodes, so that each common identification node respectively acquires the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node, and performs common identification processing on the acquired transaction list.

The present specification further provides a consensus node in a blockchain system, where the blockchain system includes a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in a local transaction pool of each of the plurality of common nodes; the local sub-chain comprises a plurality of sub-blocks created by the respective consensus nodes based on transactions stored in a local transaction pool; the method comprises the following steps:

the second sending module is used for sending the local sub-chain broadcast maintained in the local transaction pool to other each common node; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

the acquisition module acquires the proposed block transmitted by the main node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

and the consensus module is used for acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool, and performing consensus processing on the acquired transaction list.

In the above embodiment, on the one hand, since each consensus node in the blockchain system can create the transaction stored in the local transaction pool into a form of a local sub-chain composed of several sub-blocks to be maintained in the local transaction pool, and before the master node creates the proposed block, the transaction list contained in the proposed block is distributed to each consensus node in advance: therefore, by means of the method, a pre-transmission mechanism can be introduced into the blockchain system, and the distribution process of the proposed block and the consensus process aiming at the proposed block are decoupled, so that before the master node creates the proposed block, idle bandwidth of other consensus nodes except the master node can be fully utilized, a transaction list contained in the proposed block is distributed to the consensus nodes in advance, each consensus node can participate in the distribution process of the consensus data, and the throughput of the consensus protocol is greatly improved.

On the other hand, when the master node creates the proposed block, the proposed block may not contain the transaction list any more, but only the sub-block identifier of the sub-block where the transaction list is located; therefore, the data capacity of the proposed block is no longer related to the transaction amount contained in the proposed block, so that the bandwidth consumption for transmitting the proposed block is independent of the transaction amount in the block, thereby significantly reducing the data capacity and bandwidth load of the master node in distributing the proposed block to other respective consensus nodes, and improving the consensus efficiency in consensus on the proposed block.

In a third aspect, since each sub-block included in the proposed block generated by the main node is autonomously generated by each consensus node other than the main node based on the transactions stored in the local transaction pool, the transaction sequence of the transactions included in each sub-block can be autonomously determined by each consensus node; therefore, each consensus node can participate in the transaction sequencing in this way, so that the monopoly of the master node on the transaction sequencing can be weakened, and the whole consensus algorithm is fairer.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a flow diagram illustrating a method of consensus in a blockchain system in accordance with an exemplary embodiment of the present specification;

FIG. 2 is a schematic diagram illustrating a chained transaction pool structure of consensus nodes in accordance with an exemplary embodiment of the present specification;

FIG. 3 is a diagram illustrating a data format of a sub-block according to an exemplary embodiment;

FIG. 4 is a schematic diagram illustrating another data format of a sub-block according to an example embodiment;

FIG. 5 is a schematic diagram of node1 launching a bifurcation attack, shown in accordance with an exemplary embodiment;

FIG. 6 is a diagram illustrating a data format corresponding to a proposed block according to an exemplary embodiment;

FIG. 7 is a diagram illustrating another data format for a proposed block according to an exemplary embodiment;

FIG. 8 is a schematic diagram of the conventional stage of the pbft algorithm shown by the present description according to an exemplary embodiment;

FIG. 9 is a schematic diagram of the conventional stages of another pbft algorithm shown herein in accordance with an exemplary embodiment;

FIG. 10 is a flow chart illustrating another consensus method in a blockchain system in accordance with an exemplary embodiment of the present specification;

FIG. 11 is a schematic block diagram of an electronic device shown in accordance with an exemplary embodiment of the present description;

FIG. 12 is a block diagram illustrating a consensus node in a blockchain system in accordance with an illustrative embodiment of the present specification;

fig. 13 is a block diagram illustrating a consensus node in another blockchain system in accordance with an example embodiment of the present specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Many block chains, especially federation chains, commonly employ a leader-based protocol in which there is a master node. For example, typical leader-based consensus protocols are PBFT (Practical Byzantine Fault Tolerance), PAXOS, RAFT (Replicated And Fault Tolerant), hotStuff, and so on. By adopting a leader-based consensus protocol, a main node can be elected from consensus nodes participating in consensus in a block chain system, a proposal block is created by the main node, and then the consensus protocol can coordinate the consensus nodes so that the consensus nodes can agree on the proposal block created by the main node.

For the leader-based consensus protocol, the data capacity of the proposed block created by the master node in the primary consensus process determines the throughput of the current consensus. When the number of the consensus nodes is larger, the number of messages sent by the consensus nodes to achieve the consensus in the whole consensus process is proportional to the number of the nodes.

In order to improve the efficiency of consensus, in the related art, by more tending to reduce the message complexity in the consensus process; for example, the Hotstuff consensus protocol isFor example, the Hotstuff consensus protocol is based on the Pbft protocol, and the complexity of the consensus protocol is increased from O (n) ² ) Reducing to O (n) greatly improves the scalability of the consensus algorithm.

However, in practical applications, there is not only the complexity of the messages in consensus, but also the bandwidth load when the master node distributes the created proposed block to other respective consensus nodes.

Specifically, in the federation chain, a consensus requires a consensus on a large number of transactions, typically 250B in size for a transaction, and 100KB in size for a block containing 400 transactions.

Based on the common consensus process of the leader-based consensus protocol, after the master node distributes the created proposed block to all other consensus nodes, in the subsequent consensus phase for the proposed block, each other consensus node usually only needs to send signature data for the proposed block. While one signature data typically does not exceed 100B, it follows that the data bandwidth consumption of the master node to distribute the proposed block to all other consensus nodes is hundreds of times greater than in the subsequent consensus phase.

It can be seen that the master node has a greater impact on the overall consensus performance at the stage of distributing the proposed block. If the proposed block distributed by the master node contains a larger number of transactions, the greater the throughput in one consensus. However, in practical applications, the bandwidth of a master node is limited, and the larger the amount of data contained in a proposed block that needs to be distributed in one consensus is, the longer the master node takes to distribute the proposed block to other nodes, which may result in longer time for subsequent consensus.

From the above analysis, it can be seen that, for the leader-based consensus protocol, the throughput in the primary consensus process is usually determined by the bandwidth of the primary node. Alternatively, it can be understood that in a consensus process, only the bandwidth of the master node is used when the master node distributes the proposed block, and the bandwidths of the other consensus nodes are usually idle at other times and cannot be fully utilized.

Based on this, the application aims at the problem that the existing leader-based consensus protocol cannot fully exert the bandwidth of the consensus node, introduces a pre-transmission mechanism into the block chain system, and designs a data distribution strategy based on a parallel chain, so that when the proposed block is distributed, the idle bandwidth of each consensus node except the main node in the consensus process can be fully utilized, the bandwidth consumption when the proposed block is distributed is reduced to a constant level from a linear level, the throughput of the whole consensus algorithm can be greatly improved, the block transmission delay is reduced, and the consensus efficiency when the proposed block is subjected to consensus is improved. In implementation, on one hand, a local sub-chain respectively maintained in the local transaction pool of each common node may be designed based on an existing blockchain of the blockchain system, and transactions stored in the local transaction pool of each common node participating in common in the blockchain system are created into a local sub-chain composed of a plurality of sub-blocks, and then the local sub-chain is respectively maintained in the respective local transaction pool.

On the other hand, a pre-transmission mechanism may be introduced into the blockchain system, so that each of the consensus nodes uses its own idle bandwidth to broadcast and send the local sub-chain maintained in the local transaction pool to other respective consensus nodes in advance before the master node creates the proposed block, and receives the local sub-chain maintained in the local transaction pool broadcast and sent by other respective consensus nodes, and maintains the received local sub-chain in the local transaction pool.

When the master node creates the proposed block, the local sub-chains maintained in the local transaction pools of the respective consensus nodes are maintained in the local transaction pool of the master node, and at this time, the master node may acquire the sub-block set from the respective local sub-chains maintained in the local transaction pool, and create the proposed block based on the acquired sub-block set. The proposed block may no longer include the transaction list to be identified, but only include the sub-block id corresponding to each sub-block in the sub-block set.

After the host node creates the proposed block, the host node may distribute the proposed block to other respective consensus nodes, and after receiving the proposed block distributed by the host node, the other respective consensus nodes may obtain, from respective local sub-chains maintained in their local transaction pools, transaction lists included in respective sub-blocks corresponding to the sub-block identities, and then perform consensus processing on the obtained transaction lists.

In the above technical solution, on one hand, by introducing the pre-transmission mechanism into the blockchain system, the distribution process of the proposed block and the consensus process for the proposed block can be decoupled, so that before the master node creates the proposed block, idle bandwidths of other consensus nodes except the master node can be fully utilized, and a transaction list included in the proposed block is distributed to the consensus nodes in advance, so that each consensus node can participate in the distribution process of the consensus data, thereby greatly improving throughput of the consensus protocol.

On the other hand, when the master node creates the proposed block, the proposed block may no longer contain the transaction list, but only contain the sub-block identifier of the sub-block in which the transaction list is located; therefore, the data capacity of the proposed block is no longer related to the transaction amount contained in the proposed block, so that the bandwidth consumption for transmitting the proposed block is independent of the transaction amount in the block, thereby significantly reducing the data capacity and bandwidth load of the master node in distributing the proposed block to other respective consensus nodes, and improving the consensus efficiency in consensus on the proposed block.

In a third aspect, since each sub-block included in the proposed block generated by the main node is autonomously generated by each consensus node other than the main node based on the transactions stored in the local transaction pool, the transaction sequence of the transactions included in each sub-block can be autonomously determined by each consensus node; therefore, each consensus node can participate in transaction sequencing in this way, monopoly of the master node on the transaction sequencing can be weakened, and the whole consensus algorithm is more fair.

Referring to fig. 1, fig. 1 is a flow chart illustrating a consensus method in a blockchain system comprising a plurality of consensus nodes according to an exemplary embodiment of the present disclosure; the plurality of consensus nodes comprise main nodes selected based on a leader-based consensus algorithm adopted by the block chain system, and the method can be applied to the main nodes; the method comprises the following steps:

102, sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

the leader-based consensus algorithm adopted by the block chain system may specifically include a leader-based bayer consensus algorithm, or may include a leader-based non-bayer consensus algorithm.

For example, typical leader-based Byzantine consensus algorithms may include, for example, PBFT consensus algorithms and HotStuff consensus algorithms, among others. Typical leader-based non-Byzantine consensus algorithms may include, for example, the PAXOS consensus algorithm and the RAFT consensus algorithm, among others.

In this specification, a local subchain that is respectively maintained in a local transaction pool of each common node may be designed on the basis of an existing blockchain of a blockchain system.

The local sub-chain may specifically include a plurality of lots (hereinafter referred to as a sub-blockchain) created based on the transactions stored in the local transaction pool of each consensus node participating in consensus in the blockchain system. By the design, the transactions stored in the local transaction pools of all the consensus nodes can be orderly packed into the sub-blocks.

It should be noted that, a local sub-chain described in this specification refers to a sub-chain structure that is autonomously created by each common node based on transactions stored in a local transaction pool, and the sub-chain structure is independently maintained by each common node in its local transaction pool. Between different consensus nodes, there is no need to cross-validate or confirm local child chains maintained in their local transaction pools with other consensus nodes.

In an embodiment shown, when creating a sub-block based on transactions stored in a local transaction pool, each consensus node may specifically obtain a transaction list from the local transaction pool periodically based on a blocking period of the sub-block, and create the sub-block based on the obtained transaction list.

For example, in one example, the blocking period may be 1 ms, and each consensus node may fetch a batch of transactions from the local transaction pool every 1 ms and pack the batch of transactions into a sub-block, so that the transactions stored in the local transaction pool can be packed into the sub-block in order.

It should be noted that, in practical application, the blocking period of the sub-block may be flexibly set based on actual requirements; for example, in one example, the transaction list contained in the sub-block is eventually packaged into a proposal block, and the transaction amount that can be accommodated by the proposal block is usually an integer multiple of the transaction amount that can be accommodated by the sub-block; for example, a proposed chunk may be formed by the master node based on packing N sub-chunks. In this case, the period duration corresponding to the blocking period of the proposed block may be an integer multiple of the period duration corresponding to the blocking period of the sub-block.

Further, after each of the common node creates a sub-block based on the obtained transaction list, the sub-block may be linked with the latest sub-block on the local sub-chain maintained in the local transaction pool.

For example, the hash value of the latest sub-block on the local sub-chain maintained in the local transaction pool may be filled in the data format of the created sub-block, the created sub-block is linked with the latest sub-block, and after the linking is completed, the created sub-block becomes the latest sub-block on the local sub-chain.

In this specification, a pre-transmission mechanism may be further introduced into the blockchain system, so that each consensus node broadcasts the local sub-chain maintained in the local transaction pool to other consensus nodes in advance by using its own idle bandwidth before the master node creates the proposed block.

For each consensus node, on one hand, the local sub-chain maintained in the local transaction pool can be broadcast and sent to other respective consensus nodes; on the other hand, the local sub-chain maintained in the local transaction pool broadcasted by each other common node can be received, and the received local sub-chain is maintained in the local transaction pool.

By adopting the pre-transmission mechanism, each common node receives all local sub-chains maintained in the local trading pool of the common node, and finally all the local sub-chains received by each common node form a structured chain trading pool structure formed by a plurality of sub-chains.

For example, referring to fig. 2, taking the above-mentioned blockchain system including 4 consensus nodes participating in consensus (node 1-node4 shown in fig. 2) as an example, the local trading pool of each consensus node will form a structured chain trading pool structure composed of 4 sub-chains as shown in fig. 2. Wherein, bth _ i _ j on fig. 2 represents jth Batch generated by ith consensus node.

In an embodiment shown in the drawing, when each consensus node broadcasts the local sub-chain maintained in the local transaction pool to other respective consensus nodes, the new sub-blocks in the local sub-chain may be periodically broadcast to other respective consensus nodes in an incremental synchronization manner. That is, when a sub-block is added to the local sub-chain in a new blocking period, the added sub-block can be broadcast and sent to other respective common nodes in time. Correspondingly, each common node can also receive other common nodes and periodically broadcast and send newly-added sub-blocks on the local sub-chain.

Through the method, each consensus node can periodically broadcast and send the newly added sub-blocks to other consensus nodes according to the blocking period corresponding to the sub-blocks on the local sub-chain, so that the problem of excessive bandwidth consumption caused by the fact that the local sub-chain is integrally synchronized to other consensus nodes can be avoided.

It should be emphasized that, in practical applications, when the block chain system does not pay attention to bandwidth consumption, the broadcast of the entire local child chain may be transmitted to other respective common nodes.

In an embodiment shown, please refer to fig. 3, where fig. 3 is a schematic diagram of a data format corresponding to a sub-block shown in this specification.

As shown in fig. 3, the data format of the sub-block may specifically include a Batch header (i.e., a sub-block header) and a TX List (transaction List) field. The Batch header may further include a Previous Batch Hash field, a Batch Height field (i.e., a Height field), a Merkle Root field, and a Batch Tip List field (i.e., a List of indications field).

The Previous Hash field is used for filling the Hash value of the Previous sub-block linked in the local sub-chain to which the sub-block belongs;

a Batch Height field for filling a subblock identifier indicating a subblock Height in the local subblock to which the subblock belongs; the sub-block id may be a global id in the blockchain system. For example, as previously described, the sub-tile identifier may be in a form such as Bth _ i _ j, representing the jth Batch generated by the ith consensus node. The value of j represents the block height of the Batch on the local child chain to which the Batch belongs.

A Merkle Root field used for filling the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub block;

batch Tip List field: for populating a height list of block heights of the latest sub-block on the local sub-chain corresponding to the other respective common node stored in the local transaction pool at the time of creating the current sub-block.

It should be noted that the height List filled in the Batch Tip List field may generally indicate the receiving progress of the local sub-chain corresponding to each other common node locally stored by the current common node at the time of creating the sub-block.

For example, please continue to refer to fig. 2, assume that node1 shown in fig. 2 is at the time of creating this sub-block of Bth _1 \5, at this time, the latest sub-block on the local sub-chain corresponding to node2 maintained in the local transaction pool is Bth _2 \5, and the corresponding block height is 5; the latest sub-block on the local sub-chain corresponding to the node3 is Bth _3 \5, and the corresponding block height is also 5; the latest sub-block on the local sub-chain corresponding to the node4 is Bth _4 \5, and the corresponding block height is also 5; in this case, the height List populated in the Batch Tip List field contained in the data structure of this sub-chunk of Bth _1 _5can be expressed as [ 1. The significance of this high list at this time is that node1 updates the latest sub-block corresponding to node1 and the corresponding local sub-chain maintained in the local transaction pool of node1 to Bth _1_5, the latest sub-block corresponding to node2 and the corresponding local sub-chain maintained in the local transaction pool of node1 to Bth _2_5, the latest sub-block corresponding to node3 and the corresponding local sub-chain maintained in the local transaction pool of node1 to Bth _3_5, and the latest sub-block corresponding to node4 and the corresponding local sub-chain maintained in the local transaction pool of node1 to Bth _4 _5at the time of creating Bth _1 _5. It will be appreciated that the height List populated in the Batch Tip List field above, in effect, represents the progress of receipt in the respective child chains maintained in the node1 local transaction pool. It should be noted that, if the block chain system employs a leader-based non-byzantine consensus algorithm (such as RAFT or PAXOS), the data format of the sub-block may be the data format shown in fig. 2.

Since the byzantine consensus algorithm generally considers the situation that a byzantine node (i.e., a malicious node) exists in the consensus nodes, in a block chain system adopting the byzantine consensus algorithm, it is generally necessary to sign transmitted data and verify whether the data is tampered by the byzantine node based on a signature verification mechanism.

In this case, if the consensus protocol adopted by the blockchain system is a leader-based byzantine consensus algorithm; such as pbft or HotStuff; when designing the data format of the sub-block, it is usually necessary to introduce a signature field into the data format of the sub-block.

Referring to fig. 4, fig. 4 is a schematic diagram illustrating another data format corresponding to a sub-block shown in this specification.

If the consensus protocol adopted by the blockchain system is a leader-based byzantine consensus algorithm, the data format designed for the sub-blocks can be as shown in fig. 4. In the data format of the sub-block shown in fig. 4, in addition to the fields shown in fig. 3, a Signature field may be included.

The Signature field may be specifically used to fill in the Signature of the subblock by the creator of the subblock. It should be noted that the signature of the sub-block may specifically be a signature submitted for the whole sub-block, or may be a signature submitted for only a sub-block header of the sub-block, and is not particularly limited in this specification.

In an embodiment shown in the present disclosure, after the received local sub-chain maintained in the local transaction pool of the other common node is broadcast by the common node through the above-described pre-transmission mechanism, the common node may also perform validity verification on the sub-block included in the received local sub-chain, and after the validity verification passes, maintain the received local sub-chain in the local transaction pool.

Of course, for the blockchain system with a higher admission threshold and a higher trust degree, after each of the common node receives the local sub-chain maintained in the local transaction pool broadcast by another common node, the received local sub-chain may be directly maintained in the local transaction pool without performing validity verification on the sub-block included in the received local sub-chain.

It should be noted that, the validation entries that need to be executed when each consensus node performs validity validation on the received sub-blocks included in the local sub-chain generally correspond to the fields included in the data structure of the sub-blocks.

In an embodiment shown, when each consensus node performs validity verification on a sub-block, the verification items required to be performed generally include at least one or a combination of more of the following verification items:

verification item 1:

verifying the signature filled in the signature field of the sub-block; if the signature passes the verification, further performing the next verification; otherwise, it is determined that the validity verification for the sub-block fails.

Verification item 2:

verifying whether a Previous sub-block linked by the sub-block and indicated by a Hash value filled in a Previous Hash field of the sub-block is stored in a local transaction pool; if yes, further executing the next verification; otherwise, the last sub-block is further acquired to the common node for creating the last sub-block.

By performing verification item 2, it can be ensured that the last tile of the local transaction pool to which the link to this tile has been stored.

Verification item 3:

verifying whether other sub-blocks which link the same last sub-block with the sub-block are stored in a local transaction pool; if yes, determining that the validity verification aiming at the sub-block fails; otherwise, further executing the next verification;

by performing the verification item 3, it is possible to avoid the situation where two conflicting sub-blocks linking the same block are stored in the local transaction pool at the same time. This is often the case due to malicious forking of the generation of a malicious node (i.e., a byzantine node) on the local child chain. For example, referring to fig. 5, assuming node1 shown in fig. 2 has launched a bifurcation attack, two sub-blocks Bth _1_3 and Bth _1_3' may be created that simultaneously link sub-blocks Bth _1_2, respectively.

Verification item 4:

verifying whether the block height corresponding to other common identification nodes contained in the height list filled in the indication list field of the sub-block is increased compared with the block height corresponding to other common identification nodes contained in the height list filled in the indication list field of the last sub-block linked with the sub-block or not; if yes, further executing next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

in practical applications, the block heights of the local sub-chains corresponding to the other common nodes maintained in the local transaction pool are continuously incremented due to continuous reception of new sub-blocks, and once the block heights corresponding to the other common nodes included in the height list filled in the indication list field of a certain sub-block are not incremented, the sub-block may not be correctly filled with the newest sub-blocks corresponding to the other common nodes included in the indication list field of the sub-block at the time of creation (specifically, the reason may be that a malicious node intentionally has occurred), when the sub-block is a created error sub-block. Based on this, by performing the verification item 4, the above-mentioned erroneous sub-block can be discovered in time.

Verification item 5:

verifying the signature of each transaction in the transaction list contained in the sub-block; if the signature verification for each transaction is passed, further performing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

by executing the verification item 5, malicious nodes can be prevented from maliciously tampering with the transaction content of the transactions in the transaction list.

Verification item 6:

verifying whether the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub-block is the same as the hash value filled in the Merkle Root field of the sub-block; if yes, determining that the validity verification aiming at the sub-blocks passes; otherwise, determining that the validity verification for the sub-block fails.

By implementing the validation item 6, it is ensured that the correct transaction list is contained in the sub-block.

It should be noted that the execution sequence of each verification item shown above is not particularly limited in this specification, and in practical applications, the corresponding sequence may be flexibly established based on actual requirements. When the consensus algorithms adopted by the block chain system are two cases, namely, a leader-based bayer consensus algorithm and a leader-based non-bayer consensus algorithm, respectively, each consensus node needs to perform a validation item when performing validity validation on a sub-block, and a certain difference may exist usually.

In an embodiment shown, if the consensus algorithm adopted by the blockchain system is leader-based, a byzantine consensus algorithm, respectively, the data format of the sub-blocks may be as shown in fig. 3. Since the byzantine consensus algorithm generally considers the case that a byzantine node (i.e., a malicious node) exists in the consensus nodes, and in a block chain system adopting the byzantine consensus algorithm, it is generally necessary to sign transmitted data and verify whether the data is tampered by the byzantine node based on a signature verification mechanism, in this case, when each consensus node performs validity verification on a sub-block, the verification items to be performed may include the above-mentioned verification items 1 to 6.

In an implementation shown, each common node may also locally maintain a blacklist, where the blacklist is specifically used for maintaining malicious nodes discovered in the process of performing validity verification on the sub-block or the proposed block. And in the process of executing the verification item 3, if other sub-blocks which link the same last sub-block with the sub-block are stored in the local transaction pool, the creators of the sub-block and the other sub-blocks can be further determined, and the creators are added to a local blacklist as malicious nodes.

In addition, in one implementation, the sub-block and the other sub-block may be broadcast to other respective common nodes, so that the other respective common nodes verify whether the sub-block and the other sub-block link to the same previous sub-block, and when it is verified that the sub-block and the other sub-block do link to the same previous sub-block, the creator of the sub-block and the other sub-block may be further determined and added to the blacklist as a malicious node; for example, in implementation, only the sub-block header of the sub-block and the other sub-block may be broadcast to other respective common nodes, so that the other respective common nodes may perform the verification based on the information recorded in the sub-block header, and determine the creator of the sub-block and the other sub-block based on the information recorded in the sub-block header.

Or, in another implementation manner, the information of the determined creator may also be directly broadcast and sent to other respective consensus nodes, so that the other respective consensus nodes add the creator to the blacklist as a malicious node.

It should be noted that the sub-blocks created by the malicious nodes maintained in the black list will not be added to the proposed blocks subsequently created by the master node. For example, in one example, the master node, in the stage of creating the proposed block, may exclude, based on the blacklist, sub-blocks created by malicious nodes maintained in the blacklist from the proposed block.

In an embodiment shown, if the consensus algorithm adopted by the blockchain system is leader-based non-byzantine consensus algorithm, the data format of the sub-blocks may be as shown in fig. 2. Since the non-byzantine consensus algorithm does not generally need to consider the case where a byzantine node exists among the consensus nodes, in this case, the authentication items that need to be performed by each consensus node when performing validity authentication for a sub-block may include the above-mentioned authentication item 2, authentication item 4, and authentication item 6. That is, the above-mentioned authentication item 1, authentication item 3, and authentication item 5 need not be performed. 104, acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identifiers corresponding to respective subblocks in the set of subblocks;

as mentioned above, by using the pre-transmission mechanism described above, each common node receives all local sub-chains maintained in the local transaction pool of the common node, and finally, all local sub-chains received by each common node form a structured chain transaction pool structure composed of a plurality of sub-chains.

The master node may obtain a set of sub-blocks to be identified from each local sub-chain in a chain transaction pool structure maintained in the local transaction pool, and then create an proposed block based on the obtained set of sub-blocks. For example, in implementation, the master node may periodically obtain the set of sub-blocks to be identified from each local sub-chain maintained in the local transaction pool according to the blocking period of the proposed block.

It should be noted that, a specific manner in which the master node acquires the sub-block set from each local sub-chain maintained in the local transaction pool is not particularly limited in this specification.

In this specification, when the master node acquires a sub-block set from each local sub-chain maintained in the local transaction pool, the master node may specifically refer to a height list filled in the latest sub-block in each local sub-chain, and segment each local sub-chain maintained in the local transaction pool according to the receiving progress of the local sub-chain corresponding to each consensus node represented by the height list, so as to determine the sub-block set that needs to be added to the proposed block.

The specific manner of segmenting each local sub-chain maintained in the local transaction pool according to the receiving progress of the local sub-chain corresponding to each common identification node represented by the height list is not particularly limited in this specification, and in practical application, the determination can be flexibly performed based on a specific scene.

In an illustrated embodiment, the master node may use, as a reference, a local sub-chain with the slowest receiving progress from local sub-chains corresponding to the respective common identification nodes maintained in the local transaction pool, and segment the respective local sub-chains by determining a common height of a latest sub-block in the local sub-chains.

In this case, the master node may first determine the latest sub-block in each local sub-chain maintained in the local transaction pool, respectively, and further obtain the height List populated in the Batch Tip List field in the sub-block header of the latest sub-block in each local sub-chain.

After the height List filled in the Batch Tip List field in the sub-block header of the latest sub-block in each local sub-chain is obtained, based on the obtained height List, the common node with the slowest reception progress in each common node may be used as a reference, so as to further determine a common height between the block height of the latest sub-block in each sub-chain maintained in the local transaction pool of the master node and the block height of the latest sub-block in each sub-chain maintained in the local transaction pools of other respective common nodes.

After determining the common height, the master node may use the common height as a dividing point, obtain a sub-block set formed by sub-blocks having block heights not greater than the common height from each local sub-chain maintained in a local transaction pool of the master node, and create a proposed block based on the obtained sub-block set.

For example, in an example, please continue to refer to fig. 2, if node1 in fig. 2 is the master node, the master node local transaction pool maintains a height List populated in the Batch Tip List field of the newest subblock (i.e., the subblock with the largest block height) on the local subchain corresponding to nodes 1-4, as shown in table 1:

node numbering	Batch Tip List
		Node1 (Master Node)	[1:5,2:5,3:5,4:5]
Node2	[1:5,2:5,3:4,4:3]
		Node3	[1:3,2:4,3:5,4:5]
Node4	[1:3,2:3,3:4,4:6]

TABLE 1

Wherein, it should be explained that, in the above table, the [1,2, 5,3; "2; "3; "4.

[1,5,2; [1,3,2; [1,3,2; the meanings of these height lists are similar to those of the height lists filled in the Batch Tip List field of the newest subblock on the local subchain corresponding to node1, which is maintained in the local transaction pool with node1 and described above, and are not described again.

Based on the above table, when the master node divides the local sub-chains according to the common height of the latest sub-block in the local sub-chain corresponding to each common node, which is maintained in the local transaction pool, the master node may specifically determine the common height of the latest sub-block in the local sub-chain corresponding to each common node, by using the common node in each common node, which has the slowest receiving progress for the local sub-chains, as a reference.

As can be seen from the above table, the common node of node1-node4, which has the slowest receiving progress for the local child chain corresponding to node1, is node3 and node4, and both receive the 3 rd child block, and at this time, the common height of the local child chain corresponding to node1, which is maintained in the local transaction pool by node1-node4, is 3.

At this time, the master node may select Bth _1 _1to Bth _1 _3from the local child chain corresponding to node1 maintained in the local transaction pool as the set of child blocks to be added to the proposal block.

As can be seen from the above table, the node1-node4 has the slowest receiving progress for the local child chain corresponding to the node2, and is the node4, and in order to receive the 3 rd child block, the common height of the local child chain corresponding to the node2, which is maintained in the local transaction pool by the node1-node4, is 3.

At this time, the master node may select Bth _2 _1to Bth _2 _3from the local child chain corresponding to node2 maintained in the local transaction pool as the set of child blocks to be added to the proposal block.

As can be seen from the above table, the common node of node1-node4, which has the slowest receiving progress for the local child chain corresponding to node3, is node2 and node4, and both receive the 4 th child block, and at this time, the common height of the local child chain corresponding to node3, which is maintained in the local transaction pool by node1-node4, is 4.

At this time, the master node may select Bth _3 _1to Bth _3 _4from the local child chain corresponding to node3 maintained in the local transaction pool as the set of child blocks to be added to the proposal block.

Continuing with the above table, the node1-node4 has the slowest receiving progress for the local child chain corresponding to the node4, that is, the node2, and is to receive the 3 rd child block, where the common height of the local child chain corresponding to the node4 maintained by the node1-node4 in its local transaction pool is 3.

At this time, the master node may select Bth _4 \1to Bth _4 \3from the local child chain corresponding to node4 maintained in the local transaction pool as the child block set to be added to the proposed block.

Based on the above table, the sub-block set selected by the master node from 4 local sub-chains corresponding to node1-node4 maintained in the local transaction pool can be recorded as [ Bth _1_3, bth_2_3, bth_3_4, bth_4 \3 ];

wherein, in the recording, bth _1 \3represents Bth _1 \1to Bth _1 \3on the local sub-strand corresponding to node 1; bth _2 \3represents Bth _2 \1to Bth _2 \3on the local daughter strand corresponding to node 2; bth _3 \4represents Bth _3 \1to Bth _3 \4on the local daughter strand corresponding to node 3; bth _4 \3represents Bth _4 \1to Bth _4 \3on the local daughter strand corresponding to node 4.

In another embodiment shown, the master node may also use, as a reference, N local sub-chains with the fastest reception rate from the local sub-chains corresponding to the respective common identification nodes maintained in the local transaction pool, and segment the respective local sub-chains by determining a common height of a latest sub-block in the local sub-chains.

In this case, after acquiring the height List filled in the Batch Tip List field in the sub-block header of the latest sub-block in each local sub-chain, the master node may further determine, based on the acquired height List, the N common nodes with the largest block height of the latest sub-block in each local sub-chain (i.e., the N common nodes with the fastest reception progress for each local sub-chain) maintained in the local transaction pool of the master node and the local transaction pools of other respective common nodes;

then, the receiving progress of the N common nodes can be used as a reference, and a common height between block heights of latest sub-blocks on each local sub-chain maintained in a local transaction pool of the N common nodes is further determined;

after determining the common height, the master node may use the common height as a dividing point, obtain a sub-block set formed by sub-blocks having block heights not greater than the common height from each local sub-chain maintained in a local transaction pool of the master node, and create a proposed block based on the obtained sub-block set.

The value of N may be the maximum fault-tolerant node number of the consensus node involved in the consensus in the block chain system. The value of N may be a value less than the total number of common nodes in the blockchain system.

For example, if the consensus algorithm adopted by the block chain system is a leader-based byzantine consensus algorithm, the total number of consensus nodes participating in consensus by the block chain system is 3f +1, and the value of N is 2f +1. If the consensus algorithm adopted by the block chain system is a leader-based non-Byzantine consensus algorithm, the total number of consensus nodes participating in consensus of the block chain system is f, and the value of N is f/2+1.

For example, in another example, still taking node1 in fig. 2 as the master node, the master node local transaction pool maintains a height List populated in the Batch Tip List field of the newest subblock on the local subchain corresponding to node1-node4 (i.e. the subblock with the largest block height), which is also illustrated in table 1 as an example. Assuming that the consensus algorithm adopted by the blockchain system is a byzantine consensus algorithm, and the number of the consensus nodes of the blockchain system is 4, the value of f is 1, and at this time, the value of N is 2f +1=3.

By analogy with the receiving progress of the node1-node4 in the table 1 for each local sub-chain, the receiving progress of the node4 for the local sub-chain corresponding to the node1-node3 is the slowest, so the node4 with the slowest receiving progress is removed, and the master node can determine the 3 common nodes such as the node1-node3 as the 3 common nodes with the largest block height of the latest sub-block in each maintained local sub-chain (i.e. the N common nodes with the fastest receiving progress for each local sub-chain).

Further, the master node may further determine a common height between block heights of the latest sub-blocks on the local sub-chain corresponding to node1-node4 maintained in the local transaction pool for node1-node 3. For a specific manner of the public height, please refer to the previous description, which is not repeated.

As can be seen from table 1, the common height between the block heights of the latest sub-blocks on the local sub-chain corresponding to node1 maintained in the local transaction pool of node1-node3 is 3; the common height between the block heights of the latest sub-blocks on the local sub-chain corresponding to the node2 maintained in the local transaction pool of the nodes 1 to 3 is 4; the common height between the block heights of the latest sub-blocks on the local sub-chain corresponding to the node3 maintained in the local transaction pool of the node1-node3 is 4; the common height between the block heights of the latest sub-blocks on the local sub-chain corresponding to node4 maintained in the local transaction pool of nodes 1-3 is 3.

At this time, the master node may select Bth _1 _1to Bth _1 _3as a sub-block set to be added to the proposal block from a local sub-chain corresponding to node1 maintained in the local transaction pool, select Bth _2 _1to Bth _2 _4as a sub-block set to be added to the proposal block from a local sub-chain corresponding to node2 maintained in the local transaction pool, select Bth _3 _1to Bth _3 _4as a sub-block set to be added to the proposal block from a local sub-chain corresponding to node3 maintained in the local transaction pool, and select Bth _4 _1to Bth _4 _3as a sub-block set to be added to the proposal block from a local sub-chain corresponding to node4 maintained in the local transaction pool.

Based on table 1, the sub-block set selected by the master node from 4 local sub-chains corresponding to node1-node4 maintained in the local transaction pool can be recorded as [ Bth _1_3, bth _2_4, bth _3_4, bth _4_3]. For node4 with the slowest receiving progress, the 4 th sub-block (i.e. Bth _2_4) on the local sub-chain corresponding to node2 needs to be received from other common nodes, so that the final common recognition can be completed with other several common nodes.

In this specification, when the master node acquires a set of sub-blocks that need to be added to a proposed block from each local sub-chain maintained in the local transaction pool in the splitting manner described in the above embodiment, a proposed block may be created based on the set of sub-blocks.

It should be noted that, because the pre-transmission mechanism described above is adopted in this specification, the master node acquires, from each local child chain maintained in the local transaction pool, a child block set that needs to be added to the proposed block, and synchronizes and stores the child block set in the local transaction pool of each common node in advance; therefore, in the present specification, the proposed block created by the master node based on the sub-block set may include the sub-block identifier corresponding to each sub-block in the sub-block set, and no longer include the data structure corresponding to each sub-block in the sub-block set. In this way, the proposed block will no longer contain the list of transactions to be agreed upon.

In an embodiment, please refer to fig. 6, wherein fig. 6 is a schematic diagram illustrating a data format corresponding to a proposed block in the present specification.

As shown in fig. 6, the data format corresponding to the proposed chunk may specifically include a Batch List field (i.e., a sub-chunk set field) and a Merkle Root field.

Wherein, the Batch List field is used for filling the sub-block identifiers corresponding to the sub-blocks in the sub-block set contained in the proposed block;

a Merkle Root field used for filling a hash value of a Root node of a Merkle tree created based on a transaction list contained in each subblock in the set of subblocks.

It should be noted that, if the block chain system adopts a leader-based non-byzantine consensus algorithm (such as RAFT or PAXOS), the data format of the proposed block may adopt the data format shown in fig. 6. If the block chain system adopts a consensus protocol, a leader-based Byzantine consensus algorithm is adopted; such as pbft or HotStuff; when designing the data format of the proposed block, it is usually necessary to introduce a signature field in the data format of the proposed block.

Referring to fig. 7, fig. 7 is a schematic diagram illustrating another data format corresponding to a proposed block in the present specification.

If the consensus protocol adopted by the blockchain system is the leader-based Byzantine consensus algorithm, the data format designed for the proposal can be as shown in FIG. 7. In the data format of the proposed block shown in fig. 7, a Signature field may be included in addition to the fields shown in fig. 6.

The Signature field may be used to fill in the Signature of the master node on the proposed block.

And 106, distributing the proposed block to other common identification nodes respectively, so that each common identification node acquires a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node respectively, and performs common identification processing on the acquired transaction list.

In this specification, after creating the proposed block according to the data format of fig. 6 or fig. 7, the master node may further distribute the proposed block to other respective consensus nodes.

In practical applications, the consensus protocol adopted by the blockchain system, whether it is a leader-based byzantine consensus algorithm or a leader-based non-byzantine consensus algorithm, usually includes a proposed block distribution mechanism for distributing the created proposed block by the master node in its corresponding algorithm flow.

Based on this, in the illustrated embodiment, when distributing the proposed block to other respective consensus nodes, the master node may specifically broadcast the proposed block to the other respective consensus nodes based on the proposed block distribution mechanism supported by the consensus protocol adopted by the blockchain system.

In one example, pbft is taken as an example, as a classic leader-based Byzantine consensus algorithm, the algorithm flow of pbft generally includes two processes, normal Case Phase and View Change Phase. Wherein the Normal Case Phase is called as the conventional stage in the algorithm flow of pbft, FIG. 8 is a flow chart of the Normal Case Phase process. As shown in fig. 8, the Normal Case Phase mainly includes three stages of PRE-PREPARE, PREPARE and COMMIT, where the node number 3 shown in fig. 8 may represent a down node (denoted by x in fig. 8).

Based on the algorithm flow in fig. 8, the primary node will typically attach the proposed block created based on the collected transactions sent by the client to a PRE-PREPARE message during the PRE-PREPARE phase, and then broadcast the PRE-PREPARE message to other blockchain nodes to distribute the proposed block to other consensus nodes.

In this scenario, if the consensus algorithm adopted by the blockchain system is pbft, the master node may specifically use the proposed block distribution mechanism in the PRE-PREPARE phase supported by pbft to broadcast the proposed block to other respective consensus nodes in the PRE-PREPARE phase attaching the proposed block to the PRE-PREPARE message in the PRE-PREPARE phase.

In another example, taking the example of HotStuff, which is also a leader-based bexating algorithm, unlike pbft, the conventional stages of the algorithm flow of HotStuff include four stages, namely PREPARE, PRE-COMMIT, and decode. Based on the algorithm flow of the HotStuff, the master node will usually attach the proposed block created based on the collected transactions sent by the client to a PREPARE message in the PREPARE phase, and then broadcast and send the PREPARE message to other block chain nodes to distribute the proposed block to other consensus nodes.

In this scenario, if the consensus algorithm adopted by the blockchain system is HotStuff, when the master node distributes the proposed block to other consensus nodes, the master node may specifically use the proposed block distribution mechanism in the PREPARE stage supported by HotStuff to attach the proposed block to PREPARE messages in the PREPARE stage, and broadcast the messages to other consensus nodes.

In a third example, taking raft as an example, as a classic leader-based non-byzantine consensus algorithm, the algorithm flow of raft usually includes two stages, namely, leader election (master node election), log replication (log synchronization), and the like. Based on the raft algorithm flow, the master node usually packages proposed blocks created based on collected transactions sent by the clients into individual log entries at the log replay stage, and then copies (replays) the log entries to other respective consensus nodes to distribute the proposed blocks to the other respective consensus nodes, respectively.

In this scenario, if the consensus algorithm adopted by the blockchain system is raft, when the host node distributes the proposed block to other consensus nodes, the host node may specifically use the proposed block distribution mechanism in log replication stage supported by raft to package the proposed block into log entries in log replication stage, and then copy (replicate) the log entries to other consensus nodes, so as to distribute the proposed block to other consensus nodes respectively.

In a fourth example, taking PAXOS as an example, PAXOS is also a leader-based non-byzantine consensus algorithm, and the algorithm flow of PAXOS generally includes two stages, namely PREPARE and Accept. Based on the PAXOS algorithm, the master node usually attaches the proposed block to an Accept message during the Accept phase, and broadcasts and transmits the proposed block to other respective consensus nodes, so as to distribute the proposed block to other respective consensus nodes.

In this scenario, if the consensus algorithm adopted by the block chain system is PAXOS, when the host node distributes the proposed block to other consensus nodes, the host node may specifically use the proposed block distribution mechanism in the Accept phase supported by PAXOS to attach the proposed block to an Accept message, and broadcast and send the proposed block to other consensus nodes, so as to distribute the proposed block to other consensus nodes respectively.

In the above embodiments, the pre-transmission mechanism described above may be organically combined with the proposed block distribution mechanism supported by the consensus algorithm employed by the blockchain system by distributing the proposed block to other respective consensus nodes using the proposed block distribution mechanism supported by the consensus protocol employed by the blockchain system.

Due to the adoption of the pre-transmission mechanism, the proposed block created by the main node can not contain a transaction list to be identified any more; therefore, the pre-transmission mechanism described above is organically combined with the proposed block distribution mechanism supported by the consensus algorithm adopted by the block chain system, so that the data capacity and bandwidth consumption of the sent message can be reduced when the proposed block is distributed by using the proposed block distribution mechanism supported by the consensus algorithm. It will be understood that the above-described pre-transmission mechanism, in combination with the proposed block distribution mechanism supported by the consensus algorithm adopted by the blockchain system, may actually perform an optimization effect on the proposed block distribution mechanism supported by the consensus algorithm.

For example, referring to fig. 9, still taking the consensus algorithm adopted by the above block chain system as pbft as an example, after organically combining the above PRE-transmission scheme with the proposed block distribution scheme supported by pbft, the above PRE-transmission scheme can be used as a PRE-transmission phase before the PRE-PREPARE phase of pbft.

Due to the adoption of the pre-transmission mechanism, the proposed block created by the main node can not contain a transaction list any more; therefore, the data capacity of the PRE-PREPARE message is significantly reduced when the master node broadcasts the proposed block generated in the PRE-PREPARE message to other individual blockchain nodes in the PRE-PREPARE phase. For example, in general, a PRE-PREPARE message is accompanied by a transaction List and a Merkle Root generated based on the transaction List, and after the PRE-transmission mechanism is combined with a PRE-PREPARE phase supported by pbft, the PRE-PREPARE message may only carry the above-mentioned Batch List field and Merkle Root field, and the size of the content filled in the Batch List field is obviously reduced from a linear level to a constant level with respect to the transaction List.

The significant reduction of data capacity of PRE-PREPARE messages will reduce the bandwidth consumption in the interaction of PRE-PREPARE messages, which obviously helps to improve the consensus efficiency of the pbft protocol itself.

It should be noted that, in the above description, only the consensus algorithm adopted by the blockchain system is pbft, in practical applications, when the consensus algorithm adopted by the blockchain system is other types of consensus algorithms, the pre-transmission mechanism may still be organically combined with the blockchain distribution mechanisms supported by the consensus algorithms, and as a pre-transmission stage before the first stage of the consensus algorithm, no one example is given in this specification.

In this specification, when any consensus node except the master node receives the proposed block distributed by the master node, validity verification may be performed on the obtained proposed block.

Of course, for the blockchain system with a higher admission threshold and a higher trust level, after each consensus node receives the proposed block distributed by the master node, the proposed block may not be subjected to validity verification.

It should be noted that, the verification items that each consensus node needs to perform when performing validity verification on the received proposed block generally correspond to the fields included in the data structure of the proposed block.

In an embodiment shown, when each consensus node performs validity verification on a sub-block, the verification items required to be performed generally include at least one or a combination of more of the following verification items:

verification item 7:

verifying against the signature filled in the signature field of the proposed block; if the signature passes the verification, further performing the next verification; otherwise, determining that the validity verification for the proposed block fails;

verification item 8:

verifying whether each subblock corresponding to the subblock identifier filled in the subblock set field of the proposed block is stored in a local transaction pool; if the sub-blocks are stored in the local transaction pool, further executing the next verification; otherwise, further acquiring the sub-blocks in each sub-block of the fir tree which is not stored in the local transaction pool from the main node or other consensus;

by performing the validation term 2, it is ensured that the local transaction pool has stored therein the various sub-blocks that the proposed block contains.

Verification item 9:

verifying whether the hash value of the Root node of the Merkle tree created based on the acquired transaction list contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determining that the validity verification for the proposed block passes; otherwise, it is determined that the validity verification for the proposed block fails.

By performing the validation item 9, it is ensured that the correct transaction list is contained in the sub-block.

It should be noted that the execution sequence of each verification item shown above is not particularly limited in this specification, and in practical applications, the corresponding sequence may be flexibly established based on actual requirements. When the consensus algorithms adopted by the block chain system are a leader-based bayer consensus algorithm and a leader-based non-bayer consensus algorithm, respectively, each consensus node needs to perform a validation item when performing validity validation on the proposed block, and there may also be a certain difference.

In an embodiment shown, if the consensus algorithm adopted by the blockchain system is leader-based bexatility consensus algorithm, the data format of the proposed block can be as shown in fig. 7. Since the byzantine consensus algorithm generally considers the presence of a byzantine node (i.e., a malicious node) in the consensus nodes, and in a blockchain system adopting the byzantine consensus algorithm, it is generally necessary to sign transmitted data and verify whether the data is tampered by the byzantine node based on a signature verification mechanism, in this case, the verification items that each of the consensus nodes needs to perform when performing validity verification for a sub-block may include the above-mentioned verification item 7-verification item 9.

In an embodiment shown, if the consensus algorithm adopted by the blockchain system is leader-based, the value of the hash value of each sub-block can be filled in the Batch List field in the data format shown in fig. 7, in addition to the sub-block id of each sub-block in the sub-block set included in the proposed block.

In this case, in the process of performing the verification item 8, if it is determined that each sub-block corresponding to the sub-block identifier filled in the Batch List field of the proposed block is stored in the local transaction pool, the hash of each sub-block stored in the local transaction pool may be further calculated, the hash value filled in the Batch List field of the proposed block and corresponding to each sub-block may be obtained, and then the calculated hash of each sub-block stored in the local transaction pool is verified whether the hash value filled in the Batch List field of the proposed block and corresponding to each sub-block is the same as the hash value filled in the Batch List field of the obtained proposed block and corresponding to each sub-block; if yes, further verification is carried out.

In an implementation manner shown, if the hash value of any target sub-block in the above sub-blocks stored in the local transaction pool is different from the obtained hash value of the target sub-block filled in the Batch List field of the proposed block, a creator of the target sub-block may be further determined, and the creator may be added to the blacklist as a malicious node.

In addition, in one implementation, the hash value of the target sub-block stored in the local transaction pool and the hash value of the target sub-block filled in the Batch List field of the proposed block may be broadcast together to other respective common nodes, so that the other respective common nodes may calculate the hash value of the target sub-block and verify whether the hash value of the target sub-block is the same as the hash value of the target sub-block filled in the Batch List field of the proposed block; if the hash value of the target sub-block is verified to be exactly the same as the hash value of the target sub-block filled in the Batch List field of the proposed block, the creator of the target sub-block can be further determined and added to the blacklist as a malicious node.

Or, in another implementation manner, the information of the determined creator may also be directly broadcast and sent to other respective consensus nodes, so that the other respective consensus nodes add the creator to the blacklist as a malicious node.

It is emphasized, among other things, that sub-blocks created by malicious nodes maintained in the black list will not be added to proposed blocks subsequently created by the master node. For example, in one example, the master node, in the stage of creating the proposed block, may exclude, based on the blacklist, sub-blocks created by malicious nodes maintained in the blacklist from the proposed block.

In one embodiment, if the consensus algorithm adopted by the blockchain system is leader-based non-byzantine consensus algorithm, the data format of the proposed block can be as shown in fig. 6. Since the non-byzantine consensus algorithm does not usually need to consider the case where there is a byzantine node in the consensus nodes, in this case, the authentication items that each of the consensus nodes needs to perform when performing validity authentication for a sub-block may include the above-mentioned authentication item 8 and authentication item 9. That is, the above-mentioned authentication item 7 need not be executed.

In this specification, after the consensus node other than the master node verifies the validity of the received proposed block distributed by the master node, the transaction List included in each sub-block corresponding to each sub-block identifier filled in the Batch List field in the proposed block may be acquired from each local sub-chain maintained in its local transaction pool, and then the consensus voting stage of the consensus algorithm adopted by the block chain system is performed to perform the consensus voting process on the acquired transaction List.

It should be emphasized that the above-described pre-transmission mechanism is organically combined with the proposed block distribution mechanism supported by the consensus algorithm adopted by the block chain system, so that the consensus process of the existing consensus algorithm is not affected. The subsequent consensus voting processing on the obtained transaction list can still follow the existing flow of the consensus algorithm adopted by the blockchain system, and is not detailed in the description.

Referring to fig. 10, fig. 10 is a flow diagram illustrating a method of consensus in a blockchain system that includes a plurality of consensus nodes according to an exemplary embodiment of the present specification; the plurality of consensus nodes comprise a main node selected based on a leader-based consensus algorithm adopted by the block chain system, and the method can be applied to any consensus node except the main node; the method comprises the following steps:

step 1002, sending the local sub-chain broadcast maintained in the local transaction pool to other respective consensus nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

step 1004, obtaining the proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

step 1006, obtaining a transaction list included in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool, and performing consensus processing on the obtained transaction list.

In this embodiment, the description will be made in the perspective of any consensus node other than the master node, and details of implementation of the above steps may refer to the embodiment provided in fig. 1, and will not be described in detail in this specification.

Embodiments of a blockchain system, consensus node, and storage medium are also provided, corresponding to embodiments of the foregoing methods.

The present specification also provides an embodiment of a blockchain system, where the blockchain may include a plurality of common nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in the local transaction pool of each of the plurality of consensus nodes; the local sub-chain comprises a plurality of sub-blocks created by the respective consensus nodes based on transactions stored in a local transaction pool; wherein:

the main node is used for broadcasting the local sub-chain maintained in the local transaction pool to other various consensus nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool; acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identifiers corresponding to respective subblocks in the set of subblocks; distributing the proposed blocks to other common nodes respectively;

the other common nodes except the main node broadcast the local sub-chain maintained in the local transaction pool to other common nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool; and acquiring the proposed block transmitted by the main node, acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool, and performing consensus processing on the acquired transaction list.

FIG. 11 is a schematic block diagram of an electronic device provided by an example embodiment. Referring to fig. 1, at the hardware level, the apparatus includes a processor 1102, an internal bus 1104, a network interface 1106, a memory 1108, and a non-volatile storage 1110, although other hardware required for services may be included. One or more embodiments of the present description can be implemented in software, for example, by the processor 1102 reading the corresponding computer program from the non-volatile storage 1110 into the memory 1108 and then running it. Of course, besides software implementation, the one or more embodiments of the present disclosure do not exclude other implementations, such as logic devices or combination of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic module, and may also be hardware or logic devices.

Fig. 12 is a block diagram of a common node in a blockchain system according to an exemplary embodiment, and the apparatus may be applied to the electronic device shown in fig. 11 to implement the technical solution of the present specification. The blockchain system comprises a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in a local transaction pool of each of the plurality of common nodes; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the consensus node 120 comprises:

a first sending module 1201, configured to send a local child chain broadcast maintained in a local transaction pool to other respective common node; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool;

the creating module 1202 is configured to obtain a sub-block set from each local sub-chain maintained in a local transaction pool, and create an proposed block based on the obtained sub-block set; wherein the proposed block comprises subblock identifiers corresponding to respective subblocks in the set of subblocks;

the transmission module 1203 distributes the proposed blocks to other common nodes, so that each common node obtains the transaction lists contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs common identification processing on the obtained transaction lists.

The details of the modules of the apparatus 120 are described in detail in the method flow described above, and therefore are not described herein again.

Fig. 13 is a block diagram of a common node in a blockchain system according to another exemplary embodiment, and the apparatus may also be applied to the electronic device shown in fig. 11 to implement the technical solution of the present specification. The blockchain system comprises a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in a local transaction pool of each of the plurality of common nodes; the local sub-chain comprises a plurality of sub-blocks created by the respective consensus nodes based on transactions stored in a local transaction pool; the consensus node 130 comprises:

the second sending module 1301, sends the local child chain broadcast maintained in the local transaction pool to other respective consensus nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool;

an obtaining module 1302, obtaining the proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

the consensus module 1303 acquires, from each local sub-chain maintained in the local transaction pool, a transaction list included in each sub-block corresponding to the sub-block identifier, and performs consensus processing on the acquired transaction list.

The details of the modules of the apparatus 130 are described in detail in the method flow described above, and therefore are not described herein again.

Correspondingly, the present specification also provides an electronic device, which includes a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of all of the method flows described previously.

Accordingly, the present specification also provides a computer readable storage medium having executable instructions stored thereon; wherein the instructions, when executed by a processor, implement steps of all of the method flows previously described.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement without inventive effort.

The systems, devices, modules or modules illustrated in the above embodiments may be implemented by a computer chip or an entity, or by an article of manufacture with certain functionality. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the 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 Disks (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media 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 phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at" \8230; "or" when 8230; \8230; "or" in response to a determination ", depending on the context.

The above description is intended only to be exemplary of the one or more embodiments of the present disclosure, and should not be taken as limiting the one or more embodiments of the present disclosure, as any modifications, equivalents, improvements, etc. that come within the spirit and scope of the one or more embodiments of the present disclosure are intended to be included within the scope of the one or more embodiments of the present disclosure.

Claims (38)

1. A consensus method in a blockchain system, the method being applied to a master node selected from a plurality of consensus nodes participating in consensus in the blockchain system; wherein, in the local transaction pool of each of the plurality of consensus nodes, a local sub-chain is maintained respectively; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the method comprises the following steps:

sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool;

acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks;

and respectively distributing the proposed block to other common identification nodes, so that each common identification node respectively acquires a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node, and performs common identification processing on the acquired transaction list.

2. The method of claim 1, before the broadcasting the local child chain maintained in the local transaction pool to other respective consensus nodes, further comprising:

periodically acquiring a transaction list from a local transaction pool, and creating a sub-block based on the acquired transaction list;

the created sub-blocks are linked with the latest sub-block on the local sub-chain maintained in the local transaction pool.

3. The method of claim 2, wherein the proposed block has a block period corresponding to a period duration that is an integer multiple of a period duration corresponding to a block period of the sub-block.

4. The method as set forth in claim 2, wherein,

sending the local sub-chain broadcast maintained in the local transaction pool to other respective consensus nodes, including:

periodically broadcasting the newly-added sub-blocks on the local sub-chain to other respective consensus nodes;

receiving the local sub-chain maintained in the local transaction pool broadcast and sent by other respective consensus nodes, comprising:

and receiving newly added sub-blocks on the local sub-chain periodically broadcast and sent by other common nodes.

5. The method of claim 1, prior to maintaining the received local child chain in the local transaction pool, the method further comprising:

and carrying out validity verification on the received sub-blocks contained in the local sub-chain, and maintaining the received local sub-chain in a local transaction pool after the validity verification is passed.

6. The method of claim 5, wherein the data structure corresponding to the sub-block comprises:

a sub-block header, a transaction list field;

wherein, the transaction list field is used for filling the transaction list contained in the sub-block;

the sub-block header, comprising:

a Previous Hash field for filling the Hash value of the Previous sub-block linked in the local sub-chain to which the sub-block belongs;

a height field for filling a subblock identifier indicating a subblock height in a local subblock to which the subblock belongs;

a Merkle Root field for populating a hash value of a Root node of a Merkle tree created based on the transaction list contained in the sub-block;

indication list field: for populating a height list of block heights of the latest sub-block on the local sub-chain corresponding to the other respective common node stored in the local transaction pool at the time of creating the current sub-block.

7. The method of claim 6, if the consensus algorithm employed by the blockchain system is leader-based's Byzantine consensus algorithm:

the data format corresponding to the sub-block further includes:

a signature field for populating a signature of a subblock by a creator of the subblock;

performing validity verification on the sub-block, including:

verifying the signature filled in the signature field of the subblock; if the verification for the signature passes, further performing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether a Previous sub-block linked with the sub-block and indicated by a Hash value filled in a Previous Hash field of the sub-block is stored in a local transaction pool; if yes, further executing the next verification; otherwise, further acquiring the previous sub-block from the common node for creating the previous sub-block;

verifying whether other sub-blocks linked to the same previous sub-block as the sub-block are stored in a local transaction pool; if yes, determining that the validity verification aiming at the sub-block fails; otherwise, further executing the next verification;

verifying whether the block height corresponding to other common nodes contained in the height list filled in the indication list field of the sub-block is increased compared with the block height corresponding to other common nodes contained in the height list filled in the indication list field of the last sub-block linked with the sub-block; if yes, further executing next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying the signature of each transaction in the transaction list contained in the sub-block; if the signature for each transaction passes the verification, further executing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub-block is the same as the hash value filled in the Merkle Root field of the sub-block; if yes, determining that the validity verification aiming at the sub-blocks passes; otherwise, determining that the validity verification for the sub-block fails.

8. The method of claim 7, further comprising:

if other sub-blocks which link the same last sub-block with the sub-block are stored in a local transaction pool, further determining creators of the sub-block and the other sub-blocks, and adding the creators to a blacklist as malicious nodes; and the number of the first and second groups,

broadcasting the sub-block and the other sub-blocks to other respective consensus nodes, so that when the other respective consensus nodes verify that the sub-block and the other sub-blocks link the same last sub-block, further determining creators of the sub-block and the other sub-blocks, and adding the creators to a blacklist as malicious nodes; or broadcasting and sending the creator to other common identification nodes so that the other common identification nodes add the creator as a malicious node to a blacklist;

wherein the proposed blocks do not include sub-blocks created by malicious nodes maintained in the blacklist.

9. The method of claim 6, if the consensus algorithm employed by the blockchain system is a leader-based non-byzantine consensus algorithm:

performing validity verification on the sub-block, including:

verifying whether a Previous sub-block linked with the sub-block and indicated by a Hash value filled in a Previous Hash field of the sub-block is stored in a local transaction pool; if yes, further executing the next verification; otherwise, further acquiring the previous sub-block from the common node for creating the previous sub-block;

verifying whether the block height corresponding to other common nodes contained in the height list filled in the indication list field of the sub-block is increased compared with the block height corresponding to other common nodes contained in the height list filled in the indication list field of the last sub-block linked with the sub-block; if yes, further executing next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub-block is the same as the hash value filled in the Merkle Root field of the sub-block; if yes, determining that the validity verification aiming at the sub-blocks passes; otherwise, determining that the validity verification for the sub-block fails.

10. The method of claim 1, wherein distributing the proposed blocks to other respective consensus nodes comprises:

and broadcasting and sending the proposed blocks to other various consensus nodes based on a proposed block distribution mechanism supported by a consensus protocol adopted by the block chain system.

11. The method of claim 6, obtaining a set of child blocks from each local child chain maintained in a local transaction pool, comprising:

respectively determining the latest sub-block in each local sub-chain maintained in a local transaction pool, and further acquiring the height list filled in the indication list field in the sub-block head of the latest sub-block in each local sub-chain;

determining a common height between the block heights of the latest sub-blocks in each sub-chain maintained in the local transaction pool of the main node and the block heights of the latest sub-blocks in each sub-chain maintained in the local transaction pools of other common nodes based on the obtained height list, and respectively obtaining a sub-block set of which the block height is not more than the common height from each local sub-chain maintained in the local transaction pool of the main node.

12. The method of claim 11, wherein determining a common height between the block height of the latest sub-block in each sub-chain maintained in the local transaction pool of the master node and the block height of the latest sub-block in each sub-chain maintained in the local transaction pools of the other respective consensus nodes based on the obtained height list, and obtaining a set of sub-blocks having block heights no greater than the common height from each local sub-chain maintained in the local transaction pool of the master node, respectively, comprises:

determining N common identification nodes with the largest block height of the latest sub-blocks in each local sub-chain maintained in the local transaction pool of the main node and the local transaction pools of other common identification nodes based on the obtained height list;

determining a common height between block heights of latest sub-blocks on respective local sub-chains maintained in a local transaction pool of the N common nodes;

respectively acquiring a sub-block set with the block height not greater than the common height from each local sub-chain maintained in a local transaction pool of the main node;

and the value of N is the maximum fault-tolerant node number of the consensus algorithm adopted by the block chain system aiming at the consensus nodes participating in consensus.

13. The method of claim 12, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

if the consensus algorithm adopted by the block chain system is leader-based Byzantine consensus algorithm, the total number of consensus nodes participating in consensus of the block chain system is 3f +1, and the value of N is 2f +1.

14. The method of claim 13, the consensus algorithm comprising a PBFT consensus algorithm or a HotStuff consensus algorithm.

15. The method of claim 12, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

if the consensus algorithm adopted by the block chain system is a leader-based non-Byzantine consensus algorithm, the total number of consensus nodes participating in consensus of the block chain system is f, and the value of N is f/2+1.

16. The method of claim 15, the consensus algorithm comprising a RAFT consensus algorithm or a PAXOS consensus algorithm.

17. The method of claim 1, wherein the proposed block does not include a list of transactions;

the data structure corresponding to the proposed block comprises:

a subblock set field for filling subblock identifications of respective subblocks in a subblock set included in the proposed block;

a Merkle Root field for populating a hash value of a Root node of a Merkle tree created based on a transaction list contained by each of the set of sub-blocks.

18. A consensus method in a block chain system is provided, wherein a plurality of consensus nodes participating in consensus in the block chain system comprise elected main nodes; the method is applied to any consensus node in the plurality of consensus nodes except the master node; wherein, in the local transaction pool of each of the plurality of consensus nodes, a local sub-chain is maintained respectively; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the method comprises the following steps:

sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool;

acquiring an proposed block transmitted by the main node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

and acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool, and performing consensus processing on the acquired transaction list.

19. The method of claim 18, prior to sending the local child chain broadcast maintained in the local transaction pool to the other respective consensus nodes, further comprising:

periodically acquiring a transaction list from a local transaction pool, and creating a sub-block based on the acquired transaction list;

the created sub-blocks are linked with the latest sub-block on the sub-chain maintained in the local transaction pool.

20. The method of claim 19, wherein the proposed block has a blocking period that corresponds to a period that is an integer multiple of a period corresponding to the blocking period of the sub-block.

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

sending the local sub-chain broadcast maintained in the local transaction pool to other respective common nodes, including:

periodically broadcasting the newly-added sub-blocks on the local sub-chain to other respective consensus nodes;

receiving the local sub-chain maintained in the local transaction pool broadcast and sent by other respective consensus nodes, comprising:

and receiving newly added sub-blocks on the local sub-chain periodically broadcast and sent by other common nodes.

22. The method of claim 18, prior to maintaining the received local child chain in the local transaction pool, the method further comprising:

and carrying out validity verification on the sub blocks contained in the received local sub chain, and maintaining the received local sub chain in a local transaction pool after the validity verification is passed.

23. The method of claim 22, wherein the data structure corresponding to the sub-block comprises:

a sub-block header, a transaction list field;

wherein, the transaction list field is used for filling the transaction list contained in the sub-block;

the sub-block header, comprising:

a Previous Hash field for filling the Hash value of the Previous sub-block linked in the local sub-chain to which the sub-block belongs;

a height field for filling a subblock identifier indicating a subblock height in a local subblock to which the subblock belongs;

a Merkle Root field for populating a hash value of a Root node of a Merkle tree created based on the transaction list contained in the sub-block;

indication list field: for populating a height list of block heights of the latest sub-block on the local sub-chain corresponding to the other respective common node stored in the local transaction pool at the time of creating the current sub-block.

24. The method of claim 23, if the consensus algorithm employed by the blockchain system is leader-based, byzantine consensus algorithm:

the data format corresponding to the sub-block further includes:

a signature field for populating a signature of a subblock by a creator of the subblock;

performing validity verification on the sub-block, including:

verifying the signature filled in the signature field of the subblock; if the verification on the signature passes, further performing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether a Previous sub-block linked by the sub-block and indicated by a Hash value filled in a Previous Hash field of the sub-block is stored in a local transaction pool; if yes, further executing next verification; otherwise, further acquiring the previous sub-block from the common node for creating the previous sub-block;

verifying whether other sub-blocks linked to the same previous sub-block as the sub-block are stored in a local transaction pool; if so, determining that the validity verification for the sub-block fails; otherwise, further executing the next verification;

verifying whether the block height corresponding to other common nodes contained in the height list filled in the indication list field of the sub-block is increased compared with the block height corresponding to other common nodes contained in the height list filled in the indication list field of the last sub-block linked with the sub-block; if yes, further executing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying the signature of each transaction in the transaction list contained in the sub-block; if the signature verification for each transaction is passed, further performing the next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub-block is the same as the hash value filled in the Merkle Root field of the sub-block; if yes, determining that the validity verification aiming at the sub-blocks passes; otherwise, determining that the validity verification for the sub-block fails.

25. The method of claim 24, the method further comprising:

if other sub-blocks which link the same last sub-block with the sub-block are stored in a local transaction pool, further determining creators of the sub-block and the other sub-blocks, and adding the creators to a blacklist as malicious nodes; and the number of the first and second groups,

broadcasting the sub-block and the other sub-blocks to other respective consensus nodes, so that when the other respective consensus nodes verify that the sub-block and the other sub-blocks link the same last sub-block, further determining creators of the sub-block and the other sub-blocks, and adding the creators to a blacklist as malicious nodes; or broadcasting and sending the creator to other common identification nodes so that the other common identification nodes add the creator as a malicious node to a blacklist;

wherein the proposed blocks do not include sub-blocks created by malicious nodes maintained in the blacklist.

26. The method of claim 23, if the consensus algorithm employed by the blockchain system is a leader-based non-byzantine consensus algorithm:

performing validity verification on the sub-block, including:

verifying whether a Previous sub-block linked by the sub-block and indicated by a Hash value filled in a Previous Hash field of the sub-block is stored in a local transaction pool; if yes, further executing next verification; otherwise, further acquiring the previous sub-block from the common node for creating the previous sub-block;

verifying whether the block height corresponding to other common identification nodes contained in the height list filled in the indication list field of the sub-block is increased compared with the block height corresponding to other common identification nodes contained in the height list filled in the indication list field of the last sub-block linked with the sub-block or not; if yes, further executing next verification; otherwise, determining that the validity verification aiming at the sub-blocks fails;

verifying whether the hash value of the Root node of the Merkle tree created based on the transaction list contained in the sub-block is the same as the hash value filled in the Merkle Root field of the sub-block; if yes, determining that the validity verification aiming at the sub-blocks passes; otherwise, determining that the validity verification for the sub-block fails.

27. The method according to claim 18, wherein before obtaining the transaction list included in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool and performing consensus processing on the obtained transaction list, the method further comprises:

and carrying out validity verification on the obtained proposed block, further obtaining a transaction list contained in each sub-block corresponding to the sub-block identification from each local sub-chain maintained in a local transaction pool after the validity verification is passed, and carrying out consensus processing on the obtained transaction list.

28. The method of claim 27, wherein the proposed block does not include a list of transactions;

the data structure corresponding to the proposed block comprises:

a subblock set field for filling subblock identifiers corresponding to respective subblocks in a subblock set included in the proposed block;

a Merkle Root field used for filling a hash value of a Root node of a Merkle tree created based on the transaction list contained in each subblock in the set of subblocks.

29. The method of claim 28, if the consensus algorithm employed by the blockchain system is a leader-based byzantine consensus algorithm:

the data structure corresponding to the proposed block further comprises:

a signature field to populate a master node's signature for the proposed block;

and performing validity verification on the acquired proposed block, wherein the validity verification comprises the following steps:

verifying for the signature filled in the signature field of the proposed block; if the verification for the signature passes, further performing the next verification; otherwise, determining that the validity verification for the proposed block fails;

verifying whether each subblock corresponding to the subblock identifier filled in the subblock set field of the proposed block is stored in a local transaction pool or not; if the sub-blocks are stored in the local transaction pool, further executing the next verification; otherwise, further acquiring the sub-blocks in the sub-blocks which are not stored in the local transaction pool from the master node or other common knowledge;

verifying whether the hash value of the Root node of the Merkle tree created based on the acquired transaction list contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determining that the validity verification for the proposed block passes; otherwise, it is determined that the validity verification for the proposed block fails.

30. The method of claim 29, if the consensus algorithm employed by the blockchain system is leader-based, byzantine consensus algorithm:

the subblock set field is used for filling the subblock identifier of each subblock in the subblock set included in the proposed block and the hash value of each subblock;

if the local transaction pool stores the sub-blocks, further performing a next verification, including:

if the sub-blocks are stored in the local trading pool, further calculating the hash of the sub-blocks stored in the local trading pool;

acquiring hash values which are filled in a subblock set field of the proposed block and correspond to the subblocks, and verifying whether the hash values of the subblocks stored in a local transaction pool are the same as the acquired hash values; if yes, further verification is carried out.

31. The method of claim 30, further comprising:

if the hash value of any target sub-block in the sub-blocks stored in the local transaction pool is different from the obtained hash value of the target sub-block, determining a creator of the target sub-block, and adding the creator to a blacklist as a malicious node; and (c) a second step of,

broadcasting the hash value of the target sub-block stored in the local transaction pool and the hash value of the target sub-block filled in the sub-block set field of the proposed block to other common nodes, so that the other common nodes further determine a creator of the target sub-block when verifying that the hash value of the target sub-block stored in the local transaction pool is the same as the hash value of the target sub-block filled in the sub-block set field of the proposed block, and add the creator as a malicious node to a blacklist; or the creator is broadcasted to other common nodes, so that the other common nodes add the creator as a malicious node to a blacklist;

wherein the proposed blocks do not include sub-blocks created by malicious nodes maintained in the blacklist.

32. The method of claim 28, if the consensus algorithm employed by the blockchain system is a leader-based non-byzantine consensus algorithm:

and performing validity verification on the acquired proposed block, wherein the validity verification comprises the following steps:

verifying whether each subblock corresponding to the subblock header filled in the subblock set field of the proposed block is stored in a local transaction pool; if the sub-blocks are stored in the local transaction pool, further executing the next verification; otherwise, further acquiring the sub-blocks in the sub-blocks which are not stored in the local transaction pool from the master node or other common knowledge;

verifying whether the hash value of the Root node of the Merkle tree created based on the acquired transaction list contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determining that the validity verification for the proposed block passes; otherwise, it is determined that the validity verification for the proposed block fails.

33. The method of claim 30 or 32, wherein the leader-based non-bexatine consensus algorithm comprises a PBFT consensus algorithm or a HotStuff consensus algorithm; the leader-based non-Byzantine consensus algorithm comprises a RAFT consensus algorithm or a PAXOS consensus algorithm.

34. A block chain system comprises a plurality of common nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in the local transaction pool of each of the plurality of consensus nodes; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; wherein:

the main node is used for broadcasting the local sub-chain maintained in the local transaction pool to other various consensus nodes; receiving the local sub-chain maintained in the local transaction pool broadcast and sent by each other common node, and maintaining the received local sub-chain in the local transaction pool; acquiring a sub-block set from each local sub-chain maintained in a local transaction pool, and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks; distributing the proposed blocks to other common nodes respectively;

other common nodes except the main node broadcast the local sub-chain maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool; and acquiring the proposed block transmitted by the main node, acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool, and performing consensus processing on the acquired transaction list.

35. A consensus node in a blockchain system, the blockchain system comprising a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in the local transaction pool of each of the plurality of consensus nodes; the local sub-chain comprises a plurality of sub-blocks created by the common nodes based on the transactions stored in the local transaction pool; the method comprises the following steps:

the first sending module is used for sending the local sub-chain broadcast maintained in the local transaction pool to other common nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

the system comprises a creating module, a transaction module and a processing module, wherein the creating module is used for acquiring a sub-block set from each local sub-chain maintained in a local transaction pool and creating an proposed block based on the acquired sub-block set; wherein the proposed block comprises subblock identities corresponding to respective subblocks of the set of subblocks;

and the transmission module is used for respectively distributing the proposed blocks to other common identification nodes, so that each common identification node respectively acquires the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in a local transaction pool of the common identification node, and performs common identification processing on the acquired transaction list.

36. A consensus node in a blockchain system, the blockchain system comprising a plurality of consensus nodes; the plurality of consensus nodes comprise elected master nodes; local sub-chains are respectively maintained in the local transaction pool of each of the plurality of consensus nodes; the local sub-chain comprises a plurality of sub-blocks created by the respective consensus nodes based on transactions stored in a local transaction pool; the method comprises the following steps:

the second sending module is used for sending the local sub-chain broadcast maintained in the local transaction pool to other common identification nodes; receiving local sub-chains maintained in the local transaction pool broadcast and sent by other common nodes, and maintaining the received local sub-chains in the local transaction pool;

the acquisition module acquires the proposed block transmitted by the main node; wherein the proposed block is a proposed block created by the master node based on a set of sub-blocks obtained from each sub-chain maintained in its local transaction pool; the proposed block includes subblock identifiers corresponding to respective subblocks in the set of subblocks;

and the consensus module is used for acquiring a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool, and performing consensus processing on the acquired transaction list.

37. An electronic device comprises a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are connected with each other through the bus;

the memory has stored therein machine-readable instructions, which the processor executes by calling to perform the method of any one of claims 1 to 33.

38. A machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, carry out the method of any of claims 1 to 33.

Images