A multi-channel parallel processing method and system for a blockchain network

Abstract

The application belongs to the technical field of blockchains and relates to a multi-channel parallel processing method and system for a blockchain network, which comprises a blockchain node including a plurality of lower-layer channel thread groups, an upper-layer channel thread group UG and a world state management module; each lower-layer channel thread group maintains a local transaction queue and a local state snapshot; the application splits the processing procedure of transactions from access, sorting and execution to verification and submission onto a plurality of channels which are isolated from each other and can cooperate with each other by constructing a plurality of lower-layer channel thread groups and an upper-layer channel thread group in a single node, thereby simultaneously enhancing stage parallelism and execution parallelism at the architecture level and significantly improving the overall throughput of the blockchain system.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology and relates to a multi-channel parallel processing method and system for blockchain networks. Background Technology

[0002] Blockchain, as an immutable distributed ledger technology jointly maintained by multiple parties, has received widespread attention and application in fields such as cryptocurrencies, asset transfer, supply chain finance, government data sharing, and privacy computing.

[0003] Currently, industrial-grade applications generally aim for both high throughput and low latency. On the one hand, in batch-type operations such as settlement, clearing, and auditing, throughput determines the upper limit of processing capacity; on the other hand, in online operations such as order matching, asset transfer, and on-chain interaction, latency affects user experience and system stability. The paper "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" by Androulaki et al. (EuroSys 2018 conference paper) shows that under typical deployment conditions, Fabric can achieve a throughput of over 3500 transactions / second and sub-second confirmation latency. Experimental results from "Performance Evaluation of the Quorum BlockchainPlatform" by Baliga A. et al. (arXiv:1809.03421, 2018) show that Quorum typically achieves thousands of transactions / second on medium-sized clusters with confirmation latency in the second range. “Gorenflo T. et al., “FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second”, International Journal of Network Management, 30(5): e2089, 2020” improved the system throughput to about 20,000 transactions per second based on Fabric through optimization; “Qi J. et al., “BIDL: A High-throughput, Low-latency Permissioned Blockchain Framework for Datacenter Networks”, Proceedings of the 28th ACMSIGOPS Symposium on Operating Systems Principles (SOSP 2021), 18-34, 2021” proposed that BIDL can improve the throughput to about 40,000 transactions per second in some scenarios through parallel workflow. The FISCO BCOS open-source community, the FISCO BCOS 2.0 documentation: Introduction, the official FISCO BCOS online documentation, the FISCO BCOS open-source community, the FISCO BCOS v3 feature overview, and the official FISCO BCOS v3.2.0 documentation all indicate that FISCO BCOS achieves tens of thousands of transactions per second in data center environments, with transaction confirmation latency maintained at the second level.

[0004] Even so, the aforementioned performance metrics still lag behind peak business loads (such as processing demands of tens of thousands of transactions per second or even higher during large-scale promotional events). The fundamental reason is that when transaction pairs experience high contention for shared state or have complex dependencies, conflicts inevitably arise in execution layer concurrency. How to simultaneously improve stage parallelism and execution parallelism without compromising consensus security and global consistency remains a common challenge for current high-performance blockchain systems, especially in consortium blockchains and enterprise-level application scenarios.

[0005] At the architecture level, existing work primarily focuses on improving performance through two paths: stage parallelism and execution parallelism. Stage parallelism is typically achieved through pipelined engineering: breaking down stages such as access, sorting, execution, verification, and submission into overlapping sub-processes, allowing different batches of transactions to be processed at different stages simultaneously. For example, while the sorting service outputs the current block, the execution layer can pre-execute or warm up the next batch of transactions; during the verification / submission of the previous batch of blocks, the sorting layer can perform total order adjudication on the next batch of transactions. FastFabric, in "Gorenflo T. et al., FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second", International Journal of Network Management, 30(5): e2089, 2020, significantly improved node resource utilization without changing execution semantics by optimizing pipeline scheduling and batch processing strategies. BIDL, in "Qi J. et al., BIDL: A High-throughput, Low-latency Permissioned Blockchain Framework for Datacenter Networks", Proceedings of the 28th ACM SIGOPS Symposium on Operating Systems Principles (SOSP 2021), 18-34, 2021, organized sorting, execution, and submission into a high-concurrency pipeline through thread binding and data path reconstruction. The limitation of stage parallelism is that once a certain stage becomes a bottleneck, the overall throughput is limited; at the same time, rigid dependencies between stages introduce bubbles into the pipeline, making it difficult to maintain high saturation in the long term. Common methods for parallel transaction execution include: partitioning transactions across different partitions based on accounts, contracts, or key spaces; applying mutual exclusion or ordered locks to conflicting keys based on read-write sets to allow non-conflicting transactions to execute concurrently; using static analysis to predict read-write sets to reduce runtime conflict detection costs; and combining multi-version concurrency control and snapshot reads to ensure serializability through unified verification during the commit phase. FISCO BCOS employs an intra-block parallel execution model based on a directed acyclic graph (DAG) in the FISCO BCOS open-source community, FISCO BCOS 2.0 documentation (Introduction), FISCO BCOS official online documentation, FISCO BCOS open-source community, FISCO BCOS v3 feature overview, and FISCO BCOS v3.2.0 official documentation. This model automatically constructs transaction dependencies and schedules non-mutually exclusive transactions in parallel within blocks to improve throughput in multi-core environments.However, in real-world business scenarios, transaction read / write sets are often highly dynamic and concentrated on a small number of hot keys. In such cases, cross-partition and cross-batch conflicts frequently occur. If concurrency control is too conservative, the execution parallelism will decrease significantly. If it is too optimistic, the abort and rollback ratio will increase, which will adversely affect both overall throughput and tail latency.

[0006] Optimistic concurrency control is widely used in permissioned blockchains due to its simple design, low intrusion into the execution path, and ease of integration with pipelines. A typical process is as follows: during the execution phase, transactions proceed freely as if no conflicts exist; during the commit phase, the read set version is compared with the current world state. If a version mismatch exists, a conflict is identified, and the transaction is aborted, usually initiated by the client. This mechanism has low implementation costs and is easily integrated with existing chaincode / contract runtimes. However, in high-conflict scenarios, a high abort rate can lead to significant redundant computation and resource waste, and multiple retries can amplify tail latency.

[0007] Based on the above parallelization and conflict handling mechanisms, the limitations of existing technologies can be summarized into the following four points: First, it is difficult to achieve both stage parallelism and execution parallelism simultaneously. When the execution layer needs to wait for global verification and submission results, the pipeline is forced to pause; when the sorting layer needs to wait for feedback from the execution layer, sorting throughput is constrained. Second, conflict handling efficiency is limited. The abort-retry loop of optimistic concurrency control causes processor and I / O resources to be occupied by a large amount of invalid computation under high conflict rates; deterministic scheduling based on dependency graphs consumes additional resources in the process of maintaining graph structure and ensuring conservative ordering, and may suppress potential parallelism. Third, the multi-core processor and storage / network multi-queue capabilities are not fully utilized, resulting in idle computing power and I / O capacity in the system under peak load. Fourth, it is difficult to optimize throughput and latency simultaneously under existing architectures: increasing batch processing size is beneficial to improving throughput, but often brings linearly increasing queuing and confirmation delays; reducing batch size is beneficial to reducing latency, but limits the parallelism and resource utilization of each batch.

[0008] Existing solutions still lack a comprehensive design at the architecture level that can simultaneously enhance phase parallelism and execution parallelism, and achieve low rollback overhead and high resource utilization in conflict handling. Summary of the Invention

[0009] To address the aforementioned problems in the prior art, this invention employs a multi-channel parallel processing method for blockchain networks. The blockchain network includes multiple blockchain nodes, and each blockchain node includes multiple lower-level channel thread groups. One upper-level channel thread group (UG) and a world state management module; each lower-level channel thread group Maintain local transaction queues and local state snapshots;

[0010] At any height t, each lower-level channel thread group Based on the local transaction queue and local state snapshot, local block metadata of height t is constructed in parallel and sent to the upper-layer channel thread group UG; the upper-layer channel thread group UG loads the world state snapshot of height t from the world state management module. World state snapshot based on height t For all lower-level channel thread groups The local block metadata at the same height t is processed to obtain the block at height t, the state advancement information at the new height t+1, and the world state snapshot. Broadcast the block at height t to other nodes in the blockchain network, and take a snapshot of the world state at the new height t+1. Store the information in the world state management module and broadcast the state progress information of the new height t+1 to each lower-level channel thread group. Each lower-level channel thread group Load a world state snapshot at height t+1 from the world state management module. Update the local state snapshot.

[0011] Another aspect of the present invention employs a multi-channel parallel processing system for blockchain networks, deployed on blockchain nodes, comprising:

[0012] The transaction access and routing module receives transactions submitted by clients and distributes them to the local transaction queues of each lower-level channel thread group module.

[0013] The lower-level channel thread group module constructs local block metadata in parallel based on the local transaction queue and local state snapshot, and sends the local block metadata to the upper-level channel thread group UG; after receiving state advancement information, it loads the world state snapshot from the world state management module to update the local state snapshot;

[0014] The upper-level channel thread group module receives local block metadata from all lower-level channel thread groups, processes the local block metadata at the same height of all lower-level channel thread groups to obtain blocks, state progress information and world state snapshots, broadcasts the blocks to other blockchain nodes in the blockchain network, stores the world state snapshots in the world state management module, and broadcasts the state progress information to each lower-level channel thread group.

[0015] The network communication module handles the sending, receiving, and routing of messages between blockchain nodes, between blockchain nodes and clients, and between various modules within a blockchain node.

[0016] Beneficial effects:

[0017] 1. This invention constructs multiple lower-level channel thread groups and one upper-level channel thread group within a single node, splitting the transaction processing from access, sorting, execution to verification and submission onto multiple isolated yet collaborative channels. This achieves parallelism at two levels: firstly, multiple lower-level channel thread groups at the same height execute the sorting and execution of different transaction partitions in parallel from a local perspective; secondly, the lower-level channel thread groups at different heights and the upper-level channel thread groups run in staggered time layers, thereby enhancing both stage parallelism and execution parallelism at the architecture level, significantly improving the overall throughput of the blockchain system.

[0018] 2. This invention performs cross-channel read-write set consistency checks centrally on the upper-layer channel side, localizes most conflicts, reduces interference with the normal execution process of the lower-layer channel, and reduces the number of transaction rollbacks, repeated executions, and client-side end-to-end retries caused by high conflict rates, thereby improving resource utilization and tail latency under high conflict and high hotspot load conditions.

[0019] 3. This invention introduces multiple lower-level channel thread groups within the node, enabling different channels to be bound to different processor cores, memory queues, and network queues, thereby achieving fine-grained utilization of multi-core and multi-queue hardware resources;

[0020] 4. The multi-channel parallel transaction processing method of the present invention can be integrated into the existing system in a method or configuration manner without changing the external interface of the existing blockchain platform or forcibly modifying the underlying consensus protocol, so that the existing platform can obtain higher throughput and better latency performance while maintaining the original security model and programming model. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of a multi-stage transaction workflow provided in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of the node workflow provided in an embodiment of the present invention;

[0023] Figure 3 A schematic diagram of the deployment structure of the multi-channel parallel processing system provided in an embodiment of the present invention in a blockchain network;

[0024] Figure 4 This is a schematic diagram of the internal module composition of a node and the hierarchical structure of the lower / upper channel provided in an embodiment of the present invention;

[0025] Figure 5 A detailed flowchart of the lower-level channel workflow provided in this embodiment of the invention;

[0026] Figure 6 A detailed flowchart of the upper-layer channel workflow provided in this embodiment of the invention;

[0027] Figure 7 The performance comparison chart is provided for embodiments of the present invention. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Example 1:

[0030] In this embodiment, the present invention provides a multi-channel parallel processing system for blockchain networks, preferably applied to consortium blockchains / enterprise-level blockchain platforms. While maintaining the existing consensus protocol and world state storage model, this system introduces a multi-channel hierarchical organizational structure within each blockchain node in the blockchain network. This breaks down the transaction processing from access to final submission into a workflow that alternates between lower and upper-level channels, thereby achieving high throughput and low latency multi-stage parallel processing.

[0031] The system is deployed on a blockchain network, preferably a consortium blockchain or an enterprise-grade blockchain network, such as... Figure 3 As shown, the blockchain network comprises multiple consensus nodes (blockchain nodes). Each consensus node can simultaneously perform consensus, execution, and storage functions, or it can be divided into different roles according to business needs. For example, a sorting node that only performs sorting and consensus functions, an execution node that only performs execution and storage functions, or a full-function node that performs all functions. Clients establish connections with any full-function node or gateway node through a secure communication channel and send transaction requests into the blockchain network.

[0032] like Figure 4 As shown, within a blockchain node, this embodiment restructures the traditional single-path "transaction access—sorting—execution—verification—submission" process into a two-layer structure: the lower layer consists of multiple lower-level channel thread groups. (Lower-level channels), each lower-level channel thread group Maintain a local transaction queue and local state snapshot for parallel processing of some transactions locally; the upper layer consists of an upper-level channel thread group (upper-level channel) for global unified sorting, conflict resolution, and final commit of local results from various lower-level channels. Lower-level channels and upper-level channels interact only through lightweight data structures and do not directly share execution context.

[0033] In terms of module division, each blockchain node includes at least the following functional modules:

[0034] The transaction access and routing module receives transactions submitted by clients, performs identity authentication, basic format verification, and rate limiting, and distributes the transactions to various lower-level channel thread groups according to preset or dynamic strategies. Local transaction queue;

[0035] Multiple lower-level channel thread groups, each containing a sorting submodule, an execution submodule, and a local inspection submodule, are used to perform local sorting of transactions in the local transaction queue, execute on the local state snapshot, and perform inspection within the channel to obtain local block metadata, and send the local block metadata to the upper-level channel thread group; after receiving state advancement information, the local state snapshot is loaded from the world state management module to update the local state snapshot;

[0036] The upper-level channel thread group module contains a cross-channel collection submodule, a global sorting submodule, a global execution submodule, a global inspection submodule, and a commit submodule. It collects local block metadata from various lower-level channel thread groups, performs global sorting, global execution, global inspection, and commit on local block metadata at the same height t, obtaining blocks, state progress information, and a world state snapshot. It then broadcasts the blocks to other blockchain nodes in the blockchain network, stores the world state snapshot in the world state management module, and broadcasts the state progress information to each lower-level channel thread group. ;

[0037] The state storage and world state management module is used to maintain a persistent representation of the blockchain world state, supporting snapshot reading, versioned writing, and fault recovery.

[0038] The network communication module is used for sending, receiving, and routing messages between blockchain nodes, between blockchain nodes and clients, and between various modules within a blockchain node.

[0039] The configuration and monitoring module is used to configure parameters such as the number of lower-level channel thread groups, batch size, and time window, and to collect operating metrics such as CPU utilization, queue length, and throughput.

[0040] This embodiment divides the node's computing resources into several lower-level channel thread groups. Each lower-level channel thread group can be bound to one or a group of processor cores and corresponding memory queues and network queues. The lower-level channel thread group maintains an independent transaction queue and local state snapshot, responsible for local processing of transactions allocated to its channel: Specifically, the lower-level sorting submodule selects a transaction set from the local transaction queue, sorts the selected transaction set based on the channel's internal consensus / sorting logic, and generates a local block; the lower-level execution submodule executes the transactions within the local block sequentially or in multiple threads on the current local state snapshot, generating a candidate execution result summary; the lower-level checking submodule performs a channel-wide consistency check based on the candidate execution result summaries of the local block. After the check passes, the local block and its candidate execution result summaries are packaged into local block metadata and sent to the upper-level channel thread group UG, then enter a waiting state.

[0041] In the upper-layer channel thread group module, this embodiment aggregates and unifies the local block metadata uploaded by all lower-layer channels through a single upper-layer channel. The cross-channel collection submodule collects local block metadata from each lower-layer channel at the same height according to the height or epoch number and inserts it into the collection buffer; the global sorting submodule retrieves local block metadata at the same height from the collection buffer to construct a local block metadata set, and uses the consensus protocol to globally sort the local block metadata set to form a blockchain epoch; the global execution and inspection submodule loads the world state snapshot from the world state management module and, based on the world state snapshot, performs conflict resolution on transactions within the blockchain epoch. For transactions without conflicts, the execution results of the lower-layer channel thread group are directly inherited. For transactions with potential conflicts, they are rolled back, discarded, or re-executed according to a preset strategy to obtain the final confirmed write set; after completing the resolution of all transactions, the submission submodule applies the final confirmed write set to the world state and broadcasts the state progress information to all lower-layer channel thread group modules, and broadcasts the submission result, i.e., the block, to other blockchain nodes.

[0042] Regarding parameterized configuration, this embodiment allows configuring the number of lower-level channels, the batch size and time window of each lower-level channel, and the execution parallelism of upper-level channels based on actual hardware resources and business load characteristics. When it is necessary to improve single-node throughput, the number of lower-level channels can be increased first to improve local parallel execution capabilities; when upper-level channels become new bottlenecks, the number of threads within the execution and inspection submodules of upper-level channels can be increased, or the batch processing strategy can be adjusted to further improve cross-channel adjudication capabilities. In addition, this embodiment can also configure transaction dispatch strategies based on the distribution characteristics of the business key space, mapping transactions with close read-write dependencies to the same or a few lower-level channels as much as possible, thereby reducing the probability of cross-channel conflicts at the architectural level.

[0043] The multi-channel parallel processing system architecture described in this embodiment can be directly adopted as the core execution framework in newly developed blockchain platforms, especially suitable for consortium blockchains / enterprise-level blockchain platforms. It can also be integrated into existing platforms as an intermediate layer or enhancement module. For existing platforms, while maintaining the underlying consensus protocol and contract runtime unchanged, only the organizational structure of lower-level and upper-level channels needs to be introduced within the node, and adaptations made to transaction routing and execution result feedback paths. This achieves the multi-channel parallel processing capability of this invention, thus exhibiting good versatility and engineering feasibility.

[0044] Example 2: Multi-stage transaction workflow

[0045] In this embodiment, the complete lifecycle of the multi-channel parallel transaction processing method of the present invention within the system is described, starting from a single transaction. For example... Figure 1 As shown, the present invention divides the processing of each transaction from entering the system to final submission into seven sequentially connected stages that can overlap across batches. The first three stages are completed in the lower-level channel, and the last four stages are completed in the upper-level channel, forming a seven-stage workflow of "three stages in the lower level + four stages in the upper level".

[0046] Specifically, after a transaction T enters the system, it first undergoes the lower-level sorting stage, the lower-level execution stage, and the lower-level inspection stage in sequence within the lower-level channel, forming local block metadata. Subsequently, as the local block metadata from each lower-level channel at the same height is collected by the upper-level channel, transaction T enters the upper-level sorting stage and is incorporated into the blockchain era of unified sorting across channels. On this basis, transaction T further completes conflict detection and result adjudication in the upper-level execution stage and the upper-level inspection stage, and finally confirms and makes its changes to the world state visible to the outside world in the upper-level submission stage.

[0047] Phase 1: Lower-level sorting phase. When a client sends transaction T to the blockchain network, the transaction access and routing module of a blockchain node receives the transaction, performs basic validity verification, and then, according to a preset allocation strategy, assigns transaction T to the local transaction queue of a target lower-level channel thread group. Within this lower-level channel thread group, the lower-level sorting submodule periodically or trigger-basedly extracts a batch of transactions from the transaction queue. Based on the consensus or lightweight ordering protocol running within this channel, a definite local order is formed for this set of transactions, and it is encapsulated into a local block containing multiple transactions. At this point, transaction T has acquired a local sequential position within this channel, but it has not yet had a visible impact on the global world state.

[0048] Phase Two: Lower-Level Execution Phase. Local blocks are generated during the lower-level sorting phase. Subsequently, the lower-level execution submodule reads the local state snapshot currently maintained by the lower-level channel and executes transaction T and other transactions in the same batch sequentially according to the local order of transactions within the block. During execution, this submodule records the read and write sets of transaction T and generates corresponding execution results, such as balance changes, contract state updates, event logs, etc.; and sets the local block... The local block is constructed by summarizing the read / write sets and execution results of all transactions. The candidate execution result summary is provided. It should be noted that in this embodiment, the lower-level execution stage can be executed sequentially in a single thread, or it can be executed in a multi-threaded or pipelined manner without violating the sequential semantics within the block, so as to fully utilize the processor cores bound to the lower-level channel. Regardless of the specific execution method used, the result generated by transaction T in the lower-level execution stage is only a candidate result and has not yet been globally confirmed.

[0049] Phase 3: Lower-level inspection phase. This involves completing the inspection of local blocks. After execution, the lower-level inspection submodule performs a consistency check within the channel based on the candidate execution result digests. This is achieved through methods such as cross-validating the candidate execution result digests across different threads within the channel and signing and aggregating key metadata to ensure the execution results have not been tampered with and that consistency is achieved within the channel. If the check fails, the transaction set is... Mark as a failure and report an exception; otherwise, the local block... The local block metadata, including the candidate execution result summary, is packaged and sent to the upper-layer channel thread group UG, entering a waiting state. This metadata includes at least: the local block identifier, block height, transaction sequence within the block, candidate execution result summary for each transaction, and necessary authentication information. At this point, transaction T enters the upper-layer channel for processing as a local transaction.

[0050] Phase Four: Upper-Level Sorting Phase. Once the upper-level channel thread group collects local block metadata from all lower-level channel thread groups at a certain height t, the cross-channel collection submodule of the upper-level channel thread group assembles this local block metadata into a local block metadata set and triggers the global sorting process. The upper-level channel's global sorting submodule, based on the consensus protocol, performs a global sort on the local block metadata set, generating the blockchain epoch. In this epoch, the global position of each local block and the global execution order of each transaction are determined. At this point, transaction T has a uniquely determined global order across the entire network, but whether its execution result is adopted still depends on subsequent conflict detection and adjudication.

[0051] Phase 5: Upper-level Execution Phase. After the global sorting phase is completed, the global execution and inspection submodules of the upper-level channel thread group proceed according to the blockchain epoch. The module processes transaction T and other transactions sequentially. For each transaction, the submodule first loads a snapshot of the world state at the current altitude from the world state management module. Get the current confirmed write set W_committed, a snapshot of the world state based on the current altitude. And with the confirmed write set W_committed, perform a consistency check on the read set of transaction T: if the version information of the keys in the read set of transaction T matches the current world state snapshot... If the version of the corresponding key in the currently confirmed write set W_committed is consistent with the current version, and there are no write-write conflicts between the write set and the currently confirmed write set W_committed, then the transaction is considered to have no conflict from a global perspective and can directly inherit the execution result generated in the lower-level execution stage. Otherwise, if an inconsistency is detected between the read / write set and the current global state, it is determined that transaction T has a potential conflict, and transaction T can be rolled back, discarded, or re-executed in the upper-level channel based on the latest state according to the preset transaction control strategy. It should be noted that this embodiment does not limit the specific conflict detection algorithm and re-execution strategy. Conflict control can adopt existing technologies such as optimistic concurrency control, deterministic concurrency control, and multi-version concurrency control.

[0052] Phase Six: Upper-Level Inspection Phase. After completing the blockchain era... After all transactions have been executed and adjudicated, the global inspection submodule of the upper-layer channel performs consistency verification on the changes to the world state in this round. For example, this module can cross-compare key state summaries, generate world state hashes or Merkle roots, and perform signature aggregation among multiple threads within the upper-layer channel to ensure that all upper-layer channel execution threads have a consistent understanding of the state progression in this round. After confirming that there are no contradictions or errors in the changes in this round, the upper-layer channel forms the final commit resolution for this epoch, which clearly marks which transactions have been confirmed and committed, and which transactions have been rejected or need to be retried by the client due to conflicts or other reasons. At this point, transaction T has completed the final adjudication at the global execution and inspection level.

[0053] Phase Seven: Upper-Level Commit Phase. During the Generation Era. After the commit resolution is passed, the commit submodule of the upper-layer channel thread group applies the final confirmed write set to the world state storage module, forming a new world state height. It then broadcasts the blocks and state digests of this height to other nodes in the network according to the blockchain consensus protocol. Simultaneously, the upper-layer channel sends state progress information related to this commit to each lower-layer channel, instructing them to update their local state snapshots and clean up temporary execution data for completed batches. For a transaction T that has been confirmed as committed, the system can generate a receipt on the local node or client side according to the specific protocol, feeding the result back to the initiator. At this point, transaction T has completed the seven-stage processing flow from access to final commit, and the changes to the world state made by the transaction officially take effect.

[0054] It should be noted that although the above seven stages are described in logical order, in the multi-channel parallel processing system of this invention, these seven stages are highly overlapping and executed in parallel across different transactions, different levels, and different batches. For example, when transaction T is performing global conflict detection in the upper-level execution stage, subsequent transactions T' at higher levels can already be received, sorted, and executed in the lower-level sorting and execution stages; similarly, when a batch of transactions is in the upper-level checking and upper-level commit stages, other batches and transactions in other channels are still continuously advancing the lower-level three-stage processing. This cross-stage, cross-batch, and cross-channel time overlap allows the entire system to maximize the use of pipeline parallelism and channel parallelism while maintaining strict global consistency, significantly improving resource utilization and transaction throughput in multi-core, multi-queue hardware environments.

[0055] Through the description of Embodiment 2 above, the multi-stage transaction workflow of the present invention clearly delineates the responsibilities of local sorting and execution, global sorting and execution, and final commit. This allows the lower-level channel to focus on efficiently advancing candidate execution on the local state snapshot, while the upper-level channel focuses on conflict determination and final commit decision from a global perspective. This lays the foundation for a more detailed description of the internal workflow of the lower-level channel and the internal workflow of the upper-level channel in subsequent embodiments.

[0056] Example 3: Node Workflow

[0057] In this embodiment, the operation of the multi-channel parallel processing system of the present invention is described from the perspective of the overall behavior of a single node. For example... Figure 2As shown, this invention sets up multiple lower-level channel thread groups (hereinafter referred to as "LG channels") and one upper-level channel thread group (hereinafter referred to as "UG channels") within each node. Each LG channel and UG channel works in a loop around the block height and epoch number. Unlike the vertical perspective of "a single transaction traversing seven stages" in Embodiment 2, this embodiment focuses on depicting the horizontal perspective of how a node schedules multiple LG channels and a single UG channel to advance collaboratively at each height, thus more intuitively demonstrating the parallel characteristics of this invention on the time axis and height axis.

[0058] like Figure 2 As shown, in this embodiment, nodes use block height as the basic unit of advancement. At height t, each LG channel is responsible for generating and executing local blocks at that height; at height t+1, the UG channel is responsible for cross-channel aggregation and global adjudication of the LG local blocks at height t. Through this staggered arrangement of LG channels working at height t and UG channels working at height t-1 or t, the lower and upper levels can overlap in time: when an LG channel is constructing local blocks for the next height, the UG channel is still performing global sorting and submission of the local results from the previous height; the two operate intertwined on the timeline, rather than waiting sequentially.

[0059] For any lower-level channel thread group within any node This embodiment divides its workflow in the height dimension into four cyclical phases: sorting phase, execution phase, local inspection phase, and status submission phase. These four phases are executed sequentially at each height, and upon completion... This allows the cycle to continue at the next level.

[0060] During the sorting phase, when the world state of a node advances to height t, First, by reading the transactions awaiting processing in the transaction pool of this channel, a batch of transactions is selected as a candidate set according to a preset strategy. Then, The internal sorting submodule, based on Byzantine fault-tolerant consensus or lightweight sorting logic, establishes a local order for these transactions among the nodes participating in this channel and generates a local block containing these transactions. This local block includes metadata such as height t, channel identifier i, and a list of transactions in this batch. For a single-node multi-channel implementation, the sorting can be viewed as a deterministic sorting process local to the node; for a multi-node multi-channel implementation, a simplified consensus protocol can be used to reach agreement among replicas in the channel.

[0061] During the implementation phase, The execution submodule obtains a local state snapshot, according to Each transaction within the local sequence is executed sequentially. During execution, The system obtains the read and write sets for each transaction, as well as the execution results, such as account balance changes, contract storage updates, and event logs. After execution, This generates metadata for an executed partial block, which includes a summary of the original transaction and its candidate execution results. It should be noted that this embodiment allows... Multiple execution threads are allocated internally to accelerate intra-block execution using a pipelined or fine-grained lock control approach, but the externally visible semantics remain that the execution is completed within the local order of this channel.

[0062] During the partial inspection phase, The inspection submodule is responsible for verifying the consistency of candidate result summaries generated during the execution phase within the channel. For example, in a multi-threaded execution scenario, different threads can cross-validate key state summaries; in a multi-replica scenario, each replica can compare the execution results of local blocks and confirm consistency through simple voting or signature aggregation. judge When the execution result has reached a consensus within this channel and there are no internal errors, a local block will be included. The local block metadata of the candidate results summary and authentication information is packaged into an upload message and sent to the upper-level channel thread group corresponding to the UG channel for further processing.

[0063] During the status commit phase, Instead of directly and permanently updating the world state, we await the global decision from the UG channel regarding the era corresponding to height t. Once the UG channel completes its decision on height t and broadcasts the state progression information for the new height t+1 to all LG channels, After receiving this state advancement information, load the world state snapshot at height t+1 from the world state management module. Update the local state snapshot, for example from Switch to Alternatively, it can advance a local snapshot to the next level based on incremental update logs. Meanwhile, Clean up the temporary execution data corresponding to height t to release resources for the sorting and execution phase of the next height t+1. At this point, Having completed a full loop at height t, transactions at height t+1 can be processed based on the updated state snapshot.

[0064] Unlike multiple LG channels, each node has only one upper-level channel thread group (UG) for uniformly sorting, resolving conflicts, and finally committing local blocks from each LG channel from a global perspective. The UG's work also loops according to the height / epoch dimension, with each loop processing all local blocks at a certain height t and advancing the system world state from height t to height t+1.

[0065] During the collection and sorting phase, after each LG channel completes its local execution and local check at height t and sends the corresponding local block metadata to UG, UG's collection submodule is responsible for collecting this metadata according to height and channel identifier. When UG determines that all expected local blocks have been collected at a certain height t, it triggers the global sorting process for that height. UG's global sorting submodule, based on a consensus protocol, reaches a consensus among participating nodes on the total order of the local block set, forming the blockchain epoch corresponding to height t. This era explicitly defines the position of each local block in the global order and indirectly determines the global execution order of each transaction within the era.

[0066] During the global execution and conflict resolution phase, UG's execution and inspection submodules follow the epoch. The UG processes local blocks and their transactions sequentially in a global order. For each transaction, the UG first performs a consistency check on the keys and version information in its read set based on the currently confirmed world state view and the written set, determining whether the transaction has a write-write conflict with previously confirmed transactions. If no conflict is detected, the UG directly inherits the execution result of the corresponding LG channel and applies its effect to the current temporary world state view. If a conflict is detected, the UG processes the transaction according to a preset strategy, deciding whether to still adopt its write set or mark it as invalid. During this process, the UG maintains a temporary state view that progresses with the epoch to support conflict detection for subsequent transactions.

[0067] During the global inspection phase, when UG completes the epoch... After all transactions are executed and adjudicated, the execution and inspection submodule performs an overall consistency check on the state changes at that level. Specifically, this can be done by calculating the state change summary after this round of updates and comparing and aggregating signatures across multiple UG copies to confirm that all copies are consistent with the epoch. The processing results are consistent. If the check passes, UG enters the submission stage; if inconsistencies are found, retrying or fault recovery can be performed according to the consensus protocol, and the height will not be pushed out.

[0068] During the submission and broadcast phase, UG's submission submodule will epoch. The final result is officially written into the world state store, solidifying the temporary state view into the world state corresponding to the new height t+1, and generating the body and header information of the block at that height. Subsequently, UG broadcasts the submission results to other nodes in the network in the form of blocks and state summaries, and sends the new height's state advance message to each LG channel within its node, instructing them to update their local state snapshots, clean up intermediate data for the corresponding height, and begin processing transactions for the next height. Thus, UG completes one cycle at height t.

[0069] It is important to emphasize that in the node-view workflow described in this invention, the LG channel and the UG channel do not operate in a strictly sequential manner, with LG completing all heights first and then UG working, or vice versa. Instead, they overlap and interleave on the time axis, with height as the unit. For example, when UG is processing the epoch of height t... At that time, each LG channel can begin constructing a local block at height t+1 based on the local state snapshot corresponding to height t. And sorting and execution work is carried out; when UG completes the submission of height t and advances the status to height t+1, each LG channel immediately updates the local status snapshot and continues to advance to height t+2.

[0070] Through the above design, this invention achieves parallelism on two levels within the node: firstly, multiple LG channels at the same height execute the sorting and execution of different transaction partitions in parallel from a local perspective; secondly, LG channel loops and UG channel loops at different heights run in staggered time layers, forming a multi-channel parallel processing mode where LG prepares local blocks at the next height and UG adjudicates epochs at the previous height. Compared with the traditional single-path execution architecture, this multi-channel parallel processing method from the node's perspective significantly reduces the idle waiting time between upstream and downstream components, resulting in a significant improvement in the node's resource utilization and overall throughput in multi-core, multi-queue hardware environments.

[0071] Example 4: Detailed Design of Lower-Level Channel Workflow

[0072] In this embodiment, the specific workflow of the lower-level channel in the multi-channel parallel processing system of the present invention is described in detail for a single lower-level channel thread group. The lower-level channel is mainly responsible for locally accessing, partially sorting, partially executing, and partially checking the transactions allocated to it, and then sending the local block carrying the execution result and read / write set to the upper-level channel for unified conflict resolution and final commit. For ease of explanation, please refer to... Figure 5 The flowchart shown is for the lower-level channel workflow.

[0073] Within a node, this embodiment divides the available processor cores and I / O queues into multiple lower-level channel thread groups, each of which... By using thread binding or scheduling strategies to fix the node to run on one or a group of CPU cores, context switching and cache jitter can be reduced. Specifically, during node initialization, the number N of lower-layer channels is pre-configured based on hardware resources and business load, and each lower-layer channel... Maintenance includes: independent transaction queues, local state snapshots, local execution thread pools, and local log buffers. The network communication module receives transactions from clients or other nodes, processes them through the transaction access and routing module, and then dispatches the transactions to the appropriate servers. In the transaction queue, load balancing is achieved for each lower-level channel at the traffic level.

[0074] The assignment can be configured according to different business scenarios. For example, it can be based on the hash value of the account address or contract address modulo the number of lower-level channels to map related transactions of the same account or contract to the same or a few lower-level channels to reduce cross-channel conflicts; or it can be based on the business tenant identifier to map transactions of different tenants to different channels to achieve tenant-level isolation. In this embodiment, the specific form of assignment is not limited, as long as it can deterministically map the input transaction to a certain lower-level channel.

[0075] With any lower passage For example, its workflow at height t can be broken down as follows: Figure 5 Steps S101 to S105 are shown below:

[0076] S101: The system receives transactions assigned to this channel from the transaction access and routing module and inserts them into the local transaction queue according to their arrival order or a specified strategy. In the middle. For transactions that were not completed at the previous level, they can also be prioritized for removal from the queue according to the strategy, so as to reduce the transaction delay time;

[0077] S102: When the triggering condition is met from A set of transactions of height t is selected from the data. This triggers a local sorting at this height;

[0078] Lower-level channel thread group entering the waiting state Triggered by the local transaction queue length or periodic time window, that is, when the number of transactions in the transaction queue reaches a preset threshold or at fixed time windows.

[0079] S103: Set of transactions at height t Sort the transactions in the block to obtain a local block of height t. ;

[0080] For an implementation that simulates multiple channels only within a single node, step S103 can be simplified to... A deterministic sorting function is applied; for multi-replica channel implementations, lightweight protocols such as PBFT or Raft can be used to sort among replicas within the channel. The order was agreed upon. After sorting, a local block was formed with height t, channel number i, transaction sequence, and necessary metadata. .

[0081] S104: Based on local state snapshots, according to local blocks Execution of local blocks in transaction order The transaction yields a local block. The read / write set and execution result for each transaction;

[0082] Local state snapshot This can be achieved using multi-version storage or copy-on-write mechanisms to ensure that a consistent state view at a fixed height is read during execution.

[0083] For each transaction T, the execution submodule reads the required key-value pairs based on a local state snapshot, calculates the business logic, and generates new values ​​or state changes. In implementations that support multi-threaded execution, Non-dependent transactions within a block can be executed in parallel, but it must be ensured that write operations on the same key are logically equivalent to the results of a certain sequential execution. This embodiment does not limit the specific parallel execution strategy.

[0084] During the execution of each transaction T Record the read set R(T) and write set W(T) of the transaction, and generate the execution result Result(T). The read set R(T) includes all key-value pairs read from the local state snapshot during the execution of transaction T, and the write set W(T) includes all key-value pairs to be modified / written during the execution of transaction T. This information will be used for conflict detection and result inheritance in the upper-layer channel.

[0085] S105: Based on local block A local block is constructed from the read / write sets and execution results of all transactions. Summary of candidate execution results;

[0086] According to local blocks A local block is constructed from the read / write sets and execution results of all transactions. The candidate execution result summary includes: The R(T), W(T), and Result(T) information of all transactions within the block are aggregated and hashed to obtain the corresponding candidate execution result digests. The candidate execution result digests include: a digest of each transaction's read / write set, an execution result digest, a log digest, and error information statistics.

[0087] S106: For local blocks A consistency check is performed on the candidate execution result summary. If the check fails, the transaction set is removed. Mark as a failure and report an exception; otherwise, the local block... The candidate execution result summary is packaged into local block metadata of height t. And send it to the upper-level channel thread group UG, and enter the waiting state;

[0088] Consistency checks include: for single-machine multi-threaded implementations, key digests can be compared between different threads, and execution paths can be sampled and replayed to detect whether there are obvious errors; for multi-replica implementations, the execution results of Bᵗᵢ can be compared among multiple replicas within the channel, and consistency can be confirmed through signature aggregation or voting mechanisms.

[0089] It is important to note that at this time Instead of directly modifying the global world state, the candidate execution results are submitted to the UG channel for final adjudication from a global perspective, thus avoiding consistency disruptions caused by unilateral submissions from this channel.

[0090] After the local block metadata of height t is uploaded Entering a waiting state, waiting for the UG channel to complete the global sorting, conflict resolution, and commit for epoch t; when the UG channel broadcasts the commit resolution for epoch t and the status advancement information for the new epoch t+1, Upon receiving this information, load a world state snapshot at height t+1 from the world state management module. Update the local state snapshot (the upcoming world state snapshot at height t+1). Advance as a local state snapshot or based on incremental update logs, and clean up temporary execution data and buffers corresponding to height t. Afterwards, Returning to phase S101, we begin processing transactions at height t+1.

[0091] Lower-level channel thread group entering the waiting state Triggered by local transaction queue length or periodic time window.

[0092] Regarding state management, this embodiment, after completing local execution and local checks at a certain height t, An internally consistent execution result has been achieved, but it has not yet been applied to the global world state. This consistency point is achieved through local blocks and execution summaries. The results are passed between the local and global consistency points and promoted to global consistency points after the UG makes its final commit decision. By managing local and global consistency points in a hierarchical manner, this embodiment ensures the reproducibility of execution results within the lower-level channels while preventing premature modification of the world state before global adjudication, thus balancing execution parallelism and global consistency.

[0093] In summary, this fourth embodiment details the workflow of a single lower-level channel within a node, as well as the parallel scheduling and state management methods for multiple lower-level channels. By encapsulating transaction access, local sorting, local execution, and local consistency checks within multiple lower-level channels and executing them in parallel, this invention can fully utilize multi-core and multi-queue hardware resources to provide batch execution result input for upper-level channels, laying the foundation for efficient operation of global sorting and conflict resolution.

[0094] Example 5: Detailed Design of Upper-Level Channel Workflow

[0095] In this embodiment, the specific workflow of the upper-level channel in the multi-channel parallel processing system of the present invention is described in detail from the perspective of the upper-level channel thread group (UG). The upper-level channel is mainly responsible for collecting and sorting local blocks from each lower-level channel from a global perspective, performing unified transaction conflict detection and result adjudication, and finally committing the status and broadcasting the results. For ease of explanation, please refer to... Figure 6 The flowchart of the upper channel is shown.

[0096] The upper-level channel thread group UG exists within the node as a global coordinator. Its input is a set of local block metadata generated by multiple lower-level channels at a certain height t, and its output is the block at height t and a world state snapshot at the new height t+1. And state progression information. Specifically, the inputs to UG include at least: the identifier of each lower-level channel's local block, its height and channel number, a transaction list, a summary of candidate execution results, and local authentication information; the outputs of UG include at least: the block corresponding to height t (blockchain epoch). (Final rulings for each transaction), a new world state snapshot at t+1. And state advancement information used to advance local state snapshots of lower-level channels.

[0097] To fully utilize multi-core processors, in this embodiment, the UG can consist of multiple threads, each responsible for functional modules such as collection and sorting, execution and conflict detection, and inspection and submission. Each thread shares necessary metadata and intermediate states through thread-safe data structures. The following section will combine... Figure 6 The working steps of the upper-level channel are explained from a process perspective:

[0098] S201: UG's collection submodule continuously listens for messages from all sources in the background. The upload message is processed, and the local block metadata in the upload message is inserted into the collection buffer according to the height t and channel number i.

[0099] S202: The UG scheduling submodule periodically checks whether the collection buffer has collected all lower-level channel thread groups for a certain height t. The local block metadata at height t, or the collection conditions specified in the protocol, have been met when all lower-level channel thread groups have been collected. When the local block metadata of height t is available or the collection conditions are met, height t is marked as "sortable" and the global sorting process for that height is triggered.

[0100] S203: For a height t marked as "sortable", UG retrieves the local block metadata of height t from the collection buffer to construct a local block metadata set. I represents the number of LGs;

[0101] Metadata for each local block It contains the corresponding local block. Information such as the transaction list and candidate execution result summary.

[0102] S204: Utilizing a consensus protocol to process the local block metadata set at height t Perform a global sort to obtain the blockchain epoch of height t. ;

[0103] UG's global sorting submodule is based on The consensus protocol is run to reach an agreement among participating consensus nodes on the block order at that height. Specifically, the metadata of each local block can be... It is regarded as a "logical transaction unit", and a complete sequence is generated by the consensus protocol. After consensus is reached, UG will release the entire sequence of height t. Solidified into the blockchain era This embodiment does not limit the specific form of the consensus protocol; it can employ classic Byzantine fault-tolerant protocols and their improved versions, or other Byzantine fault-tolerant protocols that meet the requirements of security and liveness.

[0104] This era The code explicitly specifies the position of each local block's metadata in the global order and indirectly determines the global execution order of each transaction within an epoch.

[0105] S205: The Execution and Inspection submodule of UG is handling the epoch. Previously, a world state snapshot of height t was loaded from the world state management module. ;

[0106] S206: Based on World State Snapshot According to the blockchain era The order of local block metadata in the blockchain epochs is as follows: Metadata of each local block in By resolving conflicts among multiple copies, the blockchain era is established. The conflict resolution results and confirmed write set at each replica height t; the conflict resolution results include: a list of confirmed transactions, and the execution result of each transaction in the list of confirmed transactions;

[0107] The nodes are deployed redundantly with multiple replicas; different replicas in UG can each handle an epoch. Perform the same conflict resolution process; for any copy, based on a world state snapshot. The Blockchain Era Conflict adjudication includes: according to the blockchain era Metadata of each local block The order and metadata of each local block The order of each transaction determines the blockchain era. The global execution order of each transaction in the blockchain era; according to the blockchain era The global execution order of transactions in the blockchain era is as follows. Each transaction in the process undergoes conflict resolution, resulting in a list of confirmed transactions of height t, the execution result of each transaction in the list of confirmed transactions, and a set of confirmed writes.

[0108] Determining the Blockchain Era The global execution order of each transaction in the process includes: Epoch The metadata for each local block is explicitly provided. In the global order, the metadata of each local block The local block is explicitly given. By determining the position of each transaction within the local sequence, the global execution order of each transaction within an epoch can be determined.

[0109] While ensuring equivalence with serial execution, non-dependent transactions in different blocks or within the same block can also be executed in parallel to make full use of multi-core resources.

[0110] The Blockchain Era Conflict adjudication in transaction T includes:

[0111] UG retrieves the current list of confirmed transactions and the write set W_committed;

[0112] The Blockchain Era When the first transaction T in the process is conflict-resolved, the list of currently confirmed transactions is obtained by initializing an empty set, and the current write set W_committed is read from the world state management module.

[0113] UG extracts the read set R(T) and write set W(T) of transaction T from the candidate execution result summary of the local block metadata to which transaction T belongs;

[0114] Based on the read set R(T) and write set W(T) of transaction T, and the world state snapshot The current confirmed write set W_committed determines whether transaction T has a global conflict. If not, the upper-layer channel thread group UG merges transaction T into the current confirmed transaction list, extracts the execution result Result(T) of transaction T from the candidate execution result summary of the local block metadata of transaction T, and merges the write set W(T) into the current confirmed write set W_committed; otherwise, the upper-layer channel thread group UG adjudicates transaction T according to the preset transaction control strategy.

[0115] Determining whether a transaction T has a global conflict includes: reading the versions of all keys in set R(T) and world state snapshots. If the version of the corresponding key in the currently confirmed write set W_committed is consistent, and the write set W(T) and the currently confirmed write set W_committed do not produce write-write conflicts, then transaction T is considered to have no global conflict; otherwise, transaction T is considered to have a global conflict.

[0116] UG makes decisions on transaction T according to the preset transaction control strategy, including: rolling back and discarding conflicting transactions T, re-executing them, or delaying their processing.

[0117] Rollback and discard: Directly mark transaction T as an invalid transaction, do not merge its write set into the current confirmed write set W_committed, and let the client or upper layer application decide whether to retry;

[0118] Execute at the upper level: View the current world state Based on the currently confirmed write set W_committed, T is re-executed within UG. If the result of the re-execution satisfies the consistency check, the new write set is adopted; otherwise, it is still marked as invalid.

[0119] Marking delayed execution: In some extended implementations, conflicting transactions can be placed in a separate queue for processing in subsequent batches or through a dedicated channel.

[0120] This embodiment does not limit the specific strategy to be chosen, but only requires that the final result is equivalent to a certain serial execution order.

[0121] S207: The Execution and Inspection submodule of UG calculates the state change summary for each copy height t based on the confirmed write set for each copy height t;

[0122] The state change digest for each replica height t is calculated based on the acknowledged write set for each replica. This digest includes: a unique hash value obtained by normalizing and hashing all key-value pairs in the acknowledged write set; the state change digest is used for consistency comparisons among multiple replicas.

[0123] 208. Perform a global consistency check on the state change summary of all replicas at height t. If the check passes, proceed to step S209; otherwise, return to step S205.

[0124] An epoch is considered to have occurred when all replicas reach a consensus on the consistency of the state change summary. The processing results have reached a consensus across the entire network; if any inconsistency is found, a retry, rollback, or fault isolation can be triggered through the consensus protocol to ensure that no incorrect results are submitted.

[0125] S209: After the global check passes, the UG commit submodule generates a world state snapshot at a new height t+1 based on the confirmed write set of any copy height t. Based on the conflict resolution result of any replica at height t, construct a block at height t and generate state advancement information at a new height t+1;

[0126] A block of height t consists of a block header and a block body of height t. The block body includes the epoch. The block contains information such as a list of confirmed transactions and the execution results of each transaction in the list. This block becomes part of the blockchain ledger and can be used for auditing and verification.

[0127] Generate a world state snapshot with a new height t+1 based on the confirmed write set of any copy height t. Includes: applying the confirmed write set to a world state snapshot at height t. A new world state snapshot at height t+1 is obtained. .

[0128] S210: UG broadcasts the block at height t and its state change summary to other blockchain nodes via the network communication module; UG sends the state advancement information at new height t+1 to the lower-level channel thread group within this node. Each lower-level channel thread group Upon receiving this information, each lower-level channel thread group Load a world state snapshot at height t+1 from the world state management module. Update the local state snapshot to obtain the local state snapshot at height t+1. This process also cleans up the temporary execution data corresponding to height t. This process marks the complete end of height t in this node, and simultaneously prepares the lower-level channel thread group. The local sorting and execution at height t+1 provides a new starting state.

[0129] The upper-layer channel workflow described in this embodiment can be decoupled and integrated with the consensus protocol used in existing blockchain platforms. Specifically, the collection and sorting phase of UG can be implemented by adapting to existing sorting service interfaces, such as connecting to existing sorting node clusters or embedded consensus modules; the global execution and conflict detection phase can be regarded as an additional execution layer on top of the sorting results, without requiring modification to the message flow and security assumptions of the consensus protocol itself; the commit and broadcast phase uses the platform's original block broadcast and state synchronization mechanism. The key point of the upper-layer channel design of this invention is: without compromising the security and consistency of the consensus layer, to effectively combine local execution results with global conflict control, and achieve unified adjudication and efficient commit of multi-channel local execution results.

[0130] In summary, this fifth embodiment provides a complete description of the upper-layer channel's collection and sorting, global execution and conflict detection, and global checking and submission processes. By cooperating with the lower-layer channel workflow in the fourth embodiment, this invention establishes a multi-channel parallel processing mode within the node, where multiple lower-layer channels generate candidate results in parallel, while a single upper-layer channel centrally adjudicates and submits the results. This significantly improves transaction throughput and resource utilization efficiency while ensuring blockchain consistency and security.

[0131] Example 6: General performance test based on 4 lower-layer channels

[0132] In this embodiment, based on the architecture and workflow described in Embodiments 1 to 5 above, a general performance testing scheme based on a configuration of 4 lower-level channels is given to verify the throughput and latency performance of the multi-channel parallel processing system of the present invention under a typical blockchain cluster.

[0133] This embodiment employs a cluster environment comprising one client and ten consensus nodes. Each consensus node is equipped with one Intel processor and 64GB of memory, running a Linux (Ubuntu) operating system. The storage backend uses a pluggable solution, with LevelDB chosen as the default state storage engine. Each consensus node is internally configured with four lower-level channel thread groups and one upper-level channel thread group. At their respective levels, threads take turns acting as the leader to trigger the corresponding stage of the classic Byzantine fault-tolerant consensus process.

[0134] The operation process of this embodiment follows the seven-stage workflow described in this invention. This embodiment uses SmallBank load as the benchmark test scenario. The specific steps include: (1) generating SmallBank benchmark load and setting the read transaction ratio Rc to 0.5 to simulate a read-write balanced scenario; (2) running the system under two account sizes of 10,000 and 100,000 respectively, and recording the system throughput (transactions / second) and end-to-end latency (from client submission to confirmation return) under different loads; (3) under the same load conditions, collecting the throughput and latency curves of the multi-channel parallel processing system of this invention and the comparison system for horizontal comparative analysis.

[0135] Experimental results show that, with a configuration of four lower-level channels and a SmallBank load, the system achieves a throughput of approximately 198.93k transactions / second with 10,000 accounts and approximately 171.24k transactions / second with 100,000 accounts. Regarding end-to-end latency, under low load conditions, the latency of the multi-channel parallel processing system of this invention is on the order of 200 milliseconds. As the load increases, the latency growth rate is significantly lower than that of the comparison system, maintaining a smoother growth curve in higher load ranges. This demonstrates that the system can maintain superior latency performance even under high throughput, verifying the adaptability of this invention to high-load scenarios under a multi-channel, seven-stage, two-round consensus structure.

[0136] Example 7: General performance test based on 10 lower-level channels

[0137] In this embodiment, based on Embodiment Six, the number of lower-level channels for each node is increased from 4 to 10, while keeping other conditions basically the same, in order to verify the scalability of the multi-channel parallel processing system of the present invention after increasing the parallelism of the lower-level channels and the performance changes under different loads.

[0138] This embodiment uses the same cluster and hardware environment as Embodiment Six, and the comparison system and baseline load configuration remain consistent with Embodiment Six to ensure comparability in horizontal comparison. The operation flow of this embodiment still follows the multi-channel parallel processing method described in this invention, only the number of lower-level channels is expanded from 4 to 10.

[0139] Performance test results show that, with a configuration of 10 lower-level channels, the multi-channel parallel processing system of this invention achieves a throughput of approximately 313.48k transactions / second under SmallBank load with a scale of 10,000 accounts; and a throughput of approximately 159.40k transactions / second with a scale of 100,000 accounts. Compared with Example 6, the throughput is significantly improved in a medium-sized account scenario as the number of lower-level channels increases, demonstrating the ability of this invention to achieve near-linear scaling at the single-node level by increasing the number of lower-level channels. At larger account scales, the throughput improvement is affected by hotspot key distribution and conflict rate, but overall it still remains higher than the comparison system.

[0140] In terms of latency, since this invention adopts a seven-stage workflow and a two-round PBFT consensus structure, the initial end-to-end latency is slightly higher than some comparative systems with single-round consensus in the low-load range. However, as the load continues to increase, the latency growth curve of the system of this invention is significantly smoother: after the throughput exceeds 50k transactions / second, the latency of the multi-channel parallel processing system of this invention is consistently lower than that of typical comparative systems (such as FISCOBCOS based on a single-chain structure), and the tail latency is well controlled while maintaining high throughput.

[0141] In summary, the comparison between Embodiment 6 and Embodiment 7 shows that the multi-lower-level channel parallel workflow described in this invention has good scalability in actual deployment environments: while keeping other conditions basically unchanged, increasing the number of lower-level channels can effectively improve the system throughput limit, and still maintains better latency performance than the comparison system under high load scenarios, verifying the rationality and engineering practical value of the design of this invention in multi-core, multi-channel environments.

[0142] Figure 7 The following curves compare the throughput and latency of our multi-channel parallel processing solution with those of HLF, BIDL, and BCOS: Under workloads such as SmallBank, the multi-channel parallel processing solution significantly outperforms the comparison system at different concurrency / batch levels (OPL-4LG, OPL-10LG); as the number of transactions per second increases, the latency curve of the multi-channel parallel processing solution increases slowly, remaining in the sub-second range.

[0143] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-channel parallel processing method for blockchain networks, wherein the blockchain network includes multiple blockchain nodes, characterized in that, Blockchain nodes include: multiple lower-level channel thread groups One upper-level channel thread group (UG) and a world state management module; each lower-level channel thread group Maintain local transaction queues and local state snapshots; At any height t, each lower-level channel thread group Based on the local transaction queue and local state snapshot, local block metadata of height t is constructed in parallel and sent to the upper-layer channel thread group UG; the upper-layer channel thread group UG loads the world state snapshot of height t from the world state management module. World state snapshot based on height t For all lower-level channel thread groups The local block metadata at the same height t is processed to obtain the block at height t, the state advancement information at the new height t+1, and the world state snapshot. Broadcast the block at height t to other nodes in the blockchain network, and take a snapshot of the world state at the new height t+1. Store the information in the world state management module and broadcast the state progress information of the new height t+1 to each lower-level channel thread group. Each lower-level channel thread group Load a world state snapshot at height t+1 from the world state management module. Update the local state snapshot.

2. The multi-channel parallel processing method for blockchain networks according to claim 1, characterized in that, Lower-level channel thread group The upper-level channel thread group UG runs in parallel at different heights t.

3. The multi-channel parallel processing method for blockchain networks according to claim 1, characterized in that, Lower-level channel thread group Building a block of height t based on the local transaction queue and local state snapshot includes: S101: Select the set of transactions at height t from the local transaction queue. For the transaction set of height t Sort the transactions in the block to obtain a local block of height t. ; S102: Based on local state snapshots, according to local blocks Execution of local blocks in transaction order The transaction yields a local block. The read / write set and execution result of each transaction; based on the local block. A local block is constructed from the read / write sets and execution results of all transactions. Summary of candidate execution results; S103: For local blocks A consistency check is performed on the candidate execution result summary. If the check fails, the transaction set is removed. Mark as a failure and report an exception; otherwise, the local block... The candidate execution result summary is packaged into local block metadata of height t. It is then sent to the upper-level channel thread group UG and enters a waiting state.

4. The multi-channel parallel processing method for blockchain networks according to claim 3, characterized in that, Lower-level channel thread group entering the waiting state Triggered by local transaction queue length or periodic time window.

5. A multi-channel parallel processing method for blockchain networks according to claim 3, characterized in that, The upper-level channel thread group UG maintains the collection buffer; the upper-level channel thread group UG manages all lower-level channel thread groups. Local block metadata of height t The processing includes: S111: The upper-level channel thread group UG continuously receives data from all lower-level channel thread groups. Local block metadata Then insert a collection buffer and check whether the collection buffer has collected all the lower-level channel thread groups. Local block metadata of height t When all items are collected, proceed to step S112. S112: Retrieve local block metadata of height t from the collection buffer. Construct a local block metadata set of height t Using a consensus protocol to analyze the local block metadata set at height t Perform a global sort to obtain the blockchain epoch of height t. ; S113: Load a world state snapshot of height t from the world state management module. Based on world state snapshot The Blockchain Era By resolving conflicts among multiple copies, the blockchain era is established. The conflict resolution results and confirmed write set at each copy height t; S114. Calculate the state change summary for each replica height t based on the confirmed write set for each replica height t; perform a global consistency check on the state change summaries for all replica heights t. If the check passes, proceed to step S115; otherwise, return to step S113. S115. Generate a world state snapshot at a new height t+1 based on the confirmed write set of any copy height t. Based on the conflict resolution result of any replica at height t, construct a block at height t and generate state advancement information at a new height t+1.

6. A multi-channel parallel processing method for blockchain networks according to claim 5, characterized in that, For any copy, based on a world state snapshot The Blockchain Era Conflict adjudication includes: according to the blockchain era Metadata of each local block The order and metadata of each local block The order of each transaction determines the blockchain era. The global execution order of each transaction in the blockchain era; according to the blockchain era The global execution order of transactions in the blockchain era is as follows. Each transaction in the process undergoes conflict resolution, resulting in a conflict resolution result of height t and a set of confirmed writes.

7. A multi-channel parallel processing method for blockchain networks according to claim 5, characterized in that, The conflict resolution results include: a list of confirmed transactions, the execution result of each transaction in the list of confirmed transactions, and the impact on the blockchain epoch. Conflict adjudication in transaction T includes: Get the list of currently confirmed transactions and the set of currently confirmed writes; extract the read set R(T) and write set W(T) of transaction T from the candidate execution result summary of the local block metadata to which transaction T belongs; Based on the read set R(T) and write set W(T) of transaction T, and the world state snapshot The currently confirmed write set determines whether transaction T has a global conflict. If not, transaction T is merged into the currently confirmed transaction list. The execution result Result(T) of transaction T is extracted from the candidate execution result summary of the local block metadata of transaction T, and the write set W(T) is merged into the currently confirmed write set. Otherwise, transaction T is adjudicated according to the preset transaction control strategy.

8. A multi-channel parallel processing method for blockchain networks according to claim 7, characterized in that, Determining whether a transaction T has a global conflict includes: reading the versions of all keys in set R(T) and world state snapshots. If the version of the corresponding key in the currently confirmed write set is consistent, and the write set W(T) does not produce a write-write conflict with the currently confirmed write set, then transaction T is considered to have no global conflict; otherwise, transaction T is considered to have a global conflict.

9. A multi-channel parallel processing method for blockchain networks according to claim 7, characterized in that, The decision to adjudicate transaction T according to the preset transaction control policy includes: rolling back and discarding transaction T.

10. A multi-channel parallel processing system for blockchain networks, characterized in that, Deployed on a blockchain node to implement the multi-channel parallel processing method according to any one of claims 1 to 9, comprising: The transaction access and routing module receives transactions submitted by clients and distributes them to the local transaction queues of each lower-level channel thread group module. The lower-level channel thread group module constructs local block metadata in parallel based on the local transaction queue and local state snapshot, and sends the local block metadata to the upper-level channel thread group UG; after receiving state advancement information, it loads the world state snapshot from the world state management module to update the local state snapshot; The upper-level channel thread group module receives local block metadata from all lower-level channel thread groups, processes the local block metadata at the same height of all lower-level channel thread groups to obtain blocks, state progress information and world state snapshots, broadcasts the blocks to other blockchain nodes in the blockchain network, stores the world state snapshots in the world state management module, and broadcasts the state progress information to each lower-level channel thread group. The network communication module handles the sending, receiving, and routing of messages between blockchain nodes, between blockchain nodes and clients, and between various modules within a blockchain node.

Images