Blockchain-based multi-partition asynchronous parallel consensus method

Abstract

The present invention relates to the technical field of blockchains, and in particular to a blockchain-based multi-partition asynchronous parallel consensus method. The method comprises: constructing a multi-partition asynchronous parallel consensus blockchain system comprising a plurality of partitions and a plurality of guide nodes; for each partition, each ordinary node publishes and broadcasts transaction information in the partition to which it belongs, and each ordinary node collects and stores the transaction information published in the partition to which it belongs; each partition creates a partition block by executing an intra-partition consensus algorithm, and uses a main node to upload the partition block to a guide node; and each guide node sorts the collected partition blocks, and selects one partition block therefrom to execute an inter-partition consensus algorithm. The present invention enables the synchronous intra-partition consensus initiation and execution provided for in existing sharded blockchain systems to now be performed asynchronously, thus improving system parallelism, transaction information processing throughput, and cross-shard communication processing efficiency.

Description

A multi-partition asynchronous parallel consensus method based on blockchain Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a multi-partition asynchronous parallel consensus method based on blockchain. Background Art

[0002] With the continuous development of blockchain technology, it is being adopted in an increasing number of fields, such as digital currency, finance, and logistics. While blockchain technology offers advantages such as security and decentralization, it also presents three key challenges. The first is scalability: With the widespread adoption of blockchain technology, particularly with the rise of smart contract platforms like Ethereum, the number of transactions has skyrocketed, leading to network congestion and increased transaction fees. Traditional blockchain systems, such as Bitcoin and early Ethereum, have fixed block sizes and intervals, which limit the number of transactions they can process per second. The second is the trade-off between decentralization and performance: To maintain decentralization, traditional blockchain systems sacrifice performance. Every node must verify all transactions on the network, meaning that the throughput of the entire network is limited by the performance of a single node. The third is the issue of growing demand: With the growth of decentralized applications (DApps) and decentralized finance (DeFi) solutions, the demand for higher throughput and faster transaction confirmation times is also increasing. To address these issues, blockchain sharding technology has emerged. By dividing the network into multiple smaller, interconnected areas (called "shards"), each area can process transactions and smart contracts in parallel, significantly increasing the overall network throughput.

[0003] There is an increasing amount of research on blockchain sharding technology. Currently, the research faces the following challenges:

[0004] 1) Cross-shard communication: Sharding technology allows each shard to process transactions independently. However, when users or contracts between two shards need to interact with each other, how to conduct cross-shard communication effectively and securely becomes a critical issue.

[0005] 2) Data availability: When data on a shard is lost or unavailable, it can cause the entire system to fail. Ensuring the continuous availability and synchronization of data across all shards is a key challenge.

[0006] 3) Security: Sharding can lead to reduced security. In traditional blockchains, attackers need to control most of the network's computing power to launch an attack, but in a sharded system, attacking a single shard may only require relatively few resources.

[0007] 4) Flexibility: All shards run the same smart contract code and perform the same functions, but manage different data segments, resulting in insufficient flexibility in real-world application scenarios.

[0008] Summary of the Invention

[0009] To solve the above problems, the present invention provides a multi-partition asynchronous parallel consensus method based on blockchain, which aims to establish a sharded blockchain system to improve system efficiency and scalability while ensuring the efficiency of cross-shard communication, high availability and security of each shard data, and improving the functionality of each shard.

[0010] The specific plan is as follows:

[0011] S1. Build a multi-partition asynchronous parallel consensus blockchain system, which includes multiple partitions and multiple boot nodes. Each partition includes a master node and multiple slave nodes. Both the master node and the slave nodes are ordinary nodes.

[0012] S2. Each ordinary node synchronizes the blockchain and updates its own ledger in real time through the underlying P2P network;

[0013] S3. For each partition, each ordinary node publishes and broadcasts transaction information within its partition, and each ordinary node collects and stores transaction information published within its partition; the transaction information includes global transaction information and local transaction information;

[0014] S4. Each partition generates a partition block by executing the intra-partition consensus algorithm and uses the master node to upload the partition block to the boot node;

[0015] S5. The guide node sorts the collected partition blocks and selects one partition block to execute the inter-partition consensus algorithm;

[0016] S6. Repeat steps S2-S5 to achieve multi-partition asynchronous parallel consensus of the blockchain.

[0017] Furthermore, the master nodes of all partitions and all boot nodes form a block sorting service communication group, and each boot node is connected to the master nodes of all partitions; the boot node is used to provide block sorting services.

[0018] Furthermore, in step S4, the process of any partition executing the intra-partition consensus algorithm to generate a partition block includes:

[0019] S41. Determine whether the amount of transaction information collected by the master node in the partition reaches the expected value. If so, execute step S42; otherwise, continue to collect transaction information and execute step S41;

[0020] S42. The master node sorts all collected transaction information and packages it into a pre-prepared message, which is then broadcast within the partition to which it belongs.

[0021] S43. Each slave node in the partition receives the pre-prepare message and performs two verifications. If the verification passes, a pre-prepare message is broadcast in the partition to which it belongs;

[0022] S44. For each common node in the partition, if the number of prepared messages collected is not less than a preset value, the blocks are packaged and signed according to the transaction information in the prepared messages. Each slave node also generates a commit message based on the signed blocks.

[0023] S45. When the number of submission messages received by the master node in the partition is not less than the preset value, a round of intra-partition consensus is completed. The master node packages the signed block it generated and all submission messages into a partition block and transmits it to the boot node.

[0024] Furthermore, in step S43, any slave node receives the pre-prepare message and performs two verifications, including:

[0025] S431. The slave node verifies whether all transaction information in the pre-prepared message is stored locally. If so, execute step S432. Otherwise, verification fails.

[0026] S432. The slave node verifies whether the order of the transaction information in the prepare message is correct. If so, the verification passes and a prepare message is broadcast in the corresponding partition; otherwise, the verification fails.

[0027] Furthermore, in step S44, when the number of preparation messages collected by any ordinary node is not less than a preset value, the ordinary node processes the transaction information in the order of the transaction information in the pre-prepared message, and packages all processing results into a block for signing, wherein: if global transaction information is encountered, no processing is performed; if local transaction information is encountered, the local transaction information is executed, and the execution result is converted into execution result upload transaction information, and then all global transaction information in the pre-prepared message and all local transaction information execution result upload transaction information are packaged into a block, and finally the ordinary node signs the block.

[0028] Furthermore, step S5 guides the node to select a partition block to execute the inter-partition consensus algorithm, including:

[0029] S51. The bootstrap node selects a partition block as a candidate block and constructs a NextMessage to send to the master nodes of all partitions. The NextMessage includes the candidate block and the height and version number of the last partition block that passed the inter-partition consensus algorithm from the perspective of the current bootstrap node.

[0030] S52. Each master node receives the NextMessage and first extracts the height and version number of the last block in its own blockchain. It then determines whether these match the height and version number of the last partition block that passed the inter-partition consensus algorithm from the perspective of the current bootstrap node. If so, it performs preliminary verification on the candidate block. If the preliminary verification passes, it executes the candidate block, generates an execution receipt, signs it, constructs a SignMessage, and transmits it to the bootstrap node.

[0031] S53. When the number of SignMessages received by the bootstrap node reaches the expected number, it generates a CommitMessage and broadcasts it to all master nodes;

[0032] S54. The master node receives the CommitMessage and writes the candidate block to its own chain, and then sends a DoneMessage to the boot node;

[0033] S55. When the number of DoneMessages received by the bootstrap node reaches the expected number, a round of inter-partition consensus is completed.

[0034] Furthermore, in step S52, preliminary verification of the candidate blocks is performed, including:

[0035] S521. Verify whether the candidate block is complete. If so, execute step S522. If not, the preliminary verification fails.

[0036] S522. Verify whether the number of signatures included in the candidate block meets the expected number. If so, the preliminary verification is successful; otherwise, the preliminary verification fails.

[0037] Furthermore, step S52 executes the candidate block, including: each master node processes all global transaction information and execution result upload transaction information in the candidate block one by one to obtain corresponding processing information, combines all processing information to obtain an execution result, appends the execution result to the candidate block, and then performs a hash operation on the candidate block to obtain a block execution result summary, signs the block execution result summary and constructs a SignMessage; wherein, when the master node processes the execution result upload transaction information, it first determines whether the execution result of the local transaction information involved in the execution result upload transaction information is still valid. If valid, the execution result upload transaction information is retained; if invalid, it is skipped; when the master node processes the global transaction information, the smart contract is used to execute the global transaction information.

[0038] Beneficial effects of the present invention:

[0039] The present invention constructs a multi-partition blockchain system and proposes a two-layer consensus mechanism, which is divided into a lower-layer intra-partition consensus and an upper-layer inter-partition consensus. By decoupling the upper and lower consensus layers, the execution of cross-shard transaction information is reserved for unified processing by the upper-layer inter-shard consensus, so that the consensus within each partition can be initiated and executed asynchronously without waiting for each other; by partitioning the functions of device nodes instead of dividing the data, it is ensured that all nodes in the blockchain system only maintain one set of world states to ensure data availability; all transactions need to go through two layers of consensus, ensuring that transaction information is safe both within and between partitions; and an editing scheme for the inter-partition consensus is proposed to ensure the differentiated implementation of the functions of each partition.

[0040] The present invention improves the consensus initiation and execution within the partitions established by the existing sharded blockchain system from synchronous to asynchronous, thereby improving the system's parallelism, increasing the processing throughput of transaction information, increasing the processing efficiency of cross-shard communication, improving data availability, improving the security of the partitioned blockchain system, and enhancing the flexibility of each partition's functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a diagram of the blockchain system architecture and workflow of the multi-partition asynchronous parallel consensus of the present invention;

[0042] FIG2 is a flowchart of the operation of the asynchronous parallel consensus algorithm within a partition of the present invention;

[0043] FIG3 is a flow chart of the inter-partition consensus operation of the present invention. DETAILED DESCRIPTION

[0044] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0045] The present invention provides a multi-partition asynchronous parallel consensus method based on blockchain, as shown in FIG1 , comprising the following steps:

[0046] S1. Build a multi-partition asynchronous parallel consensus blockchain system, which includes multiple partitions and multiple boot nodes. Each partition includes a master node and multiple slave nodes. Both the master node and the slave nodes are ordinary nodes.

[0047] Specifically, when constructing a multi-partition asynchronous parallel consensus blockchain system, this embodiment uses ordinary nodes participating in the blockchain consensus and boot nodes that help build the blockchain system P2P peer network; all ordinary nodes are divided according to functional characteristics, and ordinary nodes with similar functional characteristics are divided into the same partition, and finally multiple partitions are obtained; each partition selects an ordinary node as the master node, and the remaining ordinary nodes are used as slave nodes; the master nodes of all partitions and all boot nodes form a block sorting service communication group, and each boot node is connected to the master nodes of all partitions; the boot node is used to provide block sorting services.

[0048] S2. Each ordinary node synchronizes the blockchain and updates its own ledger in real time through the underlying P2P network.

[0049] S3. For each partition, each ordinary node publishes and broadcasts transaction information within its partition, and each ordinary node collects and stores the transaction information published within its partition; the transaction information includes global transaction information and local transaction information.

[0050] Specifically, each ordinary node will first store the transaction information it wants to publish, and then broadcast it.

[0051] Specifically, global transaction information is transaction information that requires voting by all partitions to be executed, while local transaction information is transaction information that can be executed by voting by only one partition.

[0052] S4. Each partition generates a partition block by executing the intra-partition consensus algorithm and uses the master node to upload the partition block to the boot node.

[0053] Specifically, the master node in each partition will follow the PBFT distributed consensus protocol. In step S4, any partition executes the intra-partition consensus algorithm to generate partition blocks, as shown in Figure 2, including:

[0054] S41. Determine whether the amount of transaction information collected by the master node in the partition reaches the expected value. If so, execute step S42; otherwise, continue to collect transaction information and execute step S41;

[0055] S42. The master node sorts all collected transaction information and packages it into a pre-prepare message, which it then broadcasts within its partition.

[0056] S43. Each slave node in the partition receives the prepare message and performs two verifications. If the verification passes, a prepare message is broadcast in the partition to which it belongs.

[0057] Specifically, in step S43, any slave node receives the pre-prepare message and performs two verifications, including:

[0058] S431. The slave node verifies whether all transaction information in the pre-prepared message is stored locally. If so, execute step S432. Otherwise, verification fails.

[0059] S432. The slave node verifies whether the order of the transaction information in the prepare message is correct. If so, the verification passes and a prepare message is broadcast in the corresponding partition; otherwise, the verification fails.

[0060] S44. For each slave node in the partition, if the number of prepare messages it has collected is not less than a preset value, it packages and signs the blocks according to the order of the transaction information in the prepare messages, and then generates a commit message based on the signed blocks. For the master node in the partition, if the number of prepare messages it has collected is not less than a preset value, it packages and signs the blocks according to the order of the transaction information in the prepare messages.

[0061] In this embodiment, assuming that the number of ordinary nodes in a partition is 3f+1, the preset value is 2f; where f refers to the maximum tolerated Byzantine node (malicious node) in the system. Since the consensus in the lower-level partition follows the PBFT distributed consensus protocol, the calculation method of f in PBFT is 3f+1=Z, where Z is the total number of nodes.

[0062] Specifically, in step S44, when the number of prepare messages collected by any ordinary node is not less than a preset value, the ordinary node processes the transaction information in the order of the transaction information in the pre-prepare message, and packages all processing results into a block for signing, wherein: if global transaction information is encountered, no processing is performed; if local transaction information is encountered, the local transaction information is executed, and the execution result is converted into execution result upload transaction information, and then all global transaction information in the pre-prepare message and the execution result upload transaction information of all local transaction information are packaged into a block; the ordinary node performs a hash operation on the block to obtain a block ID, and signs the block ID; each slave node also generates submission information based on the block with the signature.

[0063] S45. When the number of commit messages received by the master node in the partition is no less than a preset value, a round of intra-partition consensus is completed. The master node packages the signed block it generated and all commit messages into a partition block and transmits it to the bootstrap node. Specifically, the commit message includes the block ID and the associated signature. When the number of commit messages received by the master node in the partition for the same block ID is no less than a preset value, the intra-partition consensus round is completed.

[0064] In steps S44 and S45, if the slave node or master node does not collect enough prepare messages or commit messages within the set time, the slave node or master node abandons the consensus round and returns to the initial state.

[0065] Once a round of intra-partition consensus algorithm is completed, the master node can immediately initiate a new round of intra-partition consensus without having to wait for the previous partition block to complete the upper-level inter-partition consensus, thus realizing multi-partition asynchronous parallel consensus.

[0066] Specifically, the partitioned blocks generated by the partition are uploaded by the master node to the upper-level block ordering service communication group. Specifically, they are transmitted to the currently incumbent boot node (the node providing the block ordering service). After the incumbent boot node accepts the partitioned blocks, it will synchronize them with other boot nodes, so that if the current incumbent boot node crashes, a new boot node can be elected to continue providing block ordering services.

[0067] S5. The guide node sorts the collected partition blocks and selects a partition block to execute the inter-partition consensus algorithm.

[0068] Specifically, step S5 guides the node to select a partition block to execute the inter-partition consensus algorithm, as shown in Figure 3, including:

[0069] S51. The bootstrap node selects a partition block as a candidate block and constructs a NextMessage to send to the master nodes of all partitions. The NextMessage includes the candidate block and the height and version number of the last partition block that passed the inter-partition consensus algorithm from the perspective of the current bootstrap node.

[0070] In this embodiment, the algorithm for selecting partition blocks by the boot node is based on partition rotation and intra-partition FIFO. Specifically, the boot node rotates and selects a partition block from each partition as a candidate block for inter-partition consensus. When the boot node rotates to the current partition, if there are no partition blocks that have not yet reached inter-partition consensus, it skips that partition and moves to the next partition. If the number of partition blocks in the next partition that have reached inter-partition consensus is greater than or equal to 1, a partition block is selected as a candidate block according to the FIFO (first in, first out) strategy, and then inter-partition consensus is performed on this candidate block. After the inter-partition consensus of the candidate block is completed, it moves to the next partition of the next partition to select a candidate block.

[0071] Specifically, the version number of a partition block refers to the ID of the partition block.

[0072] S52. Each master node receives the NextMessage and first extracts the height and version number of the last block in its own blockchain. It then determines whether these match the height and version number of the previous partition block that passed the inter-partition consensus algorithm from the perspective of the current boot node. If so, it performs preliminary verification on the candidate block. If the preliminary verification passes, it executes the candidate block, generates an execution receipt, and constructs a signed SignMessage to transmit to the boot node. If the preliminary verification fails, it enters recovery mode, determines whether the error is in the current master node or the boot node, and restarts the node or performs manual recovery based on the error. If not, it enters recovery mode.

[0073] Specifically, the preliminary verification of the candidate blocks in step S52 includes:

[0074] S521. Verify whether the candidate block is complete. If so, execute step S522. If not, the preliminary verification fails.

[0075] S522. Verify whether the candidate block has passed the consensus in the lower partition, that is, whether the number of signatures contained in the candidate block is sufficient (whether it meets the expectation). If so, the preliminary verification is successful; if not, the preliminary verification fails.

[0076] Specifically, executing the candidate blocks in step S52 includes:

[0077] Each master node processes all global transaction information and execution result upload transaction information in the candidate block one by one to obtain corresponding processing information, combines all processing information to obtain the execution result, appends the execution result to the candidate block, and then performs a hash operation on the candidate block to obtain a block execution result summary, signs the block execution result summary and constructs SignMessage; among them, when the master node processes the execution result upload transaction information, it first determines whether the execution result of the local transaction information involved in the execution result upload transaction information is still valid. If valid, the execution result upload transaction information is retained; if invalid, it is skipped; when the master node processes global transaction information, it uses smart contracts to execute global transaction information.

[0078] S53. When the number of SignMessages received by the bootstrap node reaches the expected number, it generates a CommitMessage and broadcasts it to all master nodes;

[0079] S54. The master node receives the CommitMessage and writes the candidate block to its own chain, and then sends a DoneMessage to the boot node;

[0080] S55. When the number of DoneMessages received by the bootstrap node reaches the expected number, a round of inter-partition consensus is completed and the next round of inter-partition consensus begins.

[0081] S6. Repeat steps S2-S5 to achieve multi-partition asynchronous parallel consensus of the blockchain.

[0082] In the present invention, unless otherwise clearly stipulated and limited, the terms "installation", "setting", "connection", "fixation", "rotation" and the like should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal connection of two elements or the interaction relationship between two elements. Unless otherwise clearly defined, ordinary technicians in this field can understand the specific meanings of the above terms in the present invention according to the specific circumstances.

[0083] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A multi-partition asynchronous parallel consensus method based on blockchain, characterized in that Including the following steps: S1. Construct a multi-partition asynchronous parallel consensus blockchain system, which includes multiple partitions and multiple bootstrap nodes. Each partition includes a primary node and multiple secondary nodes, and both the primary node and the secondary nodes are ordinary nodes; S2. Each ordinary node synchronizes the blockchain in real time through the underlying P2P network and updates its own ledger; S3. For each partition, each ordinary node publishes and broadcasts transaction information within the partition it belongs to, and each ordinary node collects and stores the transaction information published within the partition it belongs to; the transaction information includes global transaction information and local transaction information; S4. Each partition generates a partition block by executing the consensus algorithm within the partition, and uses the primary node to upload the partition block to the bootstrap node; S5. The bootstrap node sorts the collected partition blocks and selects one partition block to execute the cross-partition consensus algorithm; S6. Repeat steps S2 - S5 to achieve multi-partition asynchronous parallel consensus of the blockchain.

2. The multi-partition asynchronous parallel consensus method based on blockchain according to claim 1, wherein The primary nodes of all partitions and all bootstrap nodes form a block sorting service communication group, and each bootstrap node is connected to the primary nodes of all partitions; the bootstrap node is used to provide the block sorting service.

3. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 1, characterized in that The process of any partition in step S4 generating a partition block by executing the consensus algorithm within the partition includes: S41. Judge whether the number of transaction information collected by the primary node in the partition reaches the expected value. If so, execute step S42; otherwise, continue to collect transaction information and execute step S41; S42. The primary node sorts all the collected transaction information and packs it into a pre-prepared message, and broadcasts the pre-prepared message within the partition it belongs to; S43. Each secondary node in the partition receives the pre-prepared message and conducts two verifications. If the verification passes, it broadcasts a prepared message within the partition it belongs to; S44. For each ordinary node in the partition, if the number of prepared messages it collects is not less than the preset value, it packs the blocks in the order of the transaction information in the pre-prepared message and signs them; each secondary node also generates a submission message according to the signed block; S45. When the number of submission messages received by the primary node in the partition is not less than the preset value, one round of consensus within the partition is completed. The primary node packs the signed block generated by itself and all the submission messages into a partition block and passes it to the bootstrap node.

4. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 3, characterized in that The process of any secondary node in step S43 receiving the pre-prepared message and conducting two verifications includes: S431. The secondary node verifies whether all the transaction information in the pre-prepared message is stored locally. If so, execute step S432; otherwise, the verification fails; S432. The secondary node verifies whether the order of the transaction information in the pre-prepared message is correct. If so, the verification passes, and it broadcasts a prepared message within the partition it belongs to; otherwise, the verification fails.

5. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 3, characterized in that, In step S44, when the number of prepared messages collected by any ordinary node is not less than a preset value, the ordinary node processes the transaction information in sequence according to the transaction information order in the pre-prepared message, and packages all the processing results into a block for signature, where: if a global transaction information is encountered, it is not processed; if a local transaction information is encountered, the local transaction information is executed, and the execution result is converted into an execution result upload transaction information, and then all the global transaction information in the pre-prepared message and the execution result upload transaction information of all local transaction information are packaged into a block, and finally the ordinary node signs the block.

6. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 1, characterized in that, In step S5, the leading node selects a partition block to execute the inter-partition consensus algorithm, including: S51. The leading node selects a partition block as the candidate block and constructs a NextMessage to send to the primary nodes of all partitions. The NextMessage includes the candidate block, the height and version number of the previous partition block that passed the inter-partition consensus algorithm from the perspective of the current leading node; S52. Each primary node receives the NextMessage, first extracts the height and version number of the last block in its own blockchain, and judges whether it is consistent with the height and version number of the previous partition block that passed the inter-partition consensus algorithm from the perspective of the current leading node. If so, it conducts a preliminary verification on the candidate block. If the preliminary verification passes, it executes the candidate block, then generates an execution receipt and signs it to construct a SignMessage to transmit to the leading node; S53. When the number of SignMessages received by the leading node reaches the expected number, it generates a CommitMessage and broadcasts it to all primary nodes; S54. The primary node receives the CommitMessage and writes the candidate block to its own blockchain, and then sends a DoneMessage to the leading node; S55. When the number of DoneMessages received by the leading node reaches the expected number, one round of inter-partition consensus is completed.

7. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 6, characterized in that In step S52, the preliminary verification of the candidate block includes: S521. Verify whether the candidate block is complete. If so, execute step S522. If not, the preliminary verification fails; S522. Verify whether the number of signatures contained in the candidate block reaches the expectation. If so, the preliminary verification is successful. If not, the preliminary verification fails.

8. A multi-partition asynchronous parallel consensus method based on blockchain according to claim 6, characterized in that, In step S52, the execution of the candidate block includes: Each primary node processes all the global transaction information and the execution result upload transaction information in the candidate block one by one to obtain corresponding processing information, combines all the processing information to obtain an execution result, appends the execution result to the candidate block, then performs a hashing operation on the candidate block to obtain a block execution result summary, signs the block execution result summary and constructs a SignMessage; among them, when the primary node processes the execution result upload transaction information, it first judges whether the execution result of the local transaction information involved in the execution result upload transaction information is still valid. If it is valid, the execution result upload transaction information is retained. If it is invalid, it is skipped; when the primary node processes the global transaction information, it uses a smart contract to execute the global transaction information.

Images