A consensus method in a blockchain system, a blockchain system, and a consensus node

Abstract

The embodiments of this specification provide a consensus method, a blockchain system, and a consensus node in a blockchain system, including: broadcasting a local sub-chain maintained in a local transaction pool to other consensus nodes; and receiving local sub-chains maintained in their local transaction pools broadcast by other consensus nodes, and maintaining the received local sub-chains in the local transaction pool; obtaining a sub-block set from each local sub-chain maintained in the local transaction pool, and creating a proposal block based on the obtained sub-block set; wherein the proposal block includes a sub-block identifier corresponding to each sub-block in the sub-block set; distributing the proposal block to other consensus nodes respectively, so that each consensus node obtains a transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a consensus method, a blockchain system, and a consensus node in a blockchain system. Background Art

[0002] Blockchain is a decentralized, distributed ledger that doesn't require a trusted third party. Blockchain technology boasts multi-party access, transparency, and immutability. Blockchains can be categorized as public, consortium, and private chains based on their access mechanisms. Consortium chains feature access control, allowing only authorized nodes to join the network. Therefore, they are often more secure and efficient than public chains and are primarily used for collaboration between businesses or institutions.

[0003] The alliance chain composed of authoritative nodes created based on blockchain technology is conducive to breaking data silos, forming trusted record evidence among alliance members, ensuring the non-tamperability of chain data, and realizing cross-regional and cross-departmental cooperation.

[0004] One metric used to measure blockchain performance is TPS (Transactions Per Second). The higher the TPS, the faster transactions are executed, verified, and confirmed on the blockchain. Early public blockchains generally had low TPS, far from meeting demand. While consortium blockchains generally offer significantly higher TPS than public chains, they are still significantly lower than centralized trading systems, especially those with a higher degree of decentralization. This suggests that blockchain performance is a bottleneck hindering the large-scale adoption of blockchain technology.

[0005] TPS is determined by two factors: the number of transactions contained in each block and the rate at which the system publishes blocks. The more transactions per block, the faster the block generation rate, and the higher the TPS. However, these two parameters cannot be increased arbitrarily. As block sizes increase, the time it takes to propagate across the entire network also increases. If the block generation interval is too short to allow the majority of nodes in the system to receive newly released blocks, the security of the blockchain will be compromised. For public chains, such as those based on the PoW consensus protocol, this situation can lead to forks, potentially causing some transactions to be rolled back. Consortium chains, because they can control the identity and number of participating nodes, can use traditional distributed consensus protocols to generate blocks. Typically, consortium chains have significantly fewer consensus nodes than public chains and have better node bandwidth, resulting in significantly higher TPS. However, as the size of blocks in a consortium chain increases, the transmission delay will also increase. For a consortium chain network with large-scale nodes (such as hundreds or even thousands of nodes), the increase in blocks will lead to longer transaction execution times, and the time to verify signatures in the consensus protocol will also increase. At the same time, the sharp increase in messages sent between nodes will also cause network congestion, further increasing block transmission time, reducing the efficiency of reaching consensus, and affecting the time it takes to produce the next block.

[0006] It can be seen that, whether it is a public chain or a consortium chain, the efficiency of reaching consensus on blocks has a significant impact on the TPS of the blockchain system. Therefore, how to improve the efficiency of reaching consensus on blocks is of great significance to improving the performance of the blockchain system. Summary of the Invention

[0007] This specification proposes a consensus method in a blockchain system, which is applied to a master node elected from multiple consensus nodes participating in the consensus in the blockchain system; wherein each of the multiple consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes a number of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and includes:

[0008] Broadcasting the local subchain maintained in the local transaction pool to other consensus nodes; and receiving the local subchains maintained in their local transaction pools broadcast by other consensus nodes, and maintaining the received local subchains in the local transaction pool;

[0009] Obtain a subblock set from each local subchain maintained in the local transaction pool, and create a proposed block based on the obtained subblock set; wherein the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0010] The proposed block is distributed to other consensus nodes respectively, so that each consensus node obtains the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

[0011] This specification also proposes a consensus method in a blockchain system, wherein multiple consensus nodes participating in the consensus in the blockchain system include an elected master node; the method is applied to any consensus node among the multiple consensus nodes except the master node; wherein each of the multiple consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes several sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and comprises:

[0012] Broadcasting the local subchain maintained in the local transaction pool to other consensus nodes; and receiving the local subchains maintained in their local transaction pools broadcast by other consensus nodes, and maintaining the received local subchains in the local transaction pool;

[0013] Obtaining a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each subchain maintained in its local transaction pool; the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0014] From each local sub-chain maintained in the local transaction pool, obtain the transaction list contained in each sub-block corresponding to the sub-block identifier, and perform consensus processing on the obtained transaction list.

[0015] This specification also proposes a blockchain system, comprising a plurality of consensus nodes; the plurality of consensus nodes include an elected master node; each of the plurality of consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes a plurality of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; wherein:

[0016] The master node broadcasts the local subchain maintained in the local transaction pool to the other consensus nodes; receives the local subchains maintained in the local transaction pools broadcast by the other consensus nodes, and maintains the received local subchains in the local transaction pool; obtains a subblock set from each local subchain maintained in the local transaction pool, and creates a proposal block based on the obtained subblock set; wherein the proposal block includes a subblock identifier corresponding to each subblock in the subblock set; and distributes the proposal block to the other consensus nodes respectively;

[0017] Consensus nodes other than the master node broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes; and receive the local sub-chains maintained in their local transaction pools broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool; obtain the proposed block transmitted by the master node, obtain the 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 perform consensus processing on the obtained transaction list.

[0018] This specification also proposes a consensus node in a blockchain system, the blockchain system comprising multiple consensus nodes; the multiple consensus nodes comprising an elected master node; each of the multiple consensus nodes maintaining a local sub-chain in its local transaction pool; the local sub-chain comprising a plurality of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and comprising:

[0019] The first sending module broadcasts the local subchain maintained in the local transaction pool to other consensus nodes; and receives the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintains the received local subchain in the local transaction pool;

[0020] A creation module is configured to obtain a subblock set from each local subchain maintained in the local transaction pool, and to create a proposed block based on the obtained subblock set; wherein the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0021] The transmission module distributes the proposed block to other consensus nodes respectively, so that each consensus node obtains the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

[0022] This specification also proposes a consensus node in a blockchain system, the blockchain system comprising multiple consensus nodes; the multiple consensus nodes comprising an elected master node; each of the multiple consensus nodes maintaining a local sub-chain in its local transaction pool; the local sub-chain comprising a plurality of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and comprising:

[0023] The second sending module broadcasts the local subchain maintained in the local transaction pool to other consensus nodes; and receives the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintains the received local subchain in the local transaction pool;

[0024] an acquisition module, configured to acquire a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each subchain maintained in its local transaction pool; and the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0025] The consensus module obtains the transaction lists contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool, and performs consensus processing on the obtained transaction lists.

[0026] In the above embodiment, on the one hand, since each consensus node in the blockchain system can create transactions stored in the local transaction pool in the form of a local sub-chain composed of several sub-blocks for maintenance in the local transaction pool, and distribute the transaction list contained in the proposed block to each consensus node in advance before the master node creates the proposed block: Therefore, in this way, a pre-transmission mechanism can be introduced in the blockchain system to decouple the distribution process of the proposed block and the consensus process for the proposed block, so that before the master node creates the proposed block, the idle bandwidth of each consensus node other than the master node can be fully utilized, and the transaction list contained in the proposed block can be distributed to each consensus node in advance, so that each consensus node can participate in the distribution process of the consensus data, thereby greatly improving the throughput of the consensus protocol.

[0027] On the other hand, since when the master node creates a proposal block, the proposal block no longer contains a transaction list, but only contains the sub-block identifier of the sub-block where the transaction list is located; therefore, the data capacity of the proposal block will no longer be related to the transaction volume contained in the proposal block, making the bandwidth consumption of transmitting the proposal block independent of the transaction volume in the block, thereby significantly reducing the data capacity and bandwidth load of the master node when distributing the proposal block to other consensus nodes, and improving the consensus efficiency when reaching consensus on the proposal block.

[0028] Thirdly, since the sub-blocks contained in the proposed block generated by the master node are autonomously generated by consensus nodes other than the master node based on the transactions stored in the local transaction pool, the transaction order of the transactions contained in each sub-block can be determined independently by each consensus node; therefore, in this way, each consensus node can participate in the transaction sorting, which can weaken the master node's monopoly on transaction sorting and make the entire consensus algorithm fairer. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0030] Figure 1 This is a flowchart of a consensus method in a blockchain system according to an exemplary embodiment of this specification;

[0031] Figure 2 This is a schematic diagram of a chain transaction pool structure of a consensus node according to an exemplary embodiment of this specification;

[0032] Figure 3 is a schematic diagram of a data format of a sub-block according to an exemplary embodiment of this specification;

[0033] Figure 4 is a schematic diagram of another data format of a seed block according to an exemplary embodiment of this specification;

[0034] Figure 5 This is a schematic diagram of node 1 initiating a fork attack according to an exemplary embodiment of this specification;

[0035] Figure 6 is a schematic diagram of a data format corresponding to a proposed block according to an exemplary embodiment of this specification;

[0036] Figure 7 is a schematic diagram of another proposed data format corresponding to a block according to an exemplary embodiment of this specification;

[0037] Figure 8 is a schematic diagram of a conventional stage of a PBFT algorithm according to an exemplary embodiment of this specification;

[0038] Figure 9 is a schematic diagram of a conventional stage of another PBFT algorithm according to an exemplary embodiment of this specification;

[0039] Figure 10 This is a flowchart of another consensus method in a blockchain system according to an exemplary embodiment of this specification;

[0040] Figure 11 is a schematic structural diagram of an electronic device according to an exemplary embodiment of this specification;

[0041] Figure 12 This is a block diagram of a consensus node in a blockchain system according to an exemplary embodiment of the present specification;

[0042] Figure 13 This is a block diagram of a consensus node in another blockchain system according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0043] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0044] Many blockchains, especially consortium chains, generally adopt a leader-based consensus protocol with a master node. Typical leader-based consensus protocols include PBFT (Practical Byzantine Fault Tolerance), PAXOS, RAFT (Replicated and Fault Tolerant), and HotStuff. With a leader-based consensus protocol, a master node is elected from the consensus nodes participating in the blockchain system. The master node then creates proposed blocks. The consensus protocol then coordinates the consensus nodes to ensure they reach consensus on the proposed blocks created by the master node.

[0045] For leader-based consensus protocols, the data capacity of the proposed block created by the master node during a consensus process determines the throughput of this consensus. As the number of consensus nodes increases, the number of messages sent by the consensus nodes to reach consensus during the entire consensus process will be proportional to the number of nodes.

[0046] In order to improve the efficiency of consensus, related technologies tend to reduce the message complexity of the consensus process. For example, taking the Hotstuff consensus protocol as an example, the Hotstuff consensus protocol is based on the Pbft protocol and reduces the complexity of the consensus protocol from O(n 2 ) is reduced to O(n), which greatly improves the scalability of the consensus algorithm.

[0047] However, in actual applications, consensus performance is affected not only by the message complexity in the consensus, but also by the bandwidth load when the master node distributes the proposed blocks it creates to other consensus nodes.

[0048] Specifically, in a consortium chain, a consensus needs to reach consensus on a large number of transactions. A typical transaction size is 250B. When a block includes 400 transactions, the size of a block is 100KB.

[0049] Based on the general consensus process of the leader-based consensus protocol, after the master node distributes the proposed block it creates to all other consensus nodes, in the subsequent consensus phase for that proposed block, the other consensus nodes generally only need to send signature data for that proposed block. Since a signature typically does not exceed 100 bytes, the bandwidth consumed by the master node distributing the proposed block to all other consensus nodes is hundreds of times greater than that consumed in the subsequent consensus phase.

[0050] As can be seen, the masternode's distribution of proposed blocks has a greater impact on the overall consensus performance. If the proposed blocks distributed by the masternode contain more transactions, the throughput of the consensus process will be higher. However, in practice, a masternode's bandwidth is limited. The larger the amount of data contained in the proposed blocks required for a consensus process, the longer it takes for the masternode to pass the proposed blocks to other nodes, which in turn increases the subsequent consensus time.

[0051] Based on the above analysis, we can see that for leader-based consensus protocols, the throughput of a consensus process is generally determined by the bandwidth of the master node. Alternatively, it can be understood that during a consensus process, only the master node's bandwidth is used when distributing proposed blocks. The bandwidth of other consensus nodes is usually idle and underutilized at other times.

[0052] Based on this, this application addresses the problem that the existing leader-based consensus protocol fails to fully utilize the bandwidth of the consensus nodes. It introduces a pre-transmission mechanism into the blockchain system and designs a data distribution strategy based on parallel chains. When distributing proposed blocks, it can fully utilize the idle bandwidth of each consensus node other than the master node during the consensus process, and reduce the bandwidth consumption when distributing proposed blocks from a linear level to a constant level, thereby significantly improving the throughput of the entire consensus algorithm, reducing the block transmission delay, and improving the consensus efficiency when reaching consensus on the proposed blocks. In implementation, on the one hand, based on the existing blockchain of the blockchain system, a local sub-chain maintained in the local transaction pool of each consensus node can be designed. Each consensus node participating in the consensus in the blockchain system will create a local sub-chain consisting of several sub-blocks from the transactions stored in its local transaction pool, and then maintain the local sub-chain in its respective local transaction pool.

[0053] On the other hand, a pre-transmission mechanism can also be introduced into the blockchain system, allowing each consensus node to use its own idle bandwidth to broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes in advance before the master node creates a proposed block, and receive the local sub-chains maintained in their local transaction pools broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool.

[0054] When the master node creates a proposal block, its local transaction pool already contains the local subchains maintained by the local transaction pools of each consensus node. The master node can then retrieve a set of subblocks from each local subchain maintained in the local transaction pool and create a proposal block based on the retrieved set of subblocks. The proposal block may no longer contain the list of transactions to be agreed upon, but only contain the subblock identifiers corresponding to each subblock in the subblock set.

[0055] After creating a proposal block, the master node can distribute the proposal block to other consensus nodes. After receiving the proposal block distributed by the master node, other consensus nodes can obtain the transaction lists contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in their local transaction pool, and then perform consensus processing on the obtained transaction lists.

[0056] In the above technical solution, on the one hand, by introducing the above-mentioned 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, the idle bandwidth of each consensus node other than the master node can be fully utilized to distribute the transaction list contained in the proposed block to each consensus node in advance, so that each consensus node can participate in the distribution process of consensus data, which greatly improves the throughput of the consensus protocol.

[0057] On the other hand, since when the master node creates a proposal block, the proposal block no longer contains a transaction list, but only contains the sub-block identifier of the sub-block where the transaction list is located; therefore, the data capacity of the proposal block will no longer be related to the transaction volume contained in the proposal block, making the bandwidth consumption of transmitting the proposal block independent of the transaction volume in the block, thereby significantly reducing the data capacity and bandwidth load of the master node when distributing the proposal block to other consensus nodes, and improving the consensus efficiency when reaching consensus on the proposal block.

[0058] Thirdly, since the sub-blocks contained in the proposed block generated by the master node are autonomously generated by consensus nodes other than the master node based on the transactions stored in the local transaction pool, the transaction order of the transactions contained in each sub-block can be determined independently by each consensus node; therefore, in this way, each consensus node can participate in the transaction sorting, which can weaken the master node's monopoly on transaction sorting and make the entire consensus algorithm fairer.

[0059] See Figure 1 , Figure 1 This is a flowchart of a consensus method in a blockchain system according to an exemplary embodiment of the present specification. The blockchain system includes multiple consensus nodes; the multiple consensus nodes include a master node elected based on a leader-based consensus algorithm adopted by the blockchain system, and the method can be applied to the master node; the method includes:

[0060] Step 102: Broadcast the local subchain maintained in the local transaction pool to other consensus nodes; and receive the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintain the received local subchain in the local transaction pool.

[0061] The leader-based consensus algorithm adopted by the above-mentioned blockchain system may specifically include a leader-based Byzantine consensus algorithm or a leader-based non-Byzantine consensus algorithm.

[0062] For example, typical leader-based Byzantine consensus algorithms include the PBFT consensus algorithm and the HotStuff consensus algorithm, etc. Typical leader-based non-Byzantine consensus algorithms include the PAXOS consensus algorithm and the RAFT consensus algorithm, etc.

[0063] In this specification, based on the existing blockchain of the blockchain system, a local sub-chain can be designed, which is maintained in the local transaction pool of each consensus node.

[0064] Specifically, the local sub-chain can include multiple batches (hereinafter referred to as sub-blockchains) created by each consensus node participating in the blockchain system based on transactions stored in its local transaction pool. This design allows transactions stored in the local transaction pool of each consensus node to be packaged into sub-blocks in an orderly manner.

[0065] It should be noted that the local subchain described in this specification refers to a subchain structure independently created by each consensus node based on transactions stored in its local transaction pool. This subchain structure is independently maintained by each consensus node in its local transaction pool. Different consensus nodes do not need to cross-validate or confirm the local subchains maintained by other consensus nodes in their local transaction pools.

[0066] In one embodiment shown, when each consensus node creates a sub-block based on transactions stored in a local transaction pool, it can periodically obtain a transaction list from the local transaction pool based on the block formation period of the sub-block, and create a sub-block based on the obtained transaction list.

[0067] For example, in one example, the block cycle can be 1 millisecond, and each consensus node can periodically retrieve a batch of transactions from the local transaction pool every 1 millisecond and package them into a sub-block, so that the transactions stored in the local transaction pool can be packaged into sub-blocks in an orderly manner.

[0068] It should be noted that the above-mentioned sub-block generation period can be flexibly set based on actual needs in practical applications. For example, in one example, the transaction list contained in the sub-block will eventually be packaged into a proposed block, and the transaction volume that the proposed block can accommodate is generally an integer multiple of the transaction volume that the sub-block can accommodate. For example, a proposed block may be packaged by the master node based on N sub-blocks. In this case, the period corresponding to the generation period of the proposed block can be an integer multiple of the period corresponding to the generation period of the sub-block.

[0069] Furthermore, after each consensus node creates a sub-block based on the acquired transaction list, it can link the sub-block with the latest sub-block on the local sub-chain maintained in the local transaction pool.

[0070] For example, the data format of the created sub-block can be filled with the hash value of the latest sub-block on the local sub-chain maintained in the local transaction pool, and the created sub-block can be linked to the above latest sub-block. After the link is completed, the created sub-block will become the latest sub-block on the local sub-chain.

[0071] In this specification, a pre-transmission mechanism can also be introduced into the blockchain system, allowing each consensus node to use its own idle bandwidth to broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes in advance before the master node creates a proposed block.

[0072] For each consensus node, on the one hand, it can broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes; on the other hand, it can also receive the local sub-chain maintained in the local transaction pool broadcast by other consensus nodes, and maintain the received local sub-chain in the local transaction pool.

[0073] By adopting this pre-transmission mechanism, each consensus node will receive the local sub-chain maintained in the local transaction pool of all consensus nodes. Ultimately, all the local sub-chains received by each consensus node will form a structured chain transaction pool structure consisting of multiple sub-chains.

[0074] For example, see Figure 2 , the above blockchain system includes 4 consensus participants ( Figure 2 Taking the consensus nodes of node1-node4 as an example, the local transaction pool of each consensus node will form a Figure 2 The structured chain transaction pool structure shown is composed of 4 sub-chains. Figure 2 The Bth_i_j above represents the j-th Batch generated by the i-th consensus node.

[0075] In one embodiment, each consensus node, when broadcasting the local subchain maintained in its local transaction pool to other consensus nodes, can employ incremental synchronization to periodically broadcast newly added subblocks to the local subchain. Specifically, when a new subblock is added to the local subchain during a new block generation cycle, the newly added subblock can be promptly broadcast to the other consensus nodes. Conversely, each consensus node can also receive new subblocks on its local subchain, periodically broadcast from other consensus nodes.

[0076] In this way, each consensus node can periodically broadcast newly added sub-blocks to other consensus nodes according to the block generation period of the sub-blocks on the local sub-chain, thereby avoiding the problem of excessive bandwidth consumption caused by synchronizing the entire local sub-chain to other consensus nodes.

[0077] Of course, it should be emphasized that in actual applications, when the blockchain system does not pay attention to bandwidth consumption, it is also possible to broadcast the entire local sub-chain to other consensus nodes.

[0078] In one embodiment shown, see Figure 3 , Figure 3 This is a schematic diagram of a data format corresponding to a sub-block shown in this specification.

[0079] like Figure 3As shown, the data format of the above 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., an indicator list field).

[0080] The Previous Hash field is used to fill in the hash value of the previous subblock linked to the subblock in the local subchain to which it belongs;

[0081] The Batch Height field is used to fill in the subblock identifier representing the block height of the subblock in its local subchain. This subblock identifier can be a global identifier in the blockchain system. For example, as mentioned above, this subblock identifier can be in the form of Bth_i_j, indicating the jth batch generated by the i-th consensus node. The value of j represents the block height of the batch in its local subchain.

[0082] The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in the sub-block;

[0083] Batch Tip List field: used to fill in the height list consisting of the block heights of the latest sub-blocks on the local sub-chain corresponding to other consensus nodes stored in the local transaction pool at the time of creating the current sub-block.

[0084] It should be noted that the height list filled in the Batch Tip List field can usually indicate the reception progress of the local sub-chains corresponding to other consensus nodes stored locally by the current consensus node at the moment of creating the sub-block.

[0085] For example, see Figure 2 , assuming Figure 2As shown, when node1 creates the sub-block Bth_1_5, 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 node3 is Bth_3_5, and the corresponding block height is also 5; the latest sub-block on the local sub-chain corresponding to node4 is Bth_4_5, and the corresponding block height is also 5. In this case, the height list filled in the Batch Tip List field contained in the data structure of the Bth_1_5 sub-block can be expressed as [1:5,2:5,3:5,4:5]. At this time, the height list means that when node1 creates Bth_1_5, the latest subblock of the local subchain corresponding to node1 maintained in node1's local transaction pool is updated to Bth_1_5, the latest subblock of the local subchain corresponding to node2 maintained in node1's local transaction pool is updated to Bth_2_5, the latest subblock of the local subchain corresponding to node3 maintained in node1's local transaction pool is updated to Bth_3_5, and the latest subblock of the local subchain corresponding to node4 maintained in node1's local transaction pool is updated to Bth_4_5. It is not difficult to understand that the height list filled in the above Batch Tip List field actually represents the reception progress of each subchain maintained in node1's local transaction pool. It should be noted that if the above blockchain system adopts a leader-based non-Byzantine consensus algorithm (such as RAFT or PAXOS), the data format of the above subblocks can be as follows: Figure 2 The data format shown.

[0086] Since the Byzantine consensus algorithm usually takes into account the existence of Byzantine nodes (i.e. malicious nodes) among the consensus nodes, in a blockchain system that adopts the Byzantine consensus algorithm, it is usually necessary to sign the transmitted data and verify whether the data has been tampered with by the Byzantine nodes based on the signature verification mechanism.

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

[0088] See Figure 4 , Figure 4 This is a schematic diagram of a data format corresponding to another seed block shown in this specification.

[0089] If the consensus protocol adopted by the above blockchain system is the leader-based Byzantine consensus algorithm, the data format designed for the above sub-blocks can be as follows Figure 4 As shown. Figure 4 The data format of the above sub-blocks shown may contain Figure 3 In addition to the fields shown in , a Signature field may also be included.

[0090] The Signature field can be used to fill in the signature of the subblock's creator. It should be noted that the signature of the subblock can be a signature submitted for the entire subblock or a signature submitted for the subblock header, and this specification does not specifically limit this.

[0091] In one embodiment shown, after each consensus node receives the local sub-chain maintained in its local transaction pool broadcast by other consensus nodes through the pre-transmission mechanism described above, it can also verify the legitimacy of the sub-blocks contained in the received local sub-chain, and after the legitimacy verification is passed, maintain the received local sub-chain in the local transaction pool.

[0092] Of course, for blockchain systems with high entry barriers and high levels of trust, after receiving the local sub-chain maintained in its local transaction pool broadcast by other consensus nodes, each consensus node may not verify the legitimacy of the sub-blocks contained in the received local sub-chain, but directly maintain the received local sub-chain in the local transaction pool.

[0093] It should be noted that the verification items that each consensus node needs to perform when verifying the legitimacy of the sub-blocks contained in the received local sub-chain usually correspond to the fields contained in the data structure of the above-mentioned sub-blocks.

[0094] In one embodiment shown, when each consensus node verifies the legitimacy of a sub-block, the verification items that need to be performed generally include at least one or a combination of the following verification items:

[0095] Verification Item 1:

[0096] The signature filled in the signature field of the sub-block is verified; if the verification of the signature passes, the next step of verification is further performed; otherwise, it is determined that the legitimacy verification of the sub-block has failed.

[0097] Verification Item 2:

[0098] Verify whether the local transaction pool stores the previous subblock linked to the subblock indicated by the hash value filled in the Previous Hash field of the subblock; if so, further perform the next step of verification; otherwise, further obtain the previous subblock from the consensus node that created the previous subblock.

[0099] By executing verification item 2, it can be ensured that the previous block of the sub-block chain has been stored in the local transaction pool.

[0100] Verification Item 3:

[0101] Verify whether the local transaction pool stores other subblocks that are linked to the same previous subblock as the subblock; if so, determine that the legitimacy verification of the subblock has failed; otherwise, proceed to the next step of verification;

[0102] By executing verification item 3, we can avoid the situation where two conflicting sub-blocks linked to the same block are stored in the local transaction pool at the same time. This situation is usually caused by malicious nodes (i.e. Byzantine nodes) maliciously generating forks on the local sub-chain. For example, see Figure 5 , assuming Figure 2 If node 1 initiates a fork attack, it may create two sub-blocks Bth_1_3 and Bth_1_3 that are linked to sub-block Bth_1_2. ′ .

[0103] Verification Item 4:

[0104] Verify whether the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the sub-block are incremental compared to the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the previous sub-block linked to the sub-block; if so, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed;

[0105] In actual applications, the block heights of the local subchains corresponding to other consensus nodes maintained in the local transaction pool will continuously increase due to the continuous receipt of new subblocks. If the block heights corresponding to other consensus nodes included in the height list filled in the indication list field of a received subblock do not increase compared to the block heights corresponding to other consensus nodes included in the height list filled in the indication list field of the previous subblock linked to the subblock, then the subblock may not have been correctly filled with the latest subblocks on the local subchains corresponding to other consensus nodes in the indication list field when it was created (the specific reason may be a malicious node intentionally). In this case, the subblock is an erroneous subblock. Based on this, by executing Verification Item 4, the above-mentioned erroneous subblock can be discovered in a timely manner.

[0106] Verification Item 5:

[0107] Verify the signature of each transaction in the transaction list contained in the sub-block; if the verification of the signature of each transaction passes, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed;

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

[0109] Verification Item 6:

[0110] Verify 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 so, determine that the legitimacy verification of the sub-block has passed; otherwise, determine that the legitimacy verification of the sub-block has failed.

[0111] By executing Verification 6, we can ensure that the subblock contains the correct list of transactions.

[0112] It should be noted that the execution order of the various verification items shown above is not specifically limited in this specification. In actual applications, the corresponding order can be flexibly formulated based on actual needs. When the consensus algorithm adopted by the above-mentioned blockchain system is a leader-based Byzantine consensus algorithm or a leader-based non-Byzantine consensus algorithm, the verification items required to be executed by each consensus node when verifying the legitimacy of a sub-block may generally vary.

[0113] In one embodiment shown, if the consensus algorithm adopted by the blockchain system is the leader-based Byzantine consensus algorithm, the data format of the sub-block can be as follows: Figure 3 As shown in the figure. Since the Byzantine consensus algorithm usually takes into account the existence of Byzantine nodes (i.e., malicious nodes) among the consensus nodes, and in the blockchain system that adopts the Byzantine consensus algorithm, it is usually necessary to sign the transmitted data and verify whether the data has been tampered with by the Byzantine nodes based on the signature verification mechanism, in this case, when each consensus node verifies the legitimacy of the sub-block, the verification items that need to be executed may include the verification items 1 to 6 mentioned above.

[0114] In one implementation, each consensus node can also maintain a local blacklist specifically for identifying malicious nodes discovered during the legitimacy verification of subblocks or proposed blocks. During Verification Item 3, if the local transaction pool stores other subblocks linked to the same previous subblock as the subblock, the creators of the subblock and the other subblocks can be further determined and added to the local blacklist as malicious nodes.

[0115] In addition, in one implementation, the sub-block and the other sub-blocks may be broadcasted to other consensus nodes, so that the other consensus nodes can verify whether the sub-block and the other sub-blocks are linked to the same previous sub-block. When it is verified that the sub-block and the other sub-blocks are indeed linked to the same previous sub-block, the creators of the sub-block and the other sub-blocks may be further determined, and the creators may be added to the blacklist as malicious nodes. For example, in implementation, only the sub-block headers of the sub-block and the other sub-blocks may be broadcasted to other consensus nodes, so that the other consensus nodes can perform the above-mentioned verification based on the information recorded in the above-mentioned sub-block headers, and determine the creators of the sub-block and the other sub-blocks based on the information recorded in the above-mentioned sub-block headers.

[0116] Alternatively, in another implementation, the information of the determined creator may be directly broadcast to other consensus nodes, so that other consensus nodes add the creator as a malicious node to the blacklist.

[0117] It should be noted that child blocks created by malicious nodes maintained in the blacklist will not be added to the proposed blocks subsequently created by the master node. For example, in one example, when creating a proposed block, the master node can exclude child blocks created by malicious nodes maintained in the blacklist from the proposed block based on the blacklist.

[0118] In one embodiment shown, if the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm, the data format of the sub-block can be as follows: Figure 2 As shown. Since the non-Byzantine consensus algorithm usually does not need to consider the existence of Byzantine nodes in the consensus nodes, in this case, when each consensus node verifies the legitimacy of the sub-block, the verification items that need to be executed may include the verification items 2, 4 and 6 mentioned above. That is, there is no need to execute the verification items 1, 3 and 5 mentioned above. Step 104, obtain the sub-block set from each local sub-chain maintained in the local transaction pool, and create a proposed block based on the obtained sub-block set; wherein the proposed block contains the sub-block identifier corresponding to each sub-block in the sub-block set;

[0119] As mentioned above, by adopting the pre-transmission mechanism described above, each consensus node will receive the local sub-chain maintained in the local transaction pool of all consensus nodes. Ultimately, all the local sub-chains received by each consensus node will form a structured chain transaction pool structure consisting of multiple sub-chains.

[0120] The master node can obtain the set of subblocks to be agreed upon from each local subchain in the chained transaction pool structure maintained by the local transaction pool, and then create a proposed block based on the obtained set of subblocks. For example, in implementation, the master node can periodically obtain the set of subblocks to be agreed upon from each local subchain maintained by the local transaction pool according to the block formation period of the proposed block.

[0121] It should be noted that the specific method by which the master node obtains the sub-block set from each local sub-chain maintained in the local transaction pool is not specifically limited in this specification.

[0122] In this specification, when the master node obtains the subblock set from each local subchain maintained in the local transaction pool, it can specifically refer to the height list filled in the latest subblock in each local subchain, and split each local subchain maintained from the local transaction pool according to the reception progress of the local subchain corresponding to each consensus node represented by the height list to determine the subblock set that needs to be added to the proposed block.

[0123] Among them, the specific method of splitting each local sub-chain maintained from the local transaction pool according to the reception progress of the local sub-chain corresponding to each consensus node represented by the height list is not specifically limited in this specification. In actual application, it can be flexibly determined based on the specific scenario.

[0124] In one embodiment shown, the master node can use the local sub-chain with the slowest receiving progress among the local sub-chains corresponding to each consensus node maintained in the local transaction pool as a benchmark, and split each local sub-chain by determining the common height of the latest sub-blocks in these local sub-chains.

[0125] In this case, the master node can first determine the latest subblocks in each local subchain maintained in the local transaction pool, and further obtain the height list filled in the Batch Tip List field in the subblock header of the latest subblock in each local subchain.

[0126] After obtaining 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 obtained height list can be used as a benchmark to further determine the common height between the block height of the latest sub-block on each sub-chain maintained in the local transaction pool of the master node and the block height of the latest sub-block on each sub-chain maintained in the local transaction pool of other consensus nodes.

[0127] After determining the public height, the master node can use the public height as a split point to obtain a sub-block set consisting of sub-blocks with block heights no greater than the public height from each local sub-chain maintained in the master node's local transaction pool, and then create a proposed block based on the obtained sub-block set.

[0128] For example, in one example, see Figure 2 ,if Figure 2 Node1 in the master node is the master node. The height list filled in the Batch Tip List field of the latest sub-block (i.e., the sub-block with the largest block height) on the local sub-chain corresponding to node1-node4 maintained in the local transaction pool of the master node is shown in Table 1:

[0129] Node number 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]

[0130] Table 1

[0131] It should be explained that in the above table, [1:5, 2:5, 3:5, 4:5] represents the Batch Tip of the latest sub-block on the local sub-chain corresponding to Node1 maintained in Node1's local transaction pool. The List field is populated with a height list. In this height list, "1:5" indicates that the highest height of the subblock on the local subchain corresponding to node1 maintained in Node1's local transaction pool is 5; "2:5" indicates that the highest height of the subblock on the local subchain corresponding to node2 maintained in Node1's local transaction pool is 5 (that is, the local subchain corresponding to node2 maintained in Node1's local transaction pool has received the 5th subblock); "3:5" indicates that the highest height of the subblock on the local subchain corresponding to node3 maintained in Node1's local transaction pool is 5 (that is, the local subchain corresponding to node3 maintained in Node1's local transaction pool has received the 5th subblock); "4:5" indicates that the highest height of the subblock on the local subchain corresponding to node4 maintained in Node1's local transaction pool is 5 (that is, the local subchain corresponding to node4 maintained in Node1's local transaction pool has received the 5th subblock).

[0132] [1:5,2:5,3:4,4:3] represents the height list filled in the Batch Tip List field of the latest sub-block on the local sub-chain corresponding to node2, which is maintained in the local transaction pool of node1; [1:3,2:4,3:5,4:5] represents the height list filled in the Batch Tip List field of the latest sub-block on the local sub-chain corresponding to node3, which is maintained in the local transaction pool of node1; [1:3,2:3,3:4,4:6] represents the height list filled in the Batch Tip List field of the latest sub-block on the local sub-chain corresponding to node4, which is maintained in the local transaction pool of node1; the meanings of these height lists are similar to the meanings of the height lists filled in the Batch Tip List field of the latest sub-block on the local sub-chain corresponding to node1, which are maintained in the local transaction pool of node1, and will not be repeated here.

[0133] Based on the above table, when the master node splits these local subchains using the public heights of the latest subblocks in the local subchains corresponding to each consensus node maintained in the local transaction pool, it can use the consensus node with the slowest collection progress for these local subchains as the benchmark to determine the public heights of the latest subblocks in the local subchains corresponding to each consensus node.

[0134] From the above table, we can see that the consensus nodes with the slowest reception progress for the local sub-chain corresponding to node1 among node1-node4 are node3 and node4, both of which have received the third sub-block. At this time, the public height of the local sub-chain corresponding to node1 maintained by node1-node4 in their local transaction pool is 3.

[0135] At this time, the master node can select Bth_1_1 to Bth_1_3 from the local sub-chain corresponding to node1 maintained in the local transaction pool as the set of sub-blocks that need to be added to the proposed block.

[0136] From the above table, we can see that the consensus node with the slowest reception progress for the local sub-chain corresponding to node2 among node1-node4 is node4. When receiving the third sub-block, the public height of the local sub-chain corresponding to node2 maintained by node1-node4 in its local transaction pool is 3.

[0137] At this time, the master node can select Bth_2_1 to Bth_2_3 from the local sub-chain corresponding to node2 maintained in the local transaction pool as the set of sub-blocks that need to be added to the proposed block.

[0138] From the above table, we can see that the consensus nodes with the slowest reception progress for the local sub-chain corresponding to node3 among node1-node4 are node2 and node4, both of which have received the 4th sub-block. At this time, the public height of the local sub-chain corresponding to node3 maintained by node1-node4 in its local transaction pool is 4.

[0139] At this time, the master node can select Bth_3_1 to Bth_3_4 from the local sub-chain corresponding to node3 maintained in the local transaction pool as the set of sub-blocks that need to be added to the proposed block.

[0140] Continuing to refer to the table above, the consensus node with the slowest reception progress for the local sub-chain corresponding to node4 among node1-node4 is node2. When receiving the third sub-block, the public height of the local sub-chain corresponding to node4 maintained by node1-node4 in its local transaction pool is 3.

[0141] At this time, the master node can select Bth_4_1 to Bth_4_3 from the local sub-chain corresponding to node4 maintained in the local transaction pool as the set of sub-blocks that need to be added to the proposed block.

[0142] Based on the above table, the sub-block set selected by the master node from the four 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];

[0143] In this record, Bth_1_3 represents Bth_1_1 to Bth_1_3 on the local subchain corresponding to node1; Bth_2_3 represents Bth_2_1 to Bth_2_3 on the local subchain corresponding to node2; Bth_3_4 represents Bth_3_1 to Bth_3_4 on the local subchain corresponding to node3; and Bth_4_3 represents Bth_4_1 to Bth_4_3 on the local subchain corresponding to node4.

[0144] In another embodiment shown, the master node may also use the N local sub-chains with the fastest receiving progress among the local sub-chains corresponding to each consensus node maintained in the local transaction pool as a benchmark, and split each local sub-chain by determining the common height of the latest sub-blocks in these local sub-chains.

[0145] In this case, after obtaining 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 can further determine the N consensus nodes with the largest block heights of the latest sub-blocks in each local sub-chain maintained in the master node's local transaction pool and the local transaction pools of other consensus nodes based on the obtained height list (that is, the N consensus nodes with the fastest receiving progress for each local sub-chain);

[0146] The receiving progress of these N consensus nodes can then be used as a benchmark to further determine the common height between the block heights of the latest sub-blocks on each local sub-chain maintained in the local transaction pool of these N consensus nodes;

[0147] After determining the public height, the master node can use the public height as a split point to obtain a sub-block set consisting of sub-blocks with block heights no greater than the public height from each local sub-chain maintained in the master node's local transaction pool, and then create a proposed block based on the obtained sub-block set.

[0148] The value of N can be the maximum number of fault-tolerant nodes for consensus nodes participating in the consensus algorithm used by the blockchain system. The value of N can be a value that is less than the total number of consensus nodes in the blockchain system.

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

[0150] For example, in another example, still with Figure 2 Node 1 is the master node. The height list populated in the BatchTip List field of the latest subblock (i.e., the subblock with the largest block height) on the local subchain corresponding to nodes 1-node 4 maintained in the master node's local transaction pool is shown in Table 1. Assuming the blockchain system uses the Byzantine consensus algorithm and has 4 consensus nodes, the value of f is 1, and the value of N is 2f + 1 = 3.

[0151] By comparing the reception progress of node1-node4 for each local sub-chain in Table 1, it can be seen that node4 has the slowest reception progress for the local sub-chain corresponding to node1-node3. Therefore, excluding node4 with the slowest reception progress, the master node can determine the three consensus nodes, such as node1-node3, as the three consensus nodes with the largest block height of the latest sub-block in each local sub-chain maintained (that is, the N consensus nodes with the fastest reception progress for each local sub-chain).

[0152] Furthermore, the master node can further determine the common height between the block heights of the latest subblocks on the local subchains corresponding to nodes 1-node 4 and maintained in the local transaction pools of nodes 1-node 3. The specific method for determining the common height is described above and will not be repeated here.

[0153] Based on Table 1, it can be seen that 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 node2 maintained in the local transaction pool of node1-node3 is 4; the common height between the block heights of the latest sub-blocks on the local sub-chain corresponding to node3 maintained in the local transaction pool of 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 node1-node3 is 3.

[0154] At this time, the master node can select Bth_1_1 to Bth_1_3 from the local subchain corresponding to node1 maintained in the local transaction pool as the set of subblocks that need to be added to the proposed block, select Bth_2_1 to Bth_2_4 from the local subchain corresponding to node2 maintained in the local transaction pool as the set of subblocks that need to be added to the proposed block, select Bth_3_1 to Bth_3_4 from the local subchain corresponding to node3 maintained in the local transaction pool as the set of subblocks that need to be added to the proposed block, and select Bth_4_1 to Bth_4_3 from the local subchain corresponding to node4 maintained in the local transaction pool as the set of subblocks that need to be added to the proposed block.

[0155] Based on Table 1, the set of subblocks selected by the master node from the four local subchains corresponding to nodes 1-4 maintained in the local transaction pool can be recorded as [Bth_1_3, Bth_2_4, Bth_3_4, Bth_4_3]. Node 4, which has the slowest reception progress, needs to receive the fourth subblock (i.e., Bth_2_4) on the local subchain corresponding to node 2 from other consensus nodes before it can reach a final consensus with the other consensus nodes.

[0156] In this specification, when the master node adopts the segmentation method described in the above embodiment, after obtaining the sub-block set that needs to be added to the proposed block from each local sub-chain maintained in the local transaction pool, it can create a proposed block based on the sub-block set.

[0157] It should be noted that due to the pre-transmission mechanism described above, the master node has already pre-synchronized and stored the subblock sets required for inclusion in the proposed block, obtained from each local subchain maintained in the local transaction pool, in the local transaction pool of each consensus node. Therefore, in this specification, the proposed block created by the master node based on this subblock set can contain the subblock identifiers corresponding to each subblock in the subblock set, rather than the data structures corresponding to each subblock in the subblock set. This ensures that the proposed block no longer contains a list of transactions awaiting consensus.

[0158] In one embodiment shown, see Figure 6 , Figure 6 This is a schematic diagram of a data format corresponding to a proposed block shown in this specification.

[0159] like Figure 6 As shown, the data format corresponding to the above proposed block may specifically include a Batch List field (i.e., a sub-block set field) and a Merkle Root field.

[0160] The Batch List field is used to fill in the sub-block identifier corresponding to each sub-block in the sub-block set included in the proposed block;

[0161] The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in each sub-block in the sub-block set.

[0162] It should be noted that if the above blockchain system adopts a leader-based non-Byzantine consensus algorithm (such as RAFT or PAXOS), the data format of the above proposed block can be as follows: Figure 6 If the consensus protocol adopted by the blockchain system is a leader-based Byzantine consensus algorithm, such as PBFT or HotStuff, then when designing the data format of the proposal block, it is usually necessary to introduce a signature field into the data format of the proposal block.

[0163] See Figure 7 , Figure 7 This is a schematic diagram of another proposed data format corresponding to a block shown in this specification.

[0164] If the consensus protocol adopted by the above blockchain system is the leader-based Byzantine consensus algorithm, the data format designed for the above proposal can be as follows Figure 7 As shown. Figure 7 The data format of the proposed block shown above may contain Figure 6 In addition to the fields shown in , a Signature field may also be included.

[0165] The Signature field can be used to fill in the master node's signature on the proposed block.

[0166] Step 106: Distribute the proposed block to other consensus nodes respectively, so that each consensus node can obtain the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and perform consensus processing on the obtained transaction list.

[0167] In this manual, the master node follows the above Figure 6 or Figure 7 After creating the proposal block, the proposal block can be further distributed to other consensus nodes.

[0168] 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 in its corresponding algorithm process, in which the master node distributes the created proposed blocks.

[0169] Based on this, in one embodiment shown, when the master node distributes the proposed block to other consensus nodes, it can specifically broadcast the proposed block to other consensus nodes based on the proposed block distribution mechanism supported by the consensus protocol adopted by the blockchain system.

[0170] In an example, taking PBFT as an example, as a classic leader-based Byzantine consensus algorithm, the PBFT algorithm process usually includes two processes: Normal Case Phase and View Change Phase. Among them, the Normal Case Phase is called the regular phase in the PBFT algorithm process. Figure 8 This is the flow chart of the Normal Case Phase process. Figure 8 As shown, the Normal Case Phase mainly includes three phases: PRE-PREPARE (preparation), PREPARE (preparation) and COMMIT (commitment), among which Figure 8 Node 3 shown in the figure may represent a down node ( Figure 8 (Indicated by × in the middle).

[0171] based on Figure 8 In the algorithm process, the master node usually attaches the proposed block created based on the collected transactions sent by the client to a PRE-PREPARE message in the PRE-PREPARE phase, and then broadcasts the PRE-PREPARE message to other blockchain nodes to distribute the proposed block to other consensus nodes.

[0172] In this scenario, if the consensus algorithm adopted by the above blockchain system is PBFT, when the master node distributes the proposed block to other consensus nodes, it can specifically use the proposed block distribution mechanism in the PRE-PREPARE stage supported by PBFT. In the PRE-PREPARE stage, the proposed block is attached to the PRE-PREPARE message and broadcast to other consensus nodes.

[0173] As another example, let's take HotStuff, which is also a leader-based Byzantine consensus algorithm. Unlike PBFT, the regular phases of HotStuff's algorithm process include four phases: PREPARE, PRE-COMMIT, COMMIT, and DECIDE. Based on the HotStuff algorithm process, the master node usually attaches the proposed block created based on the collected transactions sent by the client to a PREPARE message during the PREPARE phase, and then broadcasts the PREPARE message to other blockchain nodes to distribute the proposed block to other consensus nodes.

[0174] In this scenario, if the consensus algorithm adopted by the above blockchain system is HotStuff, when the master node distributes the proposed block to other consensus nodes, it can specifically utilize the proposed block distribution mechanism in the PREPARE phase supported by HotStuff. In the PREPARE phase, the proposed block will be attached to the PREPARE message and broadcast to other consensus nodes.

[0175] In the third example, let's take Raft, a classic leader-based non-Byzantine consensus algorithm. Its algorithm typically consists of two phases: leader election and log replication. During the log replication phase, the master node typically encapsulates proposed blocks created based on collected client transactions into log entries. These log entries are then replicated to the other consensus nodes to distribute the proposed blocks.

[0176] In this scenario, if the consensus algorithm adopted by the above blockchain system is Raft, when the master node distributes the proposed block to other consensus nodes, it can specifically utilize the proposed block distribution mechanism in the log replicate phase supported by Raft. In the log replicate phase, the proposed block is encapsulated into individual log entries, and then these log entries are replicated to other consensus nodes to distribute the proposed block to each other consensus node.

[0177] In the fourth example, PAXOS is also a leader-based non-Byzantine consensus algorithm. Its algorithm typically consists of two phases: PREPARE and Accept. During the Accept phase, the master node typically includes a proposed block in an Accept message and broadcasts it to the other consensus nodes, distributing the proposed block to them.

[0178] In this scenario, if the consensus algorithm adopted by the above blockchain system is PAXOS, when the master node distributes the proposed block to other consensus nodes, it can specifically utilize the proposed block distribution mechanism in the Accept phase supported by PAXOS, attach the proposed block to an Accept message, and broadcast it to other consensus nodes to distribute the proposed block to each other consensus node.

[0179] In the above embodiment, by utilizing the proposed block distribution mechanism supported by the consensus protocol adopted by the blockchain system, the proposed block is distributed to other consensus nodes. The pre-transmission mechanism described above can be organically combined with the proposed block distribution mechanism supported by the consensus algorithm adopted by the blockchain system.

[0180] Due to the adoption of the aforementioned pre-transmission mechanism, the proposed blocks created by the master node no longer need to include a list of transactions awaiting consensus. Therefore, combining the aforementioned pre-transmission mechanism with the proposed block distribution mechanism supported by the consensus algorithm employed by the blockchain system can reduce the data volume and bandwidth consumption of messages sent when distributing proposed blocks using the proposed block distribution mechanism supported by the consensus algorithm. It is not difficult to understand that combining the aforementioned pre-transmission mechanism with the proposed block distribution mechanism supported by the consensus algorithm employed by the blockchain system can actually optimize the proposed block distribution mechanism supported by the consensus algorithm.

[0181] For example, see Figure 9 Taking the consensus algorithm adopted by the above blockchain system as PBFT as an example, after organically combining the pre-transmission mechanism described above with the proposed block distribution mechanism supported by PBFT, the pre-transmission mechanism described above can be used as a pre-transmission stage before the PRE-PREPARE stage of PBFT.

[0182] Due to the adoption of the aforementioned pre-transmission mechanism, the proposal block created by the master node no longer needs to include a transaction list. Therefore, during the PRE-PREPARE phase, the master node will attach the generated proposal block to the PRE-PREPARE message. When broadcast to other blockchain nodes, the data capacity of the PRE-PREPARE message will be significantly reduced. For example, in general, the PRE-PREPARE message will include a transaction list and a Merkle Root generated based on the transaction list. However, by combining the aforementioned pre-transmission mechanism with the PRE-PREPARE phase supported by pbft, the PRE-PREPARE message can only carry the Batch List field and Merkle Root field mentioned above. The size of the content filled in the Batch List field is significantly reduced from a linear level to a constant level relative to the transaction list.

[0183] The significant reduction in the data capacity of PRE-PREPARE messages will inevitably reduce the bandwidth consumption when exchanging PRE-PREPARE messages, which will obviously help improve the consensus efficiency of the PBFT protocol itself.

[0184] It should be noted that the above description only uses the consensus algorithm adopted by the above-mentioned blockchain system as PBFT as an example. In actual applications, when the consensus algorithm adopted by the blockchain system is other types of consensus algorithms, the above-mentioned pre-transmission mechanism can still be organically combined with the block distribution mechanism supported by these consensus algorithms as a pre-transmission stage before the first stage of the consensus algorithm. Examples will no longer be given one by one in this manual.

[0185] In this specification, when any consensus node other than the master node receives a proposal block distributed by the master node, it can verify the legitimacy of the obtained proposal block.

[0186] Of course, for blockchain systems with high entry barriers and high levels of trust, each consensus node may not verify the legitimacy of the proposed block after receiving it from the master node.

[0187] It should be noted that the verification items that each consensus node needs to perform when verifying the legitimacy of the received proposal block usually correspond to the fields contained in the data structure of the above-mentioned proposal block.

[0188] In one embodiment shown, when each consensus node verifies the legitimacy of a sub-block, the verification items that need to be performed generally include at least one or a combination of the following verification items:

[0189] Verification Item 7:

[0190] Verify the signature filled in the signature field of the proposed block; if the verification of the signature passes, further verification is performed; otherwise, it is determined that the validity verification of the proposed block has failed;

[0191] Verification Item 8:

[0192] Verify whether the local transaction pool stores the subblocks corresponding to the subblock identifiers filled in the subblock set field of the proposed block; if the local transaction pool stores the above subblocks, further verification is performed; otherwise, further subblocks of the Shanshu subblocks not stored in the local transaction pool are obtained from the master node or other consensus;

[0193] By executing Verification 2, it is ensured that the local transaction pool has stored all the sub-blocks included in the proposed block.

[0194] Verification Item 9:

[0195] Verify whether the hash value of the root node of the Merkle tree created based on the obtained transaction lists contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determine that the legitimacy verification of the proposed block has passed; otherwise, determine that the legitimacy verification of the proposed block has failed.

[0196] By executing verification item 9, it can be ensured that the subblock contains the correct transaction list.

[0197] It should be noted that the execution order of the various verification items shown above is not specifically limited in this specification. In actual applications, the corresponding order can be flexibly formulated based on actual needs. When the consensus algorithm adopted by the above-mentioned blockchain system is a leader-based Byzantine consensus algorithm or a leader-based non-Byzantine consensus algorithm, the verification items required to be executed by each consensus node when verifying the legitimacy of the proposed block may generally vary.

[0198] In one embodiment shown, if the consensus algorithm adopted by the blockchain system is the leader-based Byzantine consensus algorithm, the data format of the proposed block can be as follows: Figure 7As shown in the figure. Since the Byzantine consensus algorithm usually takes into account the existence of Byzantine nodes (i.e., malicious nodes) among the consensus nodes, and in the blockchain system that adopts the Byzantine consensus algorithm, it is usually necessary to sign the transmitted data and verify whether the data has been tampered with by the Byzantine nodes based on the signature verification mechanism, in this case, when each consensus node verifies the legitimacy of the sub-block, the verification items that need to be executed may include the verification items 7 to 9 mentioned above.

[0199] Among them, in one embodiment shown, if the consensus algorithm adopted by the blockchain system is the leader-based Byzantine consensus algorithm, then Figure 7 In the Batch List field in the data format shown, in addition to the subblock identifiers of the subblocks in the subblock set included in the proposed block, the hash values of the above subblocks can also be filled in.

[0200] In this case, during the execution of the above-mentioned verification item 8, if it is determined that the local transaction pool stores the sub-blocks corresponding to the sub-block identifiers filled in the Batch List field of the proposed block, the hash of the above-mentioned sub-blocks stored in the local transaction pool can be further calculated, and the hash values corresponding to the above-mentioned sub-blocks filled in the Batch List field of the proposed block can be obtained. Then, it is verified whether the calculated hash of the above-mentioned sub-blocks stored in the local transaction pool are the same as the hash values corresponding to the above-mentioned sub-blocks filled in the Batch List field of the proposed block. If so, the next step of verification is further performed.

[0201] In one implementation shown, if the hash value of any target sub-block among the above-mentioned sub-blocks stored in the local transaction pool is different from the hash value of the target sub-block filled in the Batch List field of the acquired proposed block, the creator of the target sub-block can be further determined and added to the blacklist as a malicious node.

[0202] In addition, in one implementation, 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 can be broadcast together to other consensus nodes, so that the other consensus nodes can calculate the hash value of the target sub-block and verify whether the hash value of the target sub-block and the hash value of the target sub-block filled in the Batch List field of the proposed block are the same; if it is verified that the hash value of the target sub-block and the hash value of the target sub-block filled in the Batch List field of the proposed block are indeed the same, the creator of the target sub-block can be further determined, and the creator can be added to the blacklist as a malicious node.

[0203] Alternatively, in another implementation, the information of the determined creator may be directly broadcast to other consensus nodes, so that other consensus nodes add the creator as a malicious node to the blacklist.

[0204] It is important to note that child blocks created by malicious nodes in the blacklist will not be added to the proposed blocks subsequently created by the master node. For example, in one example, when creating a proposed block, the master node can exclude child blocks created by malicious nodes in the blacklist from the proposed block based on the blacklist.

[0205] In one embodiment shown, if the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm, the data format of the proposed block can be as follows: Figure 6 As shown in the figure, since non-Byzantine consensus algorithms generally do not need to consider the presence of Byzantine nodes among the consensus nodes, in this case, when each consensus node verifies the legitimacy of a sub-block, the verification items that need to be performed include verification items 8 and 9 mentioned above. In other words, verification item 7 mentioned above does not need to be performed.

[0206] In this specification, after a consensus node other than the master node has verified the legitimacy of a received proposal block distributed by the master node, it can obtain the transaction lists contained in each sub-block corresponding to each sub-block identifier filled in the Batch List field in the proposal block from each local sub-chain maintained in its local transaction pool, and then enter the consensus voting phase of the consensus algorithm adopted by the blockchain system to perform consensus voting on the obtained transaction lists.

[0207] It's important to emphasize that integrating the pre-transmission mechanism described above with the proposed block distribution mechanism supported by the consensus algorithm employed by the blockchain system does not impact the existing consensus process. Subsequent consensus voting on the acquired transaction list can still follow the existing consensus algorithm process employed by the blockchain system and will not be further detailed in this specification.

[0208] See Figure 10 , Figure 10 This is a flowchart of a consensus method in a blockchain system according to an exemplary embodiment of the present specification. The blockchain system includes multiple consensus nodes; the multiple consensus nodes include a master node elected based on a leader-based consensus algorithm adopted by the blockchain system. The method can be applied to any consensus node other than the master node; the method includes:

[0209] Step 1002: Broadcast the local subchain maintained in the local transaction pool to other consensus nodes; and receive the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintain the received local subchain in the local transaction pool.

[0210] Step 1004: Obtain a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each subchain maintained in its local transaction pool; the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0211] Step 1006: Obtain the 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 perform consensus processing on the obtained transaction list.

[0212] In this embodiment, the description will be made from the perspective of any consensus node other than the master node. For the specific implementation details of the above steps, please refer to Figure 1 The embodiments provided will not be described in detail in this specification.

[0213] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of a blockchain system, a consensus node, and a storage medium.

[0214] This specification also provides an embodiment of a blockchain system, wherein the blockchain system may include multiple consensus nodes; the multiple consensus nodes include an elected master node; each of the multiple consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes several sub-blocks created by each consensus node based on transactions stored in the local transaction pool; wherein:

[0215] The master node broadcasts the local subchain maintained in the local transaction pool to the other consensus nodes; receives the local subchains maintained in the local transaction pools broadcast by the other consensus nodes, and maintains the received local subchains in the local transaction pool; obtains a subblock set from each local subchain maintained in the local transaction pool, and creates a proposal block based on the obtained subblock set; wherein the proposal block includes a subblock identifier corresponding to each subblock in the subblock set; and distributes the proposal block to the other consensus nodes respectively;

[0216] Consensus nodes other than the master node broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes; and receive the local sub-chains maintained in their local transaction pools broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool; obtain the proposed block transmitted by the master node, obtain the 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 perform consensus processing on the obtained transaction list.

[0217] Figure 11 This is a schematic structural diagram of an electronic device provided by an exemplary embodiment. Figure 1 At the hardware level, the device includes a processor 1102, an internal bus 1104, a network interface 1106, a memory 1108, and a non-volatile memory 1110. Of course, it may also include hardware required for other services. One or more embodiments of this specification can be implemented based on software, such as the processor 1102 reading the corresponding computer program from the non-volatile memory 1110 into the memory 1108 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0218] like Figure 12 As shown, Figure 12 This is a block diagram of a consensus node in a blockchain system according to an exemplary embodiment of the present specification. The device can be applied to Figure 11 The electronic device shown in the figure implements the technical solution of this specification. The blockchain system includes multiple consensus nodes; the multiple consensus nodes include an elected master node; each of the multiple consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes several sub-blocks created by each consensus node based on transactions stored in the local transaction pool; the consensus node 120 includes:

[0219] The first sending module 1201 broadcasts the local subchain maintained in the local transaction pool to other consensus nodes; and receives the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintains the received local subchain in the local transaction pool;

[0220] Creation module 1202 obtains a subblock set from each local subchain maintained in the local transaction pool, and creates a proposed block based on the obtained subblock set; wherein the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0221] The transmission module 1203 distributes the proposed block to other consensus nodes respectively, so that each consensus node obtains the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

[0222] The specific details of each module of the above-mentioned device 120 have been described in detail in the method flow described above, and therefore will not be repeated here.

[0223] like Figure 13 As shown, Figure 13 This is a block diagram of a consensus node in a blockchain system according to another exemplary embodiment of the present specification. The device can also be applied to Figure 11 The electronic device shown in the figure implements the technical solution of this specification. The blockchain system includes multiple consensus nodes; the multiple consensus nodes include an elected master node; each of the multiple consensus nodes maintains a local sub-chain in its local transaction pool; the local sub-chain includes several sub-blocks created by each consensus node based on transactions stored in the local transaction pool; the consensus node 130 includes:

[0224] The second sending module 1301 broadcasts the local subchain maintained in the local transaction pool to other consensus nodes; and receives the local subchain maintained in the local transaction pool broadcast by other consensus nodes, and maintains the received local subchain in the local transaction pool;

[0225] An acquisition module 1302 acquires a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each subchain maintained in its local transaction pool; the proposed block includes a subblock identifier corresponding to each subblock in the subblock set;

[0226] The consensus module 1303 obtains the 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 performs consensus processing on the obtained transaction list.

[0227] The specific details of each module of the above-mentioned device 130 have been described in detail in the method flow described above, and therefore will not be repeated here.

[0228] Accordingly, this 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 in all the method flows described above.

[0229] Accordingly, this specification also provides a computer-readable storage medium having executable instructions stored thereon; wherein, when the instructions are executed by a processor, the steps in all the method flows described above are implemented.

[0230] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0231] The systems, devices, modules, or components described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

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

[0233] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0234] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, 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 disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0235] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0236] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0237] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0238] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0239] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A consensus method in a blockchain system, the method being applied to a master node elected from a plurality of consensus nodes participating in the consensus in the blockchain system; wherein: A local sub-chain is maintained in the local transaction pool of each consensus node among the plurality of consensus nodes; the local sub-chain includes a plurality of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and includes: Broadcasting the local subchain maintained in the local transaction pool to other consensus nodes; and receiving the local subchains maintained in their local transaction pools broadcast by other consensus nodes, and maintaining the received local subchains in the local transaction pool; Obtain a subblock set from each local subchain maintained in the local transaction pool, and create a proposed block based on the obtained subblock set; wherein the proposed block includes a subblock identifier corresponding to each subblock in the subblock set; The proposed block is distributed to other consensus nodes respectively, so that each consensus node obtains the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

2. The method of claim 1, before broadcasting the local sub-chain maintained in the local transaction pool to other consensus nodes, further comprising: Periodically obtain transaction lists from the local transaction pool and create sub-blocks based on the obtained transaction lists; Link the created subblock with the latest subblock on the local subchain maintained in the local transaction pool.

3. In the method of claim 2, the period duration corresponding to the block formation period of the proposed block is an integer multiple of the period duration corresponding to the block formation period of the sub-block.

4. The method according to claim 2, Send the local subchain maintained in the local transaction pool to other consensus nodes, including: Periodically broadcast the newly added sub-blocks on the local sub-chain to other consensus nodes; Receive local subchains maintained in their local transaction pools broadcast by other consensus nodes, including: Receive new sub-blocks on the local sub-chain that are periodically broadcasted by other consensus nodes.

5. The method according to claim 1, before maintaining the received local sub-chain in the local transaction pool, the method further comprises: The legitimacy of the sub-blocks contained in the received local sub-chain is verified, and after the legitimacy verification is passed, the received local sub-chain is maintained in the local transaction pool.

6. The method according to claim 5, wherein the data structure corresponding to the sub-block comprises: Sub-block header, transaction list field; The transaction list field is used to fill in the transaction list contained in the sub-block; The sub-block header includes: The Previous Hash field is used to fill in the hash value of the previous subblock linked to the subblock in the local subchain to which it belongs; The height field is used to fill in the subblock identifier representing the block height of the subblock in the local subchain to which it belongs; The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in the sub-block; Indicator list field: used to fill in the height list consisting of the block heights of the latest sub-blocks on the local sub-chain corresponding to other consensus nodes stored in the local transaction pool at the time of creating the current sub-block.

7. According to the method of claim 6, if the consensus algorithm adopted by the blockchain system is a leader-based Byzantine consensus algorithm: The data format corresponding to the sub-block also includes: The signature field is used to fill in the signature of the sub-block creator on the sub-block; The legitimacy of the sub-block is verified, including: Verifying the signature filled in the signature field of the sub-block; If the verification of the signature passes, further verification is performed; otherwise, it is determined that the legitimacy verification of the sub-block fails; Verify whether the local transaction pool stores the previous subblock linked to the subblock indicated by the hash value filled in the Previous Hash field of the subblock; if so, proceed to the next step of verification; otherwise, obtain the previous subblock from the consensus node that created the previous subblock; Verify whether the local transaction pool stores other sub-blocks that are linked to the same previous sub-block as the sub-block; if so, determine that the legitimacy verification of the sub-block has failed; otherwise, proceed to the next step of verification; Verify whether the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the sub-block are incremental compared to the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the previous sub-block linked to the sub-block; if so, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify the signature of each transaction in the transaction list contained in the sub-block; if the verification of the signature of each transaction passes, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify 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 so, determine that the legitimacy verification of the sub-block has passed; otherwise, determine that the legitimacy verification of the sub-block has failed.

8. The method of claim 7, further comprising: If the local transaction pool stores other subblocks that are linked to the same previous subblock as the subblock, further determine the creators of the subblock and the other subblocks, and add the creator to the blacklist as a malicious node; as well as, Broadcasting the sub-block and the other sub-blocks to other consensus nodes, so that when the other consensus nodes verify that the sub-block and the other sub-blocks are linked to the same previous sub-block, they further determine the creators of the sub-block and the other sub-blocks and add the creators to a blacklist as malicious nodes; or broadcasting the creator to other consensus nodes, so that the other consensus nodes add the creator to a blacklist as malicious nodes; The proposed block does not include sub-blocks created by malicious nodes maintained in the blacklist.

9. The method of claim 6, wherein if the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm: The legitimacy of the sub-block is verified, including: Verify whether the local transaction pool stores the previous subblock linked to the subblock indicated by the hash value filled in the Previous Hash field of the subblock; if so, proceed to the next step of verification; otherwise, obtain the previous subblock from the consensus node that created the previous subblock; Verify whether the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the sub-block are incremental compared to the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the previous sub-block linked to the sub-block; if so, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify 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 so, determine that the legitimacy verification of the sub-block has passed; otherwise, determine that the legitimacy verification of the sub-block has failed.

10. The method of claim 1, wherein distributing the proposed block to other consensus nodes comprises: Based on the proposed block distribution mechanism supported by the consensus protocol adopted by the blockchain system, the proposed block is broadcasted to other consensus nodes.

11. The method of claim 6, wherein obtaining a sub-block set from each local sub-chain maintained in the local transaction pool comprises: Respectively determining the latest subblock in each local subchain maintained in the local transaction pool, and further obtaining the height list filled in the indication list field in the subblock header of the latest subblock in each local subchain; Based on the obtained height list, determine the common height between the block height of the latest subblock on each subchain maintained in the local transaction pool of the master node and the block height of the latest subblock on each subchain maintained in the local transaction pool of each other consensus node, and obtain a set of subblocks whose block height is not greater than the common height from each local subchain maintained in the local transaction pool of the master node.

12. The method of claim 11, wherein the common height between the block height of the latest subblock on each subchain maintained in the local transaction pool of the master node and the block height of the latest subblock on each subchain maintained in the local transaction pool of each other consensus node is determined based on the obtained height list, and a set of subblocks having a block height not greater than the common height is obtained from each local subchain maintained in the local transaction pool of the master node, comprising: Determine, based on the acquired height list, the N consensus nodes with the largest block heights of the latest subblocks in each local subchain maintained in the local transaction pool of the master node and the local transaction pools of each other consensus node; Determine the common height between the block heights of the latest subblocks on each local subchain maintained in the local transaction pool of the N consensus nodes; Obtain a set of subblocks whose block height is not greater than the public height from each local subchain maintained in the local transaction pool of the master node; The value of N is the maximum number of fault-tolerant nodes for consensus nodes participating in the consensus algorithm adopted by the blockchain system.

13. The method according to claim 12, If the consensus algorithm adopted by the blockchain system is the leader-based Byzantine consensus algorithm, the total number of consensus nodes participating in the consensus of the blockchain system is 3f+1, and the value of N is 2f+1.

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

15. The method according to claim 12, If the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm, the total number of consensus nodes participating in the consensus of the blockchain system is f, and the value of N is f / 2+1.

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

17. The method of claim 1, wherein: The proposed block does not include a transaction list; The data structure corresponding to the proposed block includes: The subblock set field is used to fill in the subblock identifier of each subblock in the subblock set included in the proposed block; The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in each sub-block in the sub-block set.

18. A consensus method in a blockchain system, wherein the plurality of consensus nodes participating in the consensus in the blockchain system include an elected master node; the method is applied to any consensus node among the plurality of consensus nodes except the master node; wherein: A local sub-chain is maintained in the local transaction pool of each consensus node among the plurality of consensus nodes; the local sub-chain includes a plurality of sub-blocks created by each consensus node based on transactions stored in the local transaction pool; and includes: Broadcasting the local subchain maintained in the local transaction pool to other consensus nodes; and receiving the local subchains maintained in their local transaction pools broadcast by other consensus nodes, and maintaining the received local subchains in the local transaction pool; Obtaining a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each local subchain maintained in its local transaction pool; the proposed block includes a subblock identifier corresponding to each subblock in the subblock set; From each local sub-chain maintained in the local transaction pool, obtain the transaction list contained in each sub-block corresponding to the sub-block identifier, and perform consensus processing on the obtained transaction list.

19. The method of claim 18, before broadcasting the local sub-chain maintained in the local transaction pool to other consensus nodes, further comprising: Periodically obtain transaction lists from the local transaction pool and create sub-blocks based on the obtained transaction lists; Link the created subblock with the latest subblock on the subchain maintained in the local transaction pool.

20. The method of claim 19, wherein the period duration corresponding to the block formation period of the proposed block is an integer multiple of the period duration corresponding to the block formation period of the sub-block.

21. The method of claim 19, Send the local subchain maintained in the local transaction pool to other consensus nodes, including: Periodically broadcast the newly added sub-blocks on the local sub-chain to other consensus nodes; Receive local subchains maintained in their local transaction pools broadcast by other consensus nodes, including: Receive new sub-blocks on the local sub-chain that are periodically broadcasted by other consensus nodes.

22. The method of claim 18, before maintaining the received local sub-chain in the local transaction pool, the method further comprises: The legitimacy of the sub-blocks contained in the received local sub-chain is verified, and after the legitimacy verification is passed, the received local sub-chain is maintained in the local transaction pool.

23. The method of claim 22, wherein the data structure corresponding to the sub-block comprises: Sub-block header, transaction list field; The transaction list field is used to fill in the transaction list contained in the sub-block; The sub-block header includes: The Previous Hash field is used to fill in the hash value of the previous subblock linked to the subblock in the local subchain to which it belongs; The height field is used to fill in the subblock identifier representing the block height of the subblock in the local subchain to which it belongs; The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in the sub-block; Indicator list field: used to fill in the height list consisting of the block heights of the latest sub-blocks on the local sub-chain corresponding to other consensus nodes stored in the local transaction pool at the time of creating the current sub-block.

24. The method of claim 23, wherein if the consensus algorithm adopted by the blockchain system is a leader-based Byzantine consensus algorithm: The data format corresponding to the sub-block also includes: The signature field is used to fill in the signature of the sub-block creator on the sub-block; The legitimacy of the sub-block is verified, including: Verifying the signature filled in the signature field of the sub-block; If the verification of the signature passes, further verification is performed; otherwise, it is determined that the legitimacy verification of the sub-block fails; Verify whether the local transaction pool stores the previous subblock linked to the subblock indicated by the hash value filled in the Previous Hash field of the subblock; if so, proceed to the next step of verification; otherwise, obtain the previous subblock from the consensus node that created the previous subblock; Verify whether the local transaction pool stores other sub-blocks that are linked to the same previous sub-block as the sub-block; if so, determine that the legitimacy verification of the sub-block has failed; otherwise, proceed to the next step of verification; Verify whether the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the sub-block are incremental compared to the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the previous sub-block linked to the sub-block; if so, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify the signature of each transaction in the transaction list contained in the sub-block; if the verification of the signature of each transaction passes, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify 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 so, determine that the legitimacy verification of the sub-block has passed; otherwise, determine that the legitimacy verification of the sub-block has failed.

25. The method of claim 24, further comprising: If the local transaction pool stores other subblocks that are linked to the same previous subblock as the subblock, further determine the creators of the subblock and the other subblocks, and add the creator to the blacklist as a malicious node; as well as, Broadcasting the sub-block and the other sub-blocks to other consensus nodes, so that when the other consensus nodes verify that the sub-block and the other sub-blocks are linked to the same previous sub-block, they further determine the creators of the sub-block and the other sub-blocks and add the creators to a blacklist as malicious nodes; or broadcasting the creator to other consensus nodes, so that the other consensus nodes add the creator to a blacklist as malicious nodes; The proposed block does not include sub-blocks created by malicious nodes maintained in the blacklist.

26. The method of claim 23, wherein if the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm: The legitimacy of the sub-block is verified, including: Verify whether the local transaction pool stores the previous subblock linked to the subblock indicated by the hash value filled in the Previous Hash field of the subblock; if so, proceed to the next step of verification; otherwise, obtain the previous subblock from the consensus node that created the previous subblock; Verify whether the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the sub-block are incremental compared to the block heights corresponding to the other consensus nodes in the height list filled in the indication list field of the previous sub-block linked to the sub-block; if so, proceed to the next step of verification; otherwise, determine that the legitimacy verification of the sub-block has failed; Verify 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 so, determine that the legitimacy verification of the sub-block has passed; otherwise, determine that the legitimacy verification of the sub-block has failed.

27. The method of claim 18, wherein before obtaining 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 obtained transaction list, the method further comprises: The obtained proposed block is subjected to a validity verification. After the validity verification is passed, the transaction list contained in each sub-block corresponding to the sub-block identifier is further obtained from each local sub-chain maintained in the local transaction pool, and a consensus process is performed on the obtained transaction list.

28. The method of claim 27, wherein: The proposed block does not include a transaction list; The data structure corresponding to the proposed block includes: The subblock set field is used to fill in the subblock identifier corresponding to each subblock in the subblock set included in the proposed block; The Merkle Root field is used to fill in the hash value of the root node of the Merkle tree created based on the transaction list contained in each sub-block in the sub-block set.

29. The method of claim 28, wherein if the consensus algorithm adopted by the blockchain system is a leader-based Byzantine consensus algorithm: The data structure corresponding to the proposed block also includes: The signature field is used to fill in the master node's signature on the proposed block; Verify the legitimacy of the proposed block, including: Verify the signature filled in the signature field of the proposed block; if the verification of the signature passes, further verification is performed; otherwise, determine that the validity verification of the proposed block fails; Verify whether the local transaction pool stores the subblocks corresponding to the subblock identifiers filled in the subblock set field of the proposed block; if the local transaction pool stores the subblocks, further perform the next step of verification; otherwise, further obtain the subblocks of the subblocks not stored in the local transaction pool from the master node or other consensus; Verify whether the hash value of the root node of the Merkle tree created based on the obtained transaction lists contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determine that the legitimacy verification of the proposed block has passed; otherwise, determine that the legitimacy verification of the proposed block has failed.

30. The method of claim 29, wherein if the consensus algorithm adopted by the blockchain system is a leader-based Byzantine consensus algorithm: The subblock set field is used to fill in 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, the next step of verification is performed, including: If the local transaction pool stores the sub-blocks, further calculating the hash of the sub-blocks stored in the local transaction pool; Obtain the hash values corresponding to the sub-blocks in the sub-block set field of the proposed block, and verify whether the hashes of the sub-blocks stored in the local transaction pool are the same as the obtained hash values; if so, proceed to the next step of verification.

31. The method of claim 30, further comprising: If the hash value of any target sub-block among the sub-blocks stored in the local transaction pool is different from the obtained hash value of the target sub-block, the creator of the target sub-block is determined and the creator is added to the blacklist as a malicious node; as well as, Broadcasting the target subblock stored in the local transaction pool and the hash value of the target subblock filled in the subblock set field of the proposed block to other consensus nodes, so that when the other consensus nodes verify that the hash value of the target subblock stored in the local transaction pool and the hash value of the target subblock filled in the subblock set field of the proposed block are the same, they further determine the creator of the target subblock and add the creator to the blacklist as a malicious node; or broadcasting the creator to other consensus nodes so that the other consensus nodes add the creator to the blacklist as a malicious node; The proposed block does not include sub-blocks created by malicious nodes maintained in the blacklist.

32. The method of claim 28, wherein if the consensus algorithm adopted by the blockchain system is a leader-based non-Byzantine consensus algorithm: Verify the legitimacy of the proposed block, including: Verify whether the local transaction pool stores the sub-blocks corresponding to the sub-block headers filled in the sub-block set field of the proposed block; if the local transaction pool stores the sub-blocks, further perform the next step of verification; otherwise, further obtain the sub-blocks of the sub-blocks not stored in the local transaction pool from the master node or other consensus; Verify whether the hash value of the root node of the Merkle tree created based on the obtained transaction lists contained in each sub-block is the same as the hash value filled in the Merkle Root field of the proposed block; if so, determine that the legitimacy verification of the proposed block has passed; Otherwise, it is determined that the validity verification of the proposed block has failed.

33. The method according to claim 30 or 32, wherein the leader-based non-Byzantine consensus algorithm includes a PBFT consensus algorithm or a HotStuff consensus algorithm; and the leader-based non-Byzantine consensus algorithm includes a RAFT consensus algorithm or a PAXOS consensus algorithm.

34. A blockchain system comprising a plurality of consensus nodes, including an elected master node; each of the plurality of consensus nodes maintains a local subchain in its local transaction pool; each local subchain comprises a plurality of subblocks created by each consensus node based on transactions stored in the local transaction pool; wherein: The master node broadcasts the local subchain maintained in the local transaction pool to the other consensus nodes; receives the local subchains maintained in the local transaction pools broadcast by the other consensus nodes, and maintains the received local subchains in the local transaction pool; obtains a subblock set from each local subchain maintained in the local transaction pool, and creates a proposal block based on the obtained subblock set; wherein the proposal block includes a subblock identifier corresponding to each subblock in the subblock set; and distributes the proposal block to the other consensus nodes respectively; Consensus nodes other than the master node broadcast the local sub-chain maintained in the local transaction pool to other consensus nodes; and receive the local sub-chains maintained in their local transaction pools broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool; obtain the proposed block transmitted by the master node, obtain the 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 perform consensus processing on the obtained transaction list.

35. A consensus node in a blockchain system, comprising a plurality of consensus nodes; the plurality of consensus nodes including an elected master node; each of the plurality of consensus nodes maintaining a local subchain in its local transaction pool; the local subchain comprising a plurality of subblocks created by each consensus node based on transactions stored in the local transaction pool; comprising: The first sending module broadcasts the local sub-chain maintained in the local transaction pool to other consensus nodes; Also, receive the local sub-chains maintained in the local transaction pool broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool; A creation module is configured to obtain a subblock set from each local subchain maintained in the local transaction pool, and to create a proposed block based on the obtained subblock set; wherein the proposed block includes a subblock identifier corresponding to each subblock in the subblock set; The transmission module distributes the proposed block to other consensus nodes respectively, so that each consensus node obtains the transaction list contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in its local transaction pool, and performs consensus processing on the obtained transaction list.

36. A consensus node in a blockchain system, comprising a plurality of consensus nodes; the plurality of consensus nodes including an elected master node; each of the plurality of consensus nodes maintaining a local subchain in its local transaction pool; the local subchain comprising a plurality of subblocks created by each consensus node based on transactions stored in the local transaction pool; comprising: The second sending module broadcasts the local sub-chain maintained in the local transaction pool to other consensus nodes; Also, receive the local sub-chains maintained in the local transaction pool broadcast by other consensus nodes, and maintain the received local sub-chains in the local transaction pool; an acquisition module, configured to acquire a proposed block transmitted by the master node; wherein the proposed block is a proposed block created by the master node based on a subblock set obtained from each local subchain maintained in its local transaction pool; and the proposed block includes a subblock identifier corresponding to each subblock in the subblock set; The consensus module obtains the transaction lists contained in each sub-block corresponding to the sub-block identifier from each local sub-chain maintained in the local transaction pool, and performs consensus processing on the obtained transaction lists.

37. An electronic device comprising a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 33 by calling the machine-readable instructions.

38. A machine-readable storage medium storing machine-readable instructions, wherein the machine-readable instructions, when called and executed by a processor, implement the method according to any one of claims 1 to 33.

Images