A pre-transmission method of transaction data, a blockchain system and a consensus node

Abstract

The embodiment of the specification provides a transaction data pre-transmission method, a block chain system and a consensus node, including: creating a local sub-chain based on transactions stored in a local transaction pool; wherein the local sub-chain includes a plurality of sub-blocks for generating a proposal block, which are created based on transactions stored in the local transaction pool; based on an erasure code algorithm, each sub-block in the local sub-chain is respectively divided into a specified number of data shards, and the specified number of data shards are respectively unicast to each other consensus node, so that each other consensus node performs legality verification on the received data shard, and in response to the legality verification passing, continues to broadcast the data shard to each other consensus node, and each other consensus node performs data recovery on the received data shard to obtain each sub-block.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for pre-transmission of transaction data, a blockchain system, and a consensus node. Background Technology

[0002] Blockchain is a decentralized, trustless distributed ledger. Blockchain technology features multi-party writing, transparency, and immutability. Based on different access control mechanisms, blockchains can be categorized into public blockchains, consortium blockchains, and private blockchains. Consortium blockchains have access control functions; only authorized nodes can join the network, making them often more secure and efficient than public blockchains. They are primarily used for collaboration between enterprises or institutions.

[0003] Consortium blockchains, built on blockchain technology and composed of authoritative nodes, help break down data silos, establish trusted records among consortium members, ensure the immutability of data on the chain, and enable cross-regional and cross-departmental cooperation.

[0004] One metric for measuring blockchain performance is TPS (Transactions Per Second). A higher TPS means faster transactions are executed, verified, and confirmed on the blockchain. Early public blockchains generally had low TPS, far from meeting the needs. While consortium blockchains generally have significantly higher TPS than public blockchains, they are still significantly lower than centralized transaction systems, especially highly decentralized consortium blockchains. Clearly, blockchain performance is a bottleneck hindering the large-scale adoption of blockchain technology.

[0005] TPS (Transactions Per Second) is determined by two factors: the number of transactions in each block and the speed at which the entire system publishes blocks. The more transactions in each block and the faster the block generation speed, the higher the TPS. However, these two parameters cannot be arbitrarily increased. Larger blocks take longer to propagate across the network. If the block interval is too short, insufficient for the vast majority of nodes in the system to receive newly published blocks, the security of the blockchain will be compromised. For public blockchains using PoW consensus protocols, this can lead to forks, potentially causing some transactions to be rolled back. Consortium blockchains, because they can control the identity and number of nodes participating in consensus, can use traditional distributed consensus protocols to generate blocks. Typically, consortium blockchains have significantly fewer consensus nodes than public blockchains, and their node bandwidth is generally better, resulting in a much higher TPS. However, as the block size increases in a consortium blockchain, the transmission latency also increases. For consortium blockchain networks with a large number of nodes (such as hundreds or even thousands of nodes), the block size will lead to longer transaction execution times, and the time for verifying signatures in the consensus protocol will also increase. At the same time, the dramatic increase in messages sent between nodes will also cause network congestion, further increasing the block transmission time, reducing the efficiency of reaching consensus, and also affecting the time of the next block.

[0006] It is evident that the efficiency of reaching consensus on blocks, whether in public or consortium blockchains, significantly impacts the TPS (transactions per second) of the blockchain system. Therefore, improving the efficiency of reaching consensus on blocks is of paramount importance for enhancing the performance of the blockchain system. Summary of the Invention

[0007] This specification proposes a method for pre-transmission of transaction data, which is applied to any target consensus node among multiple consensus nodes participating in the consensus process in the blockchain system; including:

[0008] A local subchain is created based on transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks;

[0009] Based on the erasure coding algorithm, each sub-block in the local sub-chain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes. The other consensus nodes verify the legality of the received data fragments, and in response to the successful legality verification, they continue to broadcast the data fragments to the other consensus nodes. The other consensus nodes then recover the data from the received data fragments to obtain the respective sub-blocks.

[0010] The validity verification of the data shard includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, the validity verification of the data shards is determined to be unsuccessful; otherwise, the validity verification of the data shards is determined to be successful.

[0011] This specification also proposes a method for pre-transmission of transaction data, which is applied to any target consensus node among multiple consensus nodes participating in the consensus process in the blockchain system; including:

[0012] The system receives data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing the sub-blocks based on erasure coding algorithms.

[0013] The received data shards are validated for legality. This validation includes verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose previous sub-blocks are different from those linked to in their respective local sub-chains. If so, the validation for the data shards fails; otherwise, the validation for the data shards passes.

[0014] In response to the successful validity verification, the data fragments are broadcast to the other consensus nodes, which then perform data recovery on the received data fragments to obtain the respective sub-blocks.

[0015] This specification also proposes a blockchain system, including:

[0016] The target consensus node creates a local subchain based on transactions stored in its local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks; based on erasure coding algorithm, each sub-block in the local subchain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes.

[0017] Other consensus nodes besides the target consensus node receive the data fragments unicast by the target consensus node; perform validity verification on the received data fragments; wherein, the validity verification of the data fragments includes: verifying whether other data fragments with the same sub-block as the data fragment have been received, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, it is determined that the validity verification of the data fragments has failed; otherwise, it is determined that the validity verification of the data fragments has passed; in response to the validity verification passing, the data fragments are broadcast to the other consensus nodes, and the other consensus nodes perform data recovery on the received data fragments to obtain the respective sub-blocks.

[0018] This specification also proposes a consensus node in a blockchain system, including:

[0019] A creation module creates a local subchain based on transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks;

[0020] The first sending module divides each sub-block in the local sub-chain into a specified number of data fragments based on the erasure coding algorithm, and unicasts the specified number of data fragments to each of the other consensus nodes. This allows the other consensus nodes to verify the validity of the received data fragments. In response to the successful validity verification, the module continues to broadcast the data fragments to the other consensus nodes, who then perform data recovery from the received data fragments to obtain the respective sub-blocks.

[0021] The validity verification of the data shard includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, the validity verification of the data shards is determined to be unsuccessful; otherwise, the validity verification of the data shards is determined to be successful.

[0022] This specification also proposes a consensus node in a blockchain system, including:

[0023] The receiving module receives data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing the sub-blocks based on erasure coding algorithms;

[0024] The verification module performs legality verification on the received data fragments; wherein, the legality verification includes: verifying whether other data fragments have been received that are the same as the sub-blocks corresponding to the data fragments, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains;

[0025] The second sending module, in response to the successful legality verification, continues to broadcast the data fragments to the other consensus nodes, which then perform data recovery on the received data fragments to obtain the respective sub-blocks.

[0026] In the above embodiments, when any consensus node receives a data fragment unicast from another consensus node, it verifies the legitimacy of the data fragment. Only when it determines that it has not received any other data fragments that are identical to the sub-blocks corresponding to the data fragments but whose corresponding sub-blocks are different from the previous sub-blocks linked to in their respective local sub-chains, will it further broadcast the data fragments to other consensus nodes. Therefore, in this way, the propagation of data fragments corresponding to sub-blocks on forks maliciously created by Byzantine nodes on their maintained local sub-chains can be interrupted in a timely manner. This fundamentally prevents Byzantine nodes from maliciously creating forks on their local sub-chains and avoids packaging illegitimate sub-blocks into the proposal block. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating a method for pre-transmitting transaction data according to an exemplary embodiment of this specification;

[0029] 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;

[0030] Figure 3 This is a schematic diagram illustrating a data structure of a sub-block according to an exemplary embodiment of this specification;

[0031] Figure 4 This is a schematic diagram illustrating a fork attack initiated by node1 according to an exemplary embodiment of this specification;

[0032] Figure 5This is a schematic diagram illustrating a data structure corresponding to data fragmentation according to an exemplary embodiment of this specification;

[0033] Figure 6 This is a schematic diagram illustrating a data structure corresponding to a proposed block according to an exemplary embodiment of this specification;

[0034] Figure 7 This is a schematic diagram illustrating the conventional stages of the pbft algorithm according to an exemplary embodiment of this specification;

[0035] Figure 8 This is a schematic diagram illustrating a conventional stage of another pbft algorithm according to an exemplary embodiment of this specification;

[0036] Figure 9 This is a flowchart illustrating another method for pre-transferring transaction data according to an exemplary embodiment of this specification;

[0037] Figure 10 This is a schematic structural diagram of an electronic device according to an exemplary embodiment of this specification;

[0038] Figure 11 This is a block diagram of a consensus node in a blockchain system according to an exemplary embodiment of this specification;

[0039] Figure 12 This is a block diagram of a consensus node in another blockchain system illustrated in this specification according to an exemplary embodiment. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0041] Many blockchains, especially consortium blockchains, commonly employ leader-based consensus protocols with a master node. Typical leader-based consensus protocols include PBFT (Practical Byzantine Fault Tolerance), PAXOS, RAFT (Replicated And Fault Tolerance), HotStuff, and others. Using a leader-based consensus protocol allows a master node to be elected from among the consensus nodes participating in the blockchain system. The master node creates proposal blocks, and the consensus protocol then coordinates the various consensus nodes to ensure they reach a consensus on the proposal blocks created by the master node.

[0042] For leader-based consensus protocols, the data capacity of the proposal block created by the master node during a consensus process determines the throughput of that consensus. As the number of consensus nodes increases, the number of messages sent by these nodes to reach consensus during the entire process becomes directly proportional to the number of nodes.

[0043] To improve consensus efficiency, related technologies tend to reduce message complexity during the consensus process. For example, the Hotstuff consensus protocol, based on the Pbft protocol, reduces the complexity of the consensus protocol from O(n log n). 2 The time complexity is reduced to O(n), which significantly improves the scalability of the consensus algorithm.

[0044] However, in practical applications, the performance of consensus is affected not only by the complexity of messages in the consensus process, but also by the bandwidth load when the master node distributes the created proposal blocks to other consensus nodes.

[0045] Specifically, in a consortium blockchain, consensus is required for a large number of transactions. A typical transaction is 250 bytes in size, and a block is 100 KB in size when it contains 400 transactions.

[0046] Based on the common consensus process of leader-based consensus protocols, after the master node distributes the proposed block to all other consensus nodes, in subsequent consensus phases for that proposed block, the other consensus nodes typically only need to send signature data for that proposed block. Since a signature data entry is usually no more than 100 bytes, it is evident that the bandwidth consumption of the master node distributing the proposed block to all other consensus nodes is hundreds of times greater than that of subsequent consensus phases.

[0047] It is evident that the master node has a greater impact on the overall consensus performance during the proposal block distribution phase. The more transactions contained in the proposal block distributed by the master node, the greater the throughput in a single consensus operation. In practical applications, a master node's bandwidth is limited. The larger the amount of data contained in the proposal block to be distributed in a single consensus operation, the longer it takes for the master node to distribute that proposal block to other nodes, which in turn leads to a longer consensus time for subsequent nodes.

[0048] The above analysis shows that for leader-based consensus protocols, the throughput during a single consensus process is typically 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, while the bandwidth of the other consensus nodes remains idle and is not fully utilized.

[0049] Based on this, some technical solutions address the issue that leader-based consensus protocols fail to fully utilize the bandwidth of consensus nodes by introducing a pre-transmission mechanism into the blockchain system to optimize the stage in the consensus protocol where the master node distributes the proposed blocks.

[0050] In implementation, on the one hand, a local sub-chain can be designed based on the existing blockchain of the blockchain system, and maintained in the local transaction pools of each consensus node. Each consensus node participating in the consensus in the blockchain system creates a local sub-chain consisting of several sub-blocks from the transactions stored in its local transaction pool, and then maintains the local sub-chain in its respective local transaction pool.

[0051] On the other hand, before the master node creates the proposed block, each consensus node can use its idle bandwidth to broadcast the local sub-chain maintained in its local transaction pool to other consensus nodes in advance, 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 their local transaction pools as well.

[0052] When the master node creates a proposal block, its local transaction pool already maintains the local sub-chains maintained by each consensus node. The master node can obtain a set of sub-blocks from these local sub-chains and create the proposal block based on this set. This proposal block may no longer contain the list of transactions awaiting consensus, but only the sub-block identifiers corresponding to each sub-block in the sub-block set.

[0053] After the master node creates the proposal block, it can distribute the proposal block to the other consensus nodes. After receiving the proposal block distributed by the master node, the other consensus nodes can obtain the transaction list contained in each sub-block corresponding to the sub-block identifier from the local sub-chains maintained in their local transaction pools, and then perform consensus processing on the obtained transaction list.

[0054] In the above technical solutions, by introducing a pre-transmission mechanism into the blockchain system and designing a data distribution strategy based on parallel chains, the idle bandwidth of each consensus node other than the master node can be fully utilized during the consensus process when distributing proposal blocks. This reduces the bandwidth consumption when distributing proposal blocks from a linear level to a constant level, thereby significantly improving the throughput of the entire consensus algorithm, reducing block transmission latency, and improving the consensus efficiency when reaching consensus on proposal blocks.

[0055] However, the above technical solutions do not take into account the presence of Byzantine nodes (i.e. malicious nodes) among the consensus nodes. In practical applications, Byzantine nodes among the consensus nodes may maliciously create forks on their local subchains and broadcast the false subblocks on the malicious forks to other consensus nodes, which may then package the aforementioned false subblocks into the proposal block.

[0056] Based on this, this specification proposes a technical solution to further optimize the above-mentioned pretransmission mechanism based on erasure coding technology, so as to avoid Byzantine nodes in each consensus node from maliciously creating forks on their maintained local subchains.

[0057] In implementation, each consensus node can still create a local sub-chain based on the transactions stored in the local transaction pool. When broadcasting the maintained local sub-chain to other consensus nodes based on the above pre-transmission mechanism, the local sub-chain can be divided into a specified number of data fragments based on the erasure coding algorithm, and the specified number of data fragments can be unicast to other consensus nodes.

[0058] After receiving the aforementioned data fragments via unicast, the other consensus nodes can verify the validity of the received data fragments. Specifically, this verification can include: verifying whether other data fragments have been received that correspond to the same sub-block as the data fragment, but whose previous sub-block in their respective local sub-chains is different; if so, the validity verification for the data fragment fails; otherwise, the validity verification for the data fragment passes.

[0059] Once the validity of the aforementioned data fragments is verified, the data fragments can be broadcast to other consensus nodes, which will then recover the data from the received data fragments to obtain the aforementioned sub-blocks.

[0060] In this technical solution, when any consensus node receives a data fragment unicast from another consensus node, it verifies the legitimacy of the data fragment. Only when it determines that it has not received any other data fragments that are identical to the corresponding sub-block but whose corresponding sub-block is different from the previous sub-block linked in its local sub-chain, will it further broadcast the data fragment to other consensus nodes. Therefore, in this way, the propagation of data fragments corresponding to sub-blocks of forks maliciously created by Byzantine nodes on their maintained local sub-chains can be interrupted in a timely manner. This fundamentally prevents Byzantine nodes from maliciously creating forks on their local sub-chains and avoids packaging illegitimate sub-blocks into the proposal block.

[0061] Please see Figure 1 , Figure 1 This is a flowchart illustrating a pre-transmission method for transaction data according to an exemplary embodiment of this specification. The method can be applied to any target consensus node among multiple consensus nodes participating in consensus within a blockchain system. The method includes:

[0062] Step 102: Create a local subchain based on the transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on the transactions stored in the local transaction pool for generating proposal blocks;

[0063] The aforementioned blockchain system may specifically include multiple consensus nodes participating in the consensus process. In one embodiment shown, the consensus algorithm used by the blockchain system may specifically be a leader-based consensus algorithm. Accordingly, among the consensus nodes participating in the consensus, there may be a master node elected based on the aforementioned leader-based consensus algorithm.

[0064] Since the possibility of Byzantine nodes among the consensus nodes in the blockchain system needs to be considered, the aforementioned leader-based consensus algorithm can specifically be a leader-based Byzantine consensus algorithm. For example, typical leader-based Byzantine consensus algorithms may include PBFT and HotStuff, among others.

[0065] In this specification, a local subchain can be designed based on the existing blockchain of the blockchain system, and maintained in the local transaction pool of each consensus node.

[0066] Specifically, this local sub-chain can include several sub-blocks created by each consensus node participating in the consensus process within the blockchain system, based on transactions stored in their local transaction pools, to generate the proposed block. This design allows transactions stored in the local transaction pools of each consensus node to be packaged into sub-blocks in an orderly manner.

[0067] 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 the transactions stored in its local transaction pool. This subchain structure is maintained independently by each consensus node within 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.

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

[0069] For example, in one instance, the block formation period could be 1 millisecond. Each consensus node could periodically retrieve a batch of transactions from its local transaction pool every 1 millisecond and package them into a sub-block, thus allowing the transactions stored in the local transaction pool to be packaged into the sub-block in an orderly manner.

[0070] It should be noted that the block formation period of the aforementioned sub-blocks can be flexibly set based on actual needs in practical applications. For example, in one scenario, the transaction list contained in the sub-blocks will eventually be packaged into a proposal block, and the number of transactions that the proposal block can hold is usually an integer multiple of the number of transactions that the sub-blocks can hold. For instance, a proposal block might be packaged by the master node based on N sub-blocks. In this case, the duration of the block formation period corresponding to the aforementioned proposal block can specifically be an integer multiple of the duration of the block formation period corresponding to the aforementioned sub-blocks.

[0071] Once each consensus node creates a sub-block based on the obtained transaction list, it can link the sub-block with the latest sub-block on the local sub-chain maintained in the local transaction pool.

[0072] 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 with the aforementioned latest sub-block. After the linking is completed, the created sub-block will become the latest sub-block on the local sub-chain.

[0073] Step 104: Based on the erasure coding algorithm, each sub-block in the local sub-chain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes, so that the other consensus nodes can verify the legality of the received data fragments. In response to the successful legality verification, the data fragments are broadcast to the other consensus nodes, and the other consensus nodes can recover the data from the received data fragments to obtain the respective sub-blocks.

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

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

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

[0077] For example, see Figure 2 The aforementioned blockchain system contains four consensus participants ( Figure 2 Taking the consensus nodes (nodes 1-4) shown as an example, each consensus node's local transaction pool will form a pool like this. Figure 2 The diagram shows a structured chain-like transaction pool structure consisting of four sub-chains. Figure 2 In this context, Bth_i_j represents the j-th batch (i.e., sub-block) generated by the i-th consensus node. When broadcasting their local sub-chains maintained in their local transaction pools to other consensus nodes, each consensus node can use incremental synchronization to periodically broadcast newly added sub-blocks from its local sub-chain to other consensus nodes. That is, when a new sub-block is added to its local sub-chain in a new block generation cycle, it can promptly broadcast this new sub-block to other consensus nodes. Correspondingly, each consensus node can also receive newly added sub-blocks from other consensus nodes periodically broadcast from their local sub-chains.

[0078] In this way, each consensus node can periodically broadcast newly added sub-blocks to other consensus nodes according to the block formation cycle corresponding to the sub-blocks on its local sub-chain. This avoids the problem of excessive bandwidth consumption caused by synchronizing the entire local sub-chain to other consensus nodes.

[0079] Of course, it should be emphasized that in practical applications, when the blockchain system does not concern itself with bandwidth consumption, it is also possible to broadcast the entire local subchain to other consensus nodes.

[0080] In one embodiment shown, please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating a data format corresponding to a sub-block as shown in this specification.

[0081] like Figure 3 As shown, the data format of the sub-blocks mentioned above can specifically include a Batch header (i.e., sub-block header) and a TX List (transaction list) field. The Batch header can further include the Previous Batch Hash field, Batch Height field, Merkle Root field, Batch Tip List field, and Signature field.

[0082] The Previous Hash field is used to fill in the hash value of the previous sub-block that the sub-block is linked to in its local sub-chain.

[0083] The Batch Height field is used to populate a sub-block identifier that represents the block height of the sub-block within its local subchain. This sub-block identifier can be a global identifier within the blockchain system. For example, as mentioned earlier, the sub-block identifier can be of the form Bth_i_j, representing the j-th batch generated by the i-th consensus node. The value of j represents the block height of this batch within its local subchain.

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

[0085] The Batch Tip List field is used to populate a height list consisting of the block heights of the latest sub-blocks on the local sub-chains corresponding to the various consensus nodes, stored in the local transaction pool at the time the current sub-block is created.

[0086] The Signature field can be used to fill in the signature of the creator of the sub-block for that sub-block. It should be noted that the signature of this sub-block can be a signature for the entire sub-block commit, or it can be a signature for only the sub-block header; this specification does not impose any specific limitations.

[0087] It should be noted that the height list filled in the Batch Tip List field can usually represent the reception progress of the local sub-chains corresponding to other consensus nodes stored locally at the time the sub-block is created.

[0088] For example, please continue to see Figure 2 Assuming Figure 2 When node1 creates the sub-block Bth_1_5, the latest sub-block maintained in the local transaction pool on the local sub-chain corresponding to node2 is Bth_2_5, with a block height of 5; the latest sub-block on the local sub-chain corresponding to node3 is Bth_3_5, also with a block height of 5; and the latest sub-block on the local sub-chain corresponding to node4 is Bth_4_5, also with a block height of 5. In this case, the height list filled in the Batch Tip List field of the data structure of the sub-block Bth_1_5 can be represented as [1:5, 2:5, 3:5, 4:5]. At this point, the height list indicates that when node1 creates Bth_1_5, the latest sub-block maintained in node1's local transaction pool for node1 and its corresponding local sub-chain is updated to Bth_1_5; the latest sub-block maintained in node1's local transaction pool for node2 and its corresponding local sub-chain is updated to Bth_2_5; the latest sub-block maintained in node1's local transaction pool for node3 and its corresponding local sub-chain is updated to Bth_3_5; and the latest sub-block maintained in node1's local transaction pool for node4 and its corresponding local sub-chain is updated to Bth_4_5. It's easy to understand that the height list filled in the Batch Tip List field actually represents the receiving progress of each sub-chain maintained in node1's local transaction pool.

[0089] In practical applications, Byzantine nodes may exist among the consensus nodes in a blockchain system. A Byzantine node might maliciously create a fork on its local subchain and use the pre-transmission mechanism to broadcast erroneous subblocks from this malicious fork to other consensus nodes. For example, please see... Figure 4 Assuming Figure 2If node1, as shown, initiates a fork attack, it may create two separate sub-blocks, Bth_1_3 and Bth_1_2, which are both linked to sub-block Bth_1_2. ′ .

[0090] Therefore, in order to prevent Byzantine nodes from maliciously creating forks on their maintained local subchains, in this specification, when each consensus node uses the aforementioned pretransmission mechanism to pretransmit the local subchain maintained in its local transaction pool to other consensus nodes, it can specifically divide each sub-block in the local subchain into a specified number of data fragments based on the erasure coding algorithm, and then unicast these data fragments to the other consensus nodes respectively.

[0091] In one embodiment shown, when each consensus node divides each sub-block in its local sub-chain into a specified number of data fragments based on the erasure coding algorithm, it can also use incremental synchronization to periodically divide newly added sub-blocks on the local sub-chain into a specified number of data fragments based on the erasure coding algorithm, and then unicast the specified number of data fragments to the other consensus nodes.

[0092] In one example, the specified number can specifically be the total number of consensus nodes participating in the consensus in the blockchain system; in this case, each consensus node can divide the newly added sub-blocks on its local sub-chain into data shards corresponding to the total number of consensus nodes in the blockchain system.

[0093] For example, suppose the total number of consensus nodes participating in a blockchain system is N = 3f + 1, where f represents the maximum number of Byzantine nodes the blockchain system can tolerate. In this case, each consensus node can use erasure coding algorithms to divide newly added sub-blocks on its local sub-chain into 3f + 1 data shards.

[0094] It should be noted that the specific details of dividing the sub-block based on the erasure coding algorithm will not be elaborated in this specification. For example, taking the division of a new sub-block into 2f+1 data fragments as an example, based on the erasure coding algorithm, the new sub-block can usually be divided into 2f+1 equal parts first, and then encoded to obtain the redundant f parts.

[0095] Accordingly, after dividing the new sub-block into data shards corresponding to the total number of consensus nodes in the blockchain system, the data shards can be numbered according to the total number of consensus nodes participating in the consensus in the blockchain system, and then the data shards can be unicasted to the consensus nodes corresponding to their numbers.

[0096] For example, taking a total of N consensus nodes as an example, the N data fragments can be numbered sequentially from 1 to N, and then each numbered data fragment can be unicast to the consensus node corresponding to its number. For instance, data fragment numbered 1 can be unicast to consensus node numbered 1, data fragment numbered 2 can be unicast to consensus node numbered 2, and so on.

[0097] When any consensus node receives a data shard unicast from another consensus node, it can perform a validity verification on the received data shard. This validity verification specifically includes: verifying whether another data shard, which corresponds to the same sub-block as the data shard but whose previous sub-block in its local sub-chain is different, has already been received. If so, the validity verification for that data shard fails; otherwise, the validity verification passes. In other words, the above validity verification is specifically used to verify whether the received data shard unicast by another consensus node corresponds to a sub-block on a fork maliciously created by that other consensus node on its maintained local sub-chain.

[0098] If the validity verification of the received data fragment passes, the consensus node can continue to broadcast the data fragment to other consensus nodes. Conversely, if the validity verification of the received data fragment fails, it indicates that the data fragment may be a data fragment corresponding to a sub-block of a fork maliciously created by another consensus node on its maintained local sub-chain. In this case, the consensus node can stop the further propagation of the data fragment to other consensus nodes, thereby interrupting the propagation process of the malicious data fragment to other consensus nodes.

[0099] It should be noted that the verification items that a consensus node needs to perform when verifying the legitimacy of data fragments received unicast from other consensus nodes typically correspond to the fields contained in the data structure of the aforementioned data fragments. In practical applications, the specific data structure of the aforementioned data fragments can be found in [reference needed]. Figure 3 The data structure of the sub-blocks shown above is designed.

[0100] In one embodiment shown, please refer to Figure 5 , Figure 5 This is a schematic diagram of a data structure corresponding to a data fragmentation as shown in this specification.

[0101] like Figure 5As shown, the data format of the aforementioned sub-blocks can specifically include a slice header (i.e., a data slice header) and a slice data (i.e., slice content) field. The slice header can further include a Signature field, a Previous Hash field, and a slice Height field (i.e., a height field).

[0102] The Signature field is used to fill in the signature of the creator of the sub-block for that data fragment. It should be noted that the signature of this data fragment can be a signature for the entire data fragment submission, or it can be a signature for the fragment content field submission of the data fragment; this specification does not impose any special limitations.

[0103] The Previous Hash field is used to populate the hash value of the previous sub-block that the corresponding sub-block of the data shard is linked to in its local sub-chain.

[0104] The `sliceHeight` field is used to populate a sub-block identifier representing the block height of the corresponding sub-block within its local subchain. This sub-block identifier can be a global identifier within the blockchain system. For example, as mentioned earlier, the sub-block identifier could be of the form `Bth_i_j`, representing the `j`th batch generated by the `i`th consensus node. The value of `j` represents the block height of this batch within its local subchain. Based on the above data slicing data structure, when a consensus node verifies the legitimacy of a received data slicing unicast from other consensus nodes, the verification items it needs to perform may include the following:

[0105] Verification item 1:

[0106] Verify the signature filled in the Signature field of the data shard; if the signature verification passes, proceed to the next verification step; otherwise, determine that the validity verification of the data shard has failed.

[0107] Verification item 2:

[0108] Obtain the target block height represented by the sub-block identifier filled in the height field of the data fragment, and verify whether all data fragments with corresponding block heights less than the target block height have been received; if so, proceed to the next verification step; otherwise, obtain the corresponding data fragments with block heights less than the target block height from the creator of the sub-block.

[0109] By executing verification item 2, it can be ensured that the local transaction pool has stored data fragments with the corresponding block height being less than the target block height mentioned above.

[0110] Verification item 3:

[0111] Verify whether the hash value filled in the Previous Hash field of the data fragment is the same as the hash value filled in the Previous Hash field of the data fragment corresponding to the previous block height of the target block height that has been received; if so, proceed to the next verification step; otherwise, do nothing.

[0112] Verification item 4:

[0113] Verify whether other data fragments with the same block height as the data fragment have been received, but whose hash values ​​in the Previous Hash field are different from those of the data fragment. If so, determine that the validity verification of the data fragment has failed; otherwise, determine that the validity verification of the data fragment has passed.

[0114] By executing verification item 4, it is possible to verify whether the data fragments received by other consensus nodes via unicast are malicious data fragments corresponding to sub-blocks on forks maliciously created by other consensus nodes on their maintained local sub-chains.

[0115] Among them, the verification items 1-3 listed above are optional verification items. In practical applications, when a consensus node verifies the legitimacy of the data fragments received by other consensus nodes via unicast, the verification items to be executed may include one or more of the verification items 1-3 above, in addition to the verification item 4 above.

[0116] It should be noted that when any consensus node unicasts a data fragment obtained by dividing the sub-blocks in its local sub-chain based on the erasure coding algorithm to other consensus nodes, if it receives a data fragment unicast from other consensus nodes, it can also perform the above-mentioned legality verification on the data fragment, and determine whether to continue broadcasting the data fragment to other consensus nodes based on the result of the above legality verification. The specific implementation details will not be elaborated here.

[0117] In this specification, any consensus node can receive data fragments broadcast by other consensus nodes. These received data fragments have all passed the aforementioned validity verification. Then, it can be determined whether the number of data fragments with the same sub-block identifier filled in the slice Height field reaches the erasure coding recovery threshold. For example, assuming the total number of consensus nodes participating in the blockchain system is N = 3f + 1, where f represents the maximum number of Byzantine nodes the blockchain system can tolerate, the erasure coding recovery threshold could specifically be 2f + 1.

[0118] If the number of data fragments whose slice Height field has the same sub-block identifier reaches the erasure coding recovery threshold, then the slice content filled in the slice data field of the data fragments whose slice Height field has the same sub-block identifier can be obtained. Then, data recovery is performed on the obtained slice content to obtain the sub-block corresponding to the aforementioned sub-block identifier. The process of data recovery based on erasure coding technology for the obtained slice content will not be described in detail in this specification.

[0119] After recovering the sub-block corresponding to the aforementioned sub-block identifier, the hash value filled in the Previous Hash field of these data shards can be further filled into the recovered sub-block (for example, it can be filled into the Previous Hash field of the recovered sub-block) to link the recovered sub-block with the previous sub-block corresponding to the hash value on the local sub-chain to which the sub-block belongs, maintained in the local transaction pool.

[0120] It is important to emphasize that in practical applications, the data fragments received by the consensus node from other consensus nodes may include multiple sets of data fragments with the same sub-block identifier filled in the slice Height field. In this case, when the number of data fragments in these multiple sets of data fragments reaches the aforementioned erasure coding recovery threshold, data recovery can be performed separately. Then, the recovered sub-block is linked with the previous sub-block corresponding to the hash value on the local sub-chain to which the sub-block belongs, which is maintained in the local transaction pool. The specific process will not be elaborated here.

[0121] In this specification, by adopting the pre-transmission mechanism described above, each consensus node will receive the local sub-chains maintained in the local transaction pools of all consensus nodes. Ultimately, all the local sub-chains received by each consensus node will form a structured chain transaction pool structure composed of multiple sub-chains.

[0122] In this scenario, when any consensus node is elected as the master node, the master node can obtain a set of sub-blocks to be reached for consensus from each local sub-chain within the chained transaction pool structure maintained in the local transaction pool. Then, it creates a proposal block based on this set of sub-blocks. For example, in implementation, the master node can periodically obtain the set of sub-blocks to be reached for consensus from each local sub-chain maintained in the local transaction pool according to the proposal block formation cycle.

[0123] It should be noted that the specific method by which the master node obtains the set of sub-blocks from the various local sub-chains maintained in the local transaction pool is not specifically limited in this specification.

[0124] In this specification, when the master node obtains the set of sub-blocks from the various local sub-chains maintained in the local transaction pool, it can refer to the height list filled in the latest sub-blocks in each local sub-chain. According to the receiving progress of the local sub-chains corresponding to each consensus node represented by the height list, the master node splits the various local sub-chains maintained in the local transaction pool to determine the set of sub-blocks that need to be added to the proposal block.

[0125] The specific method for splitting the local sub-chains maintained from the local transaction pool according to the reception progress of the local sub-chains corresponding to each consensus node represented by the height list is not specifically limited in this specification. In practical applications, it can be flexibly determined based on the specific scenario.

[0126] In one implementation shown, the master node can use the slowest local subchain in the local transaction pool corresponding to each consensus node as a benchmark, and divide each local subchain by determining the common height of the latest sub-block in these local subchains.

[0127] In this scenario, the master node can first determine the latest sub-block in each local sub-chain maintained in the local transaction pool, and then further obtain the height list filled in the Batch Tip List field of the sub-block header of the latest sub-block in each local sub-chain.

[0128] After obtaining the height list filled in the Batch Tip List field of the latest sub-block in each local sub-chain, the consensus node with the slowest receiving progress among the consensus nodes can be used as a benchmark to further determine the common height between the latest sub-block in each sub-chain maintained in the local transaction pool of the master node and the latest sub-block in each sub-chain maintained in the local transaction pool of other consensus nodes.

[0129] After determining the common height, the master node can use this common height as a split point to obtain a set of sub-blocks from each local sub-chain maintained in the master node's local transaction pool. These sub-blocks have a block height no greater than the common height. The master node then creates a proposal block based on the obtained set of sub-blocks.

[0130] For example, in one instance, please see [link to example]. Figure 2 ,if Figure 2 In this table, node1 is the master node. The master node maintains a local transaction pool containing a list of heights for the latest sub-blocks (i.e., the sub-blocks with the largest block height) on the local sub-chains corresponding to nodes1-4, as shown in Table 1.

[0131] Node number Batch Tips 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]

[0132] Table 1

[0133] It should be explained that in the table above, [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 contains a list of heights. In this list, "1:5" means that the highest height of the sub-blocks on the local sub-chain corresponding to node1 maintained in Node1's local transaction pool is 5; "2:5" means that the highest height of the sub-blocks on the local sub-chain corresponding to node2 maintained in Node1's local transaction pool is 5 (i.e., the local sub-chain corresponding to node2 maintained in Node1's local transaction pool has received its 5th sub-block); "3:5" means that the highest height of the sub-blocks on the local sub-chain corresponding to node3 maintained in Node1's local transaction pool is 5 (i.e., the local sub-chain corresponding to node3 maintained in Node1's local transaction pool has received its 5th sub-block); and "4:5" means that the highest height of the sub-blocks on the local sub-chain corresponding to node4 maintained in Node1's local transaction pool is 5 (i.e., the local sub-chain corresponding to node4 maintained in Node1's local transaction pool has received its 5th sub-block).

[0134] [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, maintained in node1's local transaction pool; [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, maintained in node1's local transaction pool; [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, maintained in node1's local transaction pool. The meanings of these height lists are similar to those of the height lists filled in the Batch Tip List field of the latest sub-block on the local sub-chain corresponding to node1, maintained in node1's local transaction pool, and will not be repeated here.

[0135] Based on the table above, when the master node divides these local subchains by using the common height of the latest sub-blocks in the local subchains corresponding to each consensus node, which is maintained in the local transaction pool, it can specifically use the consensus node with the slowest collection progress for these local subchains as the benchmark to determine the common height of the latest sub-blocks in the local subchains corresponding to each consensus node.

[0136] As shown in the table above, the consensus nodes with the slowest progress in receiving the local sub-chain corresponding to node1 are node3 and node4, both of which have received the 3rd sub-block. At this time, the common height of the local sub-chain corresponding to node1 maintained by node1-node4 in their local transaction pool is 3.

[0137] At this point, 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 proposal block.

[0138] As shown in the table above, the consensus node with the slowest progress in receiving the local sub-chain corresponding to node2 is node4, which has not yet received the 3rd sub-block. At this time, the common height of the local sub-chain corresponding to node2 maintained by node1-node4 in its local transaction pool is 3.

[0139] At this point, 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 proposal block.

[0140] As shown in the table above, the consensus nodes with the slowest progress in receiving the local sub-chain corresponding to node3 are node2 and node4, both of which have received the 4th sub-block. At this time, the common height of the local sub-chain corresponding to node3 maintained by node1-node4 in their local transaction pool is 4.

[0141] At this point, 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 proposal block.

[0142] Referring to the table above, the consensus node with the slowest progress in receiving the local sub-chain corresponding to node4 is node2, which has not yet received the 3rd sub-block. At this time, the common height of the local sub-chain corresponding to node4 maintained by node1-node4 in their local transaction pool is 3.

[0143] At this point, 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 proposal block.

[0144] Based on the table above, the set of sub-blocks 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];

[0145] 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.

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

[0147] In this scenario, after the master node obtains the height list filled in the Batch Tip List field of the latest sub-block in each local sub-chain, it can further determine the N consensus nodes with the largest block height in each local sub-chain maintained in the master node's local transaction pool and the local transaction pools of other consensus nodes (that is, the N consensus nodes with the fastest acceptance progress in each local sub-chain) based on the obtained height list.

[0148] Then, the receiving progress of these N consensus nodes can 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;

[0149] After determining the common height, the master node can use this common height as a split point to obtain a set of sub-blocks from each local sub-chain maintained in the master node's local transaction pool. These sub-blocks have a block height no greater than the common height. The master node then creates a proposal block based on the obtained set of sub-blocks.

[0150] The value of N mentioned above can be the maximum number of fault-tolerant nodes for the consensus algorithm used in the blockchain system. This value of N can be a value less than the total number of consensus nodes in the blockchain system.

[0151] For example, if the consensus algorithm used 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 used 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.

[0152] For example, in another example, still using Figure 2 In this table, node1 is the master node. The master node maintains a local transaction pool containing the height list of the latest sub-blocks (i.e., the sub-blocks with the largest block height) on its local sub-chains corresponding to nodes1-4, as shown in Table 1. Assuming the blockchain system uses the Byzantine consensus algorithm and has 4 consensus nodes, f takes the value 1, and N takes the value 2f + 1 = 3.

[0153] By analogy with the reception progress of nodes 1-4 for each local subchain in Table 1, it can be seen that node 4 has the slowest reception progress for the local subchains corresponding to nodes 1-3. Therefore, excluding node 4 which has the slowest reception progress, the master node can determine the three consensus nodes, including nodes 1-3, as the three consensus nodes with the largest block height of the latest sub-block in each local subchain (that is, the N consensus nodes with the fastest reception progress for each local subchain).

[0154] Furthermore, the master node can further determine the common height between the block heights of the latest sub-blocks on the local sub-chains corresponding to nodes 1-4, maintained in the local transaction pools of nodes 1-3. The specific method for calculating the common height is described previously and will not be repeated here.

[0155] Based on Table 1, the common height among the latest sub-blocks on the local sub-chain corresponding to node1 maintained in the local transaction pools of nodes1-node3 is 3; the common height among the latest sub-blocks on the local sub-chain corresponding to node2 maintained in the local transaction pools of nodes1-node3 is 4; the common height among the latest sub-blocks on the local sub-chain corresponding to node3 maintained in the local transaction pools of nodes1-node3 is 4; and the common height among the latest sub-blocks on the local sub-chain corresponding to node4 maintained in the local transaction pools of nodes1-node3 is 3.

[0156] At this point, 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 to be added to the proposal 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 to be added to the proposal 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 to be added to the proposal 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 to be added to the proposal block.

[0157] Based on Table 1, the set of sub-blocks 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_4, Bth_3_4, Bth_4_3]. For node4, which has the slowest receiving progress, it needs to receive the fourth sub-block (i.e., Bth_2_4) from the local sub-chain corresponding to node2 from other consensus nodes before it can reach final consensus with the other consensus nodes.

[0158] In this specification, when the master node uses the sharding method described in the above embodiments to obtain the set of sub-blocks that need to be added to the proposal block from the various local sub-chains maintained in the local transaction pool, it can create the proposal block based on the set of sub-blocks.

[0159] It should be noted that, due to the pre-transmission mechanism described above used in this specification, the set of sub-blocks to be added to the proposal block, obtained by the master node from the various local sub-chains maintained in the local transaction pool, has been pre-synchronized and stored in the local transaction pools of each consensus node. Therefore, in this specification, the proposal block created by the master node based on the aforementioned sub-block set may contain the sub-block identifiers corresponding to each sub-block in the aforementioned sub-block set, but no longer contains the data structures corresponding to each sub-block in the aforementioned sub-block set. In this way, the proposal block will no longer contain the list of transactions awaiting consensus.

[0160] In one embodiment shown, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating a proposed block data format as shown in this specification.

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

[0162] The Signature field is used to fill in the master node's signature for the proposed block.

[0163] The Batch List field is used to populate the sub-block identifiers corresponding to each sub-block in the set of sub-blocks contained in the proposed block;

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

[0165] In this specification, the master node is configured according to the above... Figure 6After creating the proposal block, the data format allows for its further distribution to other consensus nodes.

[0166] For example, when the master node distributes the proposed block to other consensus nodes, it can broadcast the proposed block to the other consensus nodes based on the proposed block distribution mechanism supported by the consensus protocol adopted by the blockchain system.

[0167] In one example, taking PBFT as an example, as a classic leader-based Byzantine consensus algorithm, the PBFT algorithm flow typically includes two processes: the Normal Case Phase and the View Change Phase. The Normal Case Phase is referred to as the regular phase in the PBFT algorithm flow. Figure 7 This is a flowchart of the Normal Case Phase process. For example... Figure 7 As shown, the Normal Case Phase mainly includes three stages: PRE-PREPARE, PREPARE, and COMMIT. Figure 7 The node shown as number 3 can represent a node that has crashed. Figure 7 (represented by ×).

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

[0169] In this scenario, if the consensus algorithm used by the blockchain system is pbft, when the master node distributes the proposal block to other consensus nodes, it can utilize the proposal block distribution mechanism of the PRE-PREPARE stage supported by pbft. In the PRE-PREPARE stage, the proposal block is broadcast to other consensus nodes along with a PRE-PREPARE message.

[0170] In another example, HotStuff, also a leader-based Byzantine consensus algorithm, differs from PBFT in that its algorithm typically consists of four phases: PREPARE, PRE-COMMIT, COMMIT, and DECIDE. Based on HotStuff's algorithm, the master node usually attaches a proposal block created from the collected transactions sent by clients to a PREPARE message during the PREPARE phase. This PREPARE message is then broadcast to other blockchain nodes to distribute the proposal block to the respective consensus nodes.

[0171] In this scenario, if the consensus algorithm used by the blockchain system is HotStuff, when the master node distributes the proposal block to other consensus nodes, it can utilize the proposal block distribution mechanism of the PREPARE phase supported by HotStuff. In the PREPARE phase, the proposal block is broadcast to other consensus nodes along with a PREPARE message.

[0172] In the above embodiments, by utilizing the proposal block distribution mechanism supported by the consensus protocol adopted by the blockchain system to distribute the proposal block to other consensus nodes, the pre-transmission mechanism described above can be organically combined with the proposal block distribution mechanism supported by the consensus algorithm adopted by the blockchain system.

[0173] Because of the pre-transmission mechanism described above, the proposal block created by the master node no longer needs to contain a list of transactions awaiting consensus. Therefore, organically combining the pre-transmission mechanism described above with the proposal block distribution mechanism supported by the consensus algorithm used by the blockchain system can reduce the data size and bandwidth consumption of messages sent when distributing proposal blocks using the consensus algorithm-supported proposal block distribution mechanism. It is easy to understand that organically combining the pre-transmission mechanism described above with the proposal block distribution mechanism supported by the consensus algorithm used by the blockchain system can effectively optimize the proposal block distribution mechanism supported by the consensus algorithm.

[0174] For example, see Figure 8 Taking pbft as an example of the consensus algorithm used in the aforementioned blockchain system, after organically combining the pretransmission mechanism described above with the proposal block distribution mechanism supported by pbft, the pretransmission mechanism described above can be used as a pretransmission stage before the PRE-PREPARE stage of pbft.

[0175] Because of the aforementioned pre-transfer mechanism, the proposal block created by the master node no longer needs to include the transaction list. Therefore, when the master node attaches the generated proposal block to the PRE-PREPARE message during the PRE-PREPARE phase and broadcasts it to other blockchain nodes, the data size of the PRE-PREPARE message is significantly reduced. For example, normally the PRE-PREPARE message includes a transaction list and a Merkle Root generated based on the transaction list. However, by combining the aforementioned pre-transfer mechanism with the PRE-PREPARE phase supported by PBFT, the PRE-PREPARE message can only carry the Batch List field and the Merkle Root field mentioned above. The size of the content filled in the Batch List field is obviously reduced from a linear level to a constant level relative to the transaction list.

[0176] The significant reduction in the data size of PRE-PREPARE messages will inevitably reduce the bandwidth consumption when exchanging PRE-PREPARE messages, which obviously helps to improve the consensus efficiency of the pbft protocol itself.

[0177] It should be noted that the above explanation only uses the consensus algorithm pbft used in the aforementioned blockchain system as an example. In practical applications, when the blockchain system uses other types of consensus algorithms, the above 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 not be given in this specification.

[0178] After the master node distributes the proposed block to the other consensus nodes, each of the other consensus nodes can obtain the transaction list of each sub-block corresponding to the sub-block identifier filled in the Batch List field of the proposed block from the local sub-chains maintained in its local transaction pool, and then perform consensus processing on the obtained transaction list.

[0179] For example, after the pre-transmission phase of transaction data is completed, the consensus voting phase of the consensus algorithm used by the blockchain system can proceed, where the obtained transaction list is processed through consensus voting. The process of processing the obtained transaction list through consensus voting will not be detailed in this specification.

[0180] The above embodiments describe the pre-transmission method from the perspective of consensus nodes pre-transmitting the local sub-chain maintained in their local transaction pools to other consensus nodes. In the following embodiments, the pre-transmission method will be described from the perspective of consensus nodes receiving the local sub-chains maintained in their local transaction pools pre-transmitted by other consensus nodes.

[0181] Please see Figure 9 , Figure 9 This is a flowchart illustrating a pre-transmission method for transaction data according to an exemplary embodiment of this specification. The method can be applied to any target consensus node among multiple consensus nodes participating in consensus within a blockchain system. The method includes:

[0182] Step 902: Receive data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing the several sub-blocks based on erasure coding algorithms;

[0183] Step 904: Perform a validity verification on the received data shards; wherein, the validity verification of the data shards includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, determine that the validity verification of the data shards fails; otherwise, determine that the validity verification of the data shards passes.

[0184] Step 006: In response to the successful legality verification, the data fragments are broadcast to the other consensus nodes, and the other consensus nodes perform data recovery on the received data fragments to obtain the respective sub-blocks.

[0185] In this embodiment, the specific implementation details of each of the above steps can be found in [reference needed]. Figure 1 The provided embodiments will not be described in detail in this specification.

[0186] Corresponding to the embodiments of the aforementioned methods, this specification also provides embodiments of blockchain systems, consensus nodes, and storage media.

[0187] This specification also provides an embodiment of a blockchain system, which may include multiple consensus nodes; the multiple consensus nodes include a target consensus node as the initiator of pre-transmission, and other consensus nodes besides the target consensus node; wherein:

[0188] The target consensus node creates a local sub-chain based on transactions stored in its local transaction pool; wherein, the local sub-chain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks; based on erasure coding algorithm, each sub-block in the local sub-chain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes.

[0189] The other consensus nodes receive the data fragments unicast by the target consensus node; they perform validity verification on the received data fragments; wherein, the validity verification of the data fragments includes: verifying whether other data fragments have been received that are identical to the sub-blocks corresponding to the data fragments, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, the validity verification of the data fragments is determined to be unsuccessful; otherwise, the validity verification of the data fragments is determined to be successful; in response to the successful validity verification, the data fragments are broadcast to the other consensus nodes, and the other consensus nodes perform data recovery on the received data fragments to obtain the respective sub-blocks.

[0190] Figure 10 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 10 At the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, memory 1008, and non-volatile memory 1010, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 1002 reading the corresponding computer program from the non-volatile memory 1010 into the memory 1008 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 hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0191] like Figure 11 As shown, Figure 11 This specification illustrates a block diagram of a consensus node in a blockchain system according to an exemplary embodiment. This device can be applied to, for example... Figure 10 The electronic device shown implements the technical solution described in this specification. The consensus node 110 includes:

[0192] The creation module 1101 creates a local subchain based on transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks;

[0193] The first sending module 1102, based on the erasure coding algorithm, divides each sub-block in the local sub-chain into a specified number of data fragments, and unicasts each of the specified number of data fragments to other consensus nodes. This allows the other consensus nodes to verify the validity of the received data fragments. Upon successful verification, the module broadcasts the data fragments to other consensus nodes, who then reconstruct the sub-blocks from the received data fragments. The validity verification of the data fragments includes: verifying whether other data fragments have been received that are identical to the sub-blocks corresponding to the data fragments, but whose previous sub-blocks in their respective local sub-chains are different. If so, the validity verification of the data fragments fails; otherwise, the validity verification of the data fragments passes.

[0194] The specific details of each module of the aforementioned device 110 have been described in detail in the previously described method flow, so they will not be repeated here.

[0195] like Figure 12 As shown, Figure 12 This is a block diagram illustrating a consensus node in a blockchain system according to another exemplary embodiment of this specification. This device can also be applied to, for example... Figure 11 The electronic device shown implements the technical solution described in this specification. The consensus node 120 includes:

[0196] The receiving module 1201 receives data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing the sub-blocks based on erasure coding algorithms;

[0197] The verification module 1202 performs a validity verification on the received data fragments. The validity verification of the data fragments includes: verifying whether other data fragments have been received that are identical to the sub-blocks corresponding to the data fragments, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains. If so, the validity verification of the data fragments is determined to be unsuccessful; otherwise, the validity verification of the data fragments is determined to be successful.

[0198] The second sending module 1203, in response to the successful legality verification, continues to broadcast the data fragments to other consensus nodes, and the other consensus nodes perform data recovery on the received data fragments to obtain the various sub-blocks.

[0199] The specific details of each module of the aforementioned device 120 have been described in detail in the previously described method flow, so they will not be repeated here.

[0200] Accordingly, this specification also provides an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement all the steps in the previously described method flow.

[0201] Accordingly, this specification also provides a computer-readable storage medium having executable instructions stored thereon; wherein, when executed by a processor, the instructions implement all the steps in the previously described method flow.

[0202] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

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

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

[0205] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0206] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0207] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0208] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0209] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0210] 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 information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, 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," "in response to a determination," or "when," or "in the event of a determination."

[0211] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of 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 should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for pre-transmission of transaction data, the method being applied to any target consensus node among multiple consensus nodes participating in consensus in a blockchain system; comprising: A local subchain is created based on transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks; Based on the erasure coding algorithm, each sub-block in the local sub-chain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes. The other consensus nodes verify the legality of the received data fragments, and in response to the successful legality verification, they continue to broadcast the data fragments to the other consensus nodes. The other consensus nodes then recover the data from the received data fragments to obtain the respective sub-blocks. The validity verification of the data shard includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, the validity verification of the data shards is determined to be unsuccessful; otherwise, the validity verification of the data shards is determined to be successful.

2. The method as described in claim 1, wherein each sub-block in the local sub-chain is divided into a specified number of data fragments based on the erasure coding algorithm, and the specified number of data fragments are unicasted to the other consensus nodes respectively, comprising: Periodically, based on the erasure coding algorithm, newly added sub-blocks on the local sub-chain are divided into a specified number of data fragments, and the specified number of data fragments are unicast to the other consensus nodes respectively.

3. The method as described in claim 2, wherein the specified quantity is the total number of consensus nodes participating in the consensus in the blockchain system; Divide the specified number of data fragments and unicast them to the other consensus nodes, including: Based on the total number of consensus nodes participating in the consensus in the blockchain system, the data fragments are numbered and then unicasted to the consensus nodes corresponding to their respective numbers.

4. The method of claim 3, further comprising: Receive data fragments unicast from other consensus nodes and perform the aforementioned legality verification on the received data fragments; In response to the successful verification of the validity of the data fragment, the data fragment is broadcast to the other consensus nodes.

5. The method as described in claim 4, wherein the consensus algorithm used in the blockchain system is a leader-based Byzantine consensus algorithm; and the consensus nodes participating in the consensus in the blockchain system include the elected master node.

6. The method as described in claim 5, wherein the data structure corresponding to the data shard includes: Data sharding header, sharding content fields; The fragment content field is used to fill in the fragment content contained in the data fragment; The data fragment header includes: The signature field is used to fill in the signature of the creator of the sub-block on that data fragment; The Previous Hash field is used to populate the hash value of the previous sub-block that the corresponding sub-block of the data shard is linked to in its local sub-chain. The height field is used to populate the sub-block identifier, which represents the block height of the sub-block corresponding to this data shard in its local sub-chain.

7. The method of claim 6, wherein the legality verification of the received data fragments includes: Verify the signature filled in the signature field of the data shard; If the signature verification passes, proceed to the next verification step; otherwise, it is determined that the validity verification of the data fragment has failed. Obtain the target block height represented by the sub-block identifier filled in the height field of the data fragment, and verify whether all data fragments with corresponding block heights less than the target block height have been received; if so, proceed to the next verification step; otherwise, obtain the corresponding data fragments with block heights less than the target block height from the creator of the sub-block. Verify whether the hash value filled in the Previous Hash field of the data fragment is the same as the hash value filled in the Previous Hash field of the data fragment corresponding to the previous block height of the received target block height; if so, proceed to the next verification step. Verify whether other data fragments with the same block height as the data fragment have been received, but whose hash values ​​filled in the Previous Hash field are different from those of the data fragment; If yes, the validity verification of the data shard is determined to be unsuccessful; otherwise, the validity verification of the data shard is determined to be successful.

8. The method of claim 7, wherein the leader-based Byzantine consensus algorithm includes the PBFT consensus algorithm or the HotStuff consensus algorithm.

9. The method as described in claim 6, wherein each of the plurality of consensus nodes maintains a local sub-chain corresponding to the plurality of consensus nodes in its local transaction pool; The method further includes: Receive data fragments broadcast by other consensus nodes; Determine whether the number of data fragments with the same sub-block identifier filled in the height field in the received data fragments has reached the erasure coding recovery threshold. If so, retrieve the fragment content filled in the fragment content field of the data fragments whose height field is filled with the same sub-block identifier as the sub-block identifier, and perform data recovery on the retrieved fragment content to obtain the sub-block corresponding to the sub-block identifier; and, The hash value filled in the Previous Hash field of the data shard is further filled into the recovered sub-block to link the sub-block with the previous sub-block corresponding to the hash value on the local sub-chain to which the sub-block belongs, which is maintained in the local transaction pool.

10. The method of claim 5, wherein if the target consensus node is elected as the master node, the method further comprises: Obtain a set of sub-blocks from each local sub-chain maintained in the local transaction pool, and create a proposal block based on the obtained set of sub-blocks; wherein, the proposal block contains a sub-block identifier corresponding to each sub-block in the set of sub-blocks; The proposed blocks are distributed to the other consensus nodes, so that each consensus node can obtain the transaction list contained in each sub-block corresponding to the sub-block identifier from the local sub-chains maintained in its local transaction pool, and perform consensus processing on the obtained transaction list.

11. The method of claim 10, 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 populate the subblock identifiers of each subblock in the subblock set contained in the proposed block; The Merkle Root field is used to populate the hash value of the root node of the Merkle tree created based on the list of transactions contained in each sub-block in the set of sub-blocks.

12. A method for pre-transmitting transaction data, the method being applied to any target consensus node among multiple consensus nodes participating in consensus in a blockchain system; comprising: The system receives data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing the several sub-blocks based on erasure coding algorithms. The received data shards are validated for legality. This validation includes verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose previous sub-blocks are different from those linked to in their respective local sub-chains. If so, the validation for the data shards fails; otherwise, the validation for the data shards passes. In response to the successful validity verification, the data fragments are broadcast to the other consensus nodes, which then perform data recovery on the received data fragments to obtain the respective sub-blocks.

13. The method as described in claim 12, wherein the consensus algorithm used in the blockchain system is a leader-based Byzantine consensus algorithm; and the consensus nodes participating in the consensus in the blockchain system include the elected master node.

14. The method of claim 13, wherein the data structure corresponding to the data fragment includes: Data sharding header, sharding content fields; The fragment content field is used to fill in the fragment content contained in the data fragment; The data fragment header includes: The signature field is used to fill in the signature of the creator of the sub-block on that data fragment; The Previous Hash field is used to populate the hash value of the previous sub-block that the corresponding sub-block of the data shard is linked to in its local sub-chain. The height field is used to populate the sub-block identifier, which represents the block height of the sub-block corresponding to this data shard in its local sub-chain.

15. The method of claim 14, wherein the legality verification of the received data fragments comprises: Verify the signature filled in the signature field of the data shard; If the signature verification passes, proceed to the next verification step; otherwise, it is determined that the validity verification of the data fragment has failed. Obtain the target block height represented by the sub-block identifier filled in the height field of the data fragment, and verify whether all data fragments with corresponding block heights less than the target block height have been received; if so, proceed to the next verification step; otherwise, obtain the corresponding data fragments with block heights less than the target block height from the creator of the sub-block. Verify whether the hash value filled in the Previous Hash field of the data fragment is the same as the hash value filled in the Previous Hash field of the data fragment corresponding to the previous block height of the received target block height; if so, proceed to the next verification step. Verify whether other data fragments with the same block height as the data fragment have been received, but whose hash values ​​filled in the Previous Hash field are different from those of the data fragment; If yes, the validity verification of the data shard is determined to be unsuccessful; otherwise, the validity verification of the data shard is determined to be successful.

16. The method of claim 15, wherein the leader-based Byzantine consensus algorithm includes the PBFT consensus algorithm or the HotStuff consensus algorithm.

17. The method as described in claim 14, wherein each of the plurality of consensus nodes maintains a local sub-chain corresponding to the plurality of consensus nodes in its local transaction pool; The method further includes: Receive data fragments broadcast by other consensus nodes; Determine whether the number of data fragments with the same sub-block identifier filled in the height field in the received data fragments has reached the erasure coding recovery threshold. If so, retrieve the fragment content filled in the fragment content field of the data fragments whose height field is filled with the same sub-block identifier as the sub-block identifier, and perform data recovery on the retrieved fragment content to obtain the sub-block corresponding to the sub-block identifier; and, The hash value filled in the Previous Hash field of the data shard is further filled into the recovered sub-block to link the sub-block with the previous sub-block corresponding to the hash value on the local sub-chain to which the sub-block belongs, which is maintained in the local transaction pool.

18. The method of claim 13, wherein if the target consensus node is elected as the master node, the method further comprises: Obtain a set of sub-blocks from each local sub-chain maintained in the local transaction pool, and create a proposal block based on the obtained set of sub-blocks; wherein, the proposal block contains a sub-block identifier corresponding to each sub-block in the set of sub-blocks; The proposed blocks are distributed to the other consensus nodes, so that each consensus node can obtain the transaction list contained in each sub-block corresponding to the sub-block identifier from the local sub-chains maintained in its local transaction pool, and perform consensus processing on the obtained transaction list.

19. The method of claim 18, 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 populate the subblock identifiers of each subblock in the subblock set contained in the proposed block; The Merkle Root field is used to populate the hash value of the root node of the Merkle tree created based on the list of transactions contained in each sub-block in the set of sub-blocks.

20. A blockchain system, comprising: The target consensus node creates a local subchain based on transactions stored in its local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks; based on erasure coding algorithm, each sub-block in the local subchain is divided into a specified number of data fragments, and the specified number of data fragments are unicast to each of the other consensus nodes. Other consensus nodes besides the target consensus node receive the data fragments unicast by the target consensus node; perform validity verification on the received data fragments; wherein, the validity verification of the data fragments includes: verifying whether other data fragments with the same sub-block as the data fragment have been received, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, it is determined that the validity verification of the data fragments has failed; otherwise, it is determined that the validity verification of the data fragments has passed; in response to the validity verification passing, the data fragments are broadcast to the other consensus nodes, and the other consensus nodes perform data recovery on the received data fragments to obtain the respective sub-blocks.

21. A consensus node in a blockchain system, comprising: A creation module creates a local subchain based on transactions stored in the local transaction pool; wherein, the local subchain includes several sub-blocks created based on transactions stored in the local transaction pool for generating proposal blocks; The first sending module divides each sub-block in the local sub-chain into a specified number of data fragments based on the erasure coding algorithm, and unicasts the specified number of data fragments to each of the other consensus nodes. This allows the other consensus nodes to verify the validity of the received data fragments. In response to the successful validity verification, the module continues to broadcast the data fragments to the other consensus nodes, who then perform data recovery from the received data fragments to obtain the respective sub-blocks. The validity verification of the data shard includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose corresponding sub-blocks are linked to different previous sub-blocks in their respective local sub-chains; if so, the validity verification of the data shards is determined to be unsuccessful; otherwise, the validity verification of the data shards is determined to be successful.

22. A consensus node in a blockchain system, comprising: The receiving module receives data fragments unicast from other consensus nodes; wherein, the other consensus nodes create local sub-chains based on transactions stored in their local transaction pools; the local sub-chains include several sub-blocks created based on transactions stored in their local transaction pools for generating proposal blocks; the data fragments are data fragments obtained by the other consensus nodes dividing each sub-block based on erasure coding algorithms; The verification module performs legality verification on the received data shards. This verification includes: verifying whether other data shards have been received that are identical to the sub-blocks corresponding to the data shards, but whose previous sub-blocks are different from those linked to in their respective local sub-chains. If so, the legality verification for the data shards fails; otherwise, the legality verification for the data shards passes. The second sending module, in response to the successful legality verification, continues to broadcast the data fragments to the other consensus nodes, which then perform data recovery on the received data fragments to obtain the respective sub-blocks.

23. 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 19 by invoking the machine-readable instructions.

24. A machine-readable storage medium storing machine-readable instructions that, when invoked and executed by a processor, implement the method of any one of claims 1 to 19.

Images