High-throughput blockchain sharding management method and system
By introducing a global cache pool into the blockchain sharding system, dividing the transaction lifecycle, and adopting an asynchronous confirmation mechanism, the problems of insufficient processing capacity within shards and low efficiency of cross-pool transaction coordination in high-concurrency environments are solved, achieving high-throughput transaction processing with low latency and low communication overhead.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHEJIANG SCI-TECH UNIV
- Filing Date
- 2026-04-10
- Publication Date
- 2026-07-21
AI Technical Summary
Existing sharded blockchain systems suffer from insufficient processing capacity within shards, low efficiency in cross-pool transaction coordination, and excessive communication and state overhead during transaction execution in high-concurrency transaction scenarios, making it difficult to meet the performance and efficiency requirements of high-concurrency environments.
A high-throughput blockchain sharding management method is adopted. By introducing a global cache pool, the transaction lifecycle is divided into four stages: local execution in the source pool, global caching, global batch consensus, and execution in the target pool. The global cache pool is used to coordinate cross-pool transactions. The method of local consensus in the source pool + global asynchronous confirmation is adopted to achieve low latency and low communication overhead for cross-pool transactions.
It significantly improves the parallel processing capability within shards, reduces cross-pool transaction coordination overhead, shortens transaction confirmation latency, and enhances the overall system performance and resource utilization.
Smart Images
Figure CN122022809B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of blockchain technology, specifically relating to a high-throughput blockchain sharding management method and system. Background Technology
[0002] As the blockchain application ecosystem continues to expand, the performance bottlenecks of its underlying architecture are becoming increasingly apparent. Traditional single-chain models are limited by the requirement that all nodes on the network process all transactions, resulting in overall system throughput constrained by structural limits and difficulty in achieving horizontal scalability. Faced with ever-increasing high-concurrency loads, there is an urgent need to build a high-performance blockchain system with linear scalability while maintaining decentralization and security. This direction has become a topic of common concern for both academia and industry.
[0003] Sharding technology, proposed and applied as a horizontal scaling paradigm for blockchains, effectively addresses the performance constraints of single-chain architectures. Its basic idea is to divide the node set and state space into several parallel subdomains with bounded access. Each subdomain, acting as a shard, independently handles transaction reception, execution, and consensus within its scope, maintaining its local ledger and state root. Within each shard, to maintain state consistency and fault tolerance, a Byzantine Fault Tolerance (BFT) consensus protocol is typically used as the foundation.
[0004] Existing sharded blockchain systems still face structural bottlenecks in high-concurrency transaction execution, mainly due to the serial proposal process, the complexity of state consistency maintenance, and the tight coupling of execution models. Most current protocols employ a single leader node-driven consensus process, requiring transactions to be processed sequentially by a single leader node, which becomes a bottleneck for system performance. Secondly, in cross-shard transaction coordination, the commonly used two-phase commit mechanism requires locking the relevant shard states to ensure atomicity, easily leading to conflicts and resource congestion, significantly reducing system performance. Furthermore, the transaction execution process is highly coupled with the consensus commit process, lacking a unified intermediate state or caching mechanism. This results in each transaction repeatedly accessing the global state in multiple phases, leading to heavy state tracking burdens and high response latency. These problems are further amplified in high-frequency cross-shard transaction scenarios, and currently, no solution simultaneously achieves structural optimization at the communication, execution, and data consistency levels. A Chinese invention patent (CN113568974B) proposes a sharded consensus method that achieves transaction processing through local consensus within shards and network-wide ordering. However, this solution still has shortcomings in large-scale, high-concurrency scenarios. These include the need to split cross-shard transactions for execution and reliance on network-wide sorting, resulting in significant coordination overhead; the limited processing mode within each shard, leading to limited overall system concurrency; and the potential for conflicts and delays in transaction scheduling and state maintenance when cross-shard calls are frequent. Therefore, existing technologies struggle to meet the performance and efficiency requirements of high-concurrency environments.
[0005] In high-concurrency scenarios, the sequential processing of transactions by a single leader node significantly increases the length of the transaction processing queue, further reducing system throughput. The current framework cannot fully utilize the parallel processing capabilities of multiple nodes within shards; all transactions must be executed strictly and sequentially in a single process, resulting in low resource utilization and response latency. Particularly in applications with frequent interactions, the heavy synchronization overhead and message passing latency of the transaction confirmation process further constrain system performance. Existing solutions lack effective cross-stage parallel pipelines or intermediate caching mechanisms to alleviate dependencies and waiting times between different stages.
[0006] Therefore, under the premise of ensuring system security and consistency, it is very important to design a blockchain consensus and execution method that can improve the parallel processing capability within shards, reduce cross-pool transaction coordination overhead, and shorten transaction confirmation latency. Summary of the Invention
[0007] This invention aims to overcome the problems of insufficient processing capacity within shards, low efficiency of cross-pool transaction coordination, and excessive communication and state overhead during transaction execution in existing sharded blockchains under large-scale high-concurrency scenarios. It provides a high-throughput blockchain sharding management method and system that can improve parallel processing capacity within shards, reduce cross-pool transaction coordination overhead, and shorten transaction confirmation latency.
[0008] To achieve the above-mentioned objectives, the present invention adopts the following technical solution:
[0009] The high-throughput blockchain sharding management method includes the following steps:
[0010] S1, Transaction Receipt and Type Determination:
[0011] The system receives a transaction submitted by the client and determines whether the transaction is a single-pool transaction or a cross-pool transaction based on the mapping relationship between the account involved in the transaction and the transaction pool. If it is a single-pool transaction, step S2 is executed; if it is a cross-pool transaction, step S3 is executed.
[0012] S2, Single Pool Transaction Processing:
[0013] If the transaction is a single-pool transaction, each transaction pool will independently complete the local consensus, block generation and ledger update of the transaction based on the intra-slice consensus protocol;
[0014] S3, Cross-pool Transaction Processing:
[0015] If the transaction is a cross-pool transaction, a global coordination process is executed; the global coordination process is as follows:
[0016] Each transaction pool submits the blocks that have achieved local consensus across the pool to the global cache pool; then the global cache pool coordinates and executes batch consensus blocks, and forwards the completed cross-pool transactions to the target transaction pool in batches.
[0017] Preferably, in step S1, a single-pool transaction refers to all accounts involved belonging to the same transaction pool; a cross-pool transaction refers to accounts involved belonging to at least two different transaction pools.
[0018] Preferably, step S2 includes the following steps:
[0019] S21. In a single transaction pool scenario, when a single pool transaction is received, the leader node in the current pool votes according to the consensus protocol, and the replica nodes participate in voting and confirmation in parallel.
[0020] S22: After each transaction pool completes its local consensus, it directly writes the block to its local ledger and updates the corresponding account status, without the need for cross-pool coordination.
[0021] Preferably, in step S3, the global cache pool exists as a buffer table in the local memory of each replica node, and each replica node maintains a buffer state view, ensuring state consistency through a periodic consensus protocol.
[0022] Preferably, in step S3, the global cache pool operates with a fixed time window δ as the scheduling cycle, and in each cycle, it aggregates multiple cross-pool transaction blocks from different transaction pools; at the end of the time window, the current round leader node of the global cache pool constructs a batch of transaction blocks. And initiate a consensus process involving all copies within the shard.
[0023] Preferably, step S3 includes the following steps:
[0024] S31, Cross-pool transaction submission:
[0025] Source Transaction Pool i Local consensus generates block B i A cross-pool transaction set is generated based on the cross-pool transaction screening rules. (tx represents a submitted transaction, i.e., a transaction data object submitted by the client and processed by the system; tx.target represents the target object of the transaction tx, used to determine which transaction pool should record the transaction.) Pool i The leader node submits a collection to the global cache pool GBP, along with the local certificate QC. i ;
[0026] S32, Global Cache Pool Batch Processing:
[0027] Set a fixed time window δ, with a window start time t.start Triggered by a broadcast from the GBP leader node, the global cache pool collects a set of cross-pool transactions within a time window δ. Record the global transaction list to form an ordered set, and map transactions based on target pool grouping. Construct global block B G , containing all T global ;
[0028] Broadcasting a message to the replica nodes triggers the global cache pool consensus process and generates a global certificate. Record blocks and push them in parallel to the relevant transaction pools;
[0029] S33, Cross-pool transaction distribution and execution:
[0030] Analysis of each trading pool B G Extract transactions belonging to the Pool according to the target transaction pool dst_pool. j (i and j represent different transaction pool numbers, Poolj is the target pool that receives and executes the cross-pool transaction) Transaction tx j , (T) j This indicates that the transaction is distributed to the target transaction pool. j A cross-pool transaction subset, where each transaction pool parses global block B. G Then, the target pool is designated as pool. j All transactions are selected to form a set T j `tx.dst_pool` represents the target transaction pool identifier for transaction `tx`, indicating which transaction pool should ultimately receive and execute the transaction (constructing block B in this region). j Attach global certificate σ G As proof, it is broadcast and submitted to the replica nodes, which then verify σ. G Validity is confirmed, the transaction is globally approved, and then the consensus process is executed to generate block B. j QC Certificate j ;
[0031] Finally, update the target account balance and mark it as tx. j Submitted.
[0032] This invention also provides a high-throughput blockchain sharding management system, including:
[0033] The transaction receiving module is used to verify the transaction signature and account mapping, as well as to determine the transaction type;
[0034] The local consensus module is used to execute the consensus protocol and generate local blocks and certificates;
[0035] The global cache coordination module is used to maintain the cache state table and run global batch consensus.
[0036] The state update module is used to verify the validity of the global certificate, and at the same time perform ledger updates and transaction commits;
[0037] The synchronization and cleanup module is used to periodically synchronize cache status and clean up expired transaction records.
[0038] Compared with the prior art, the beneficial effects of this invention are: (1) This invention proposes a high-throughput blockchain sharding management method; on this basis, a transaction coordination mechanism integrating a global cache pool is designed, which divides the life cycle of high-concurrency cross-pool transactions into four stages: local execution in the source pool, global caching, global batch consensus and execution in the target pool; this mechanism is different from the traditional pre-commit / rollback interaction mode, and adopts the source pool local consensus + global asynchronous confirmation method to achieve low latency, low communication overhead and no rollback execution of cross-pool transactions in a high-concurrency environment, with an overall complexity of O(n) structural advantage; (2) This invention introduces a flexible batch processing and pipeline scheduling strategy, which can make full use of sharding parallel resources and significantly reduce the number of message transmissions and consensus complexity. Attached Figure Description
[0039] Figure 1 This is a schematic diagram illustrating the principle architecture of the high-throughput blockchain sharding management method in this invention. Figure 2 This is a schematic diagram of a cross-pool transaction processing method in the present invention; Figure 3 This is a schematic diagram of a high-throughput blockchain sharding management system in this invention. Detailed Implementation
[0040] To more clearly illustrate the embodiments of the present invention, specific implementation methods will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.
[0041] This invention provides a high-throughput blockchain sharding management method, comprising the following steps:
[0042] 1. Transaction Receipt and Type Determination:
[0043] The system receives a transaction submitted by the client and determines whether the transaction is a single-pool transaction or a cross-pool transaction based on the mapping relationship between the accounts involved in the transaction and the transaction pools. If it is a single-pool transaction, step 2 is executed; if it is a cross-pool transaction, step 3 is executed. A single-pool transaction means that all the accounts involved belong to the same transaction pool; a cross-pool transaction means that the accounts involved belong to at least two different transaction pools.
[0044] 2. Single-pool transaction processing:
[0045] If the transaction is a single-pool transaction, each transaction pool will independently complete the local consensus, block generation and ledger update of the transaction based on the intra-slice consensus protocol;
[0046] 3. Cross-pool transaction processing:
[0047] If the transaction is a cross-pool transaction, a global coordination process is executed; the global coordination process is as follows:
[0048] Each transaction pool submits the blocks that have achieved local consensus across the pool to the global cache pool; then the global cache pool coordinates and executes batch consensus blocks, and forwards the completed cross-pool transactions to the target transaction pool in batches.
[0049] Specifically, such as Figure 1 As shown, the method of the present invention is as follows:
[0050] Single transaction pool operation process: All accounts and states involved in a transaction belong to the same leader node's transaction pool. Such transactions can be submitted as long as consensus is reached within the same transaction pool, without the need for cross-pool coordination.
[0051] In a single transaction pool scenario, since all accounts involved in a transaction reside within the same shard, the execution process of this invention is consistent with traditional sharded consensus. However, unlike the serial proposal mode that relies on a single leader node, this invention allows each transaction pool to initiate local consensus in parallel on its leader node. Specifically, upon receiving a single-pool transaction, the current leader node within the pool can vote according to the consensus protocol, and replica nodes participate in voting and confirmation in parallel. After each transaction pool completes its local consensus, it directly writes the block to its local ledger and updates the corresponding account status. Because cross-pool coordination is unnecessary, each transaction pool can independently and in parallel process single-pool transactions, thereby improving the overall system's parallel processing capability.
[0052] Cross-transaction pool operation process: First, a global cache pool is designed specifically for coordinating the execution of cross-pool transactions, ensuring the safe atomicity of cross-pool transaction commits. The global coordination phase includes two core steps: First, each transaction pool submits blocks that have achieved local consensus on the cross-pool transaction set to the global cache pool; second, the global cache pool coordinates and executes batch consensus blocks, forwarding the completed cross-pool transactions in batches to the target transaction pool. Through this mode, cross-pool transactions achieve asynchronous pipelined processing between the source and target pools, eliminating the need to immediately lock the target shard state during transaction commit, thereby significantly reducing coordination latency and the probability of conflicts.
[0053] The global cache pool is not managed by a single node, but exists as a buffer table in the local memory of each replica node. Each replica node maintains a view of the buffer state, and state consistency is ensured through a periodic consensus protocol. Specifically, the global cache pool operates on a fixed time window δ as its scheduling cycle, aggregating multiple cross-pool transaction blocks from different transaction pools within each cycle. At the end of the time window, the current round leader node of the cache pool constructs a batch of transaction blocks. It then initiates a consensus process involving all replicas within the shard. The cache table is designed as follows: Tx_ID is a globally unique identifier for cross-pool transactions, used to index and identify transaction status; Source_Pool records the transaction pool from which the transaction was initially committed; Target_Pools records the set of target transaction pools involved in the transaction; Tx_Content contains the transaction execution content; and Expire_Timeδ is a fixed time.
[0054] During the global coordination phase, a global cache pool is used to relay cross-pool transaction status information between different leader nodes, avoiding synchronization waits between leader nodes and ensuring intra-segment parallel operation performance. After successful consensus within the cache pool, transaction information including that of the source and target transaction pools is structured, recorded, and broadcast. In addition, each record in the cache pool status table is updated to "committed." Each target transaction pool reads the consensus-reached transactions and completes its local ledger update. All replica nodes clean up the corresponding cache pool records and release cache resources.
[0055] Specifically, such as Figure 2 As shown, the global coordination process generally includes the following steps:
[0056] 3-1. Cross-pool transaction submission:
[0057] Source Transaction Pool i Local consensus generates block B i A cross-pool transaction set is generated based on the cross-pool transaction screening rules. Pool i The leader node submits the collection to GBP, along with its local certificate QC. i ;
[0058] 3-2. Global cache pool batch processing:
[0059] Set a fixed time window δ, with a window start time t. start Triggered by a broadcast from the GBP leader node, the global cache pool collects a set of cross-pool transactions within a time window δ. Record the global transaction list to form an ordered set, and map transactions based on target pool grouping. Construct global block B G , containing all T global ;
[0060] Broadcasting a message to the replica nodes triggers the global cache pool consensus process and generates a global certificate. Record blocks and push them in parallel to the relevant transaction pools;
[0061] 3-3. Cross-pool transaction distribution and execution:
[0062] Analysis of each trading pool B G Extract transactions belonging to the Pool according to the target transaction pool dst_pool. j Transaction tx j , Construct local block B j Attach global certificate σ G As proof, it is broadcast and submitted to the replica nodes, which then verify σ. G Validity is confirmed, the transaction is globally approved, and then the consensus process is executed to generate block B. j QC Certificate j ;
[0063] Finally, update the target account balance and mark it as tx. j Submitted.
[0064] like Figure 3 As shown, the present invention also provides a high-throughput blockchain sharding management system, including:
[0065] The transaction receiving module is used to verify the transaction signature and account mapping, as well as to determine the transaction type;
[0066] The local consensus module is used to execute the consensus protocol and generate local blocks and certificates;
[0067] The global cache coordination module is used to maintain the cache state table and run global batch consensus.
[0068] The state update module is used to verify the validity of the global certificate, and at the same time perform ledger updates and transaction commits;
[0069] The synchronization and cleanup module is used to periodically synchronize cache status and clean up expired transaction records.
[0070] Based on the technical solution of this invention, the implementation process of this invention in practical applications will be illustrated through the following case scenarios. The specific application implementation scheme is as follows:
[0071] Single-pool transaction execution:
[0072] When all accounts and states involved in a transaction belong to the same transaction pool, the transaction is marked as a single-pool transaction and can be processed without invoking the global cache pool for coordination. A specific example of its operation includes the following steps:
[0073] Step S1: Receiving and Inspection
[0074] The transaction pool module receives transaction requests submitted by clients and sequentially performs signature verification, transaction identifier uniqueness verification, account nonce sequence check, and balance adequacy verification. After successful verification, the module determines the transaction's pool based on the set account-transaction pool binding mapping rules. If both the source and target accounts are in the same pool... If so, the transaction is marked as a single-pool transaction;
[0075] Step S2: Consensus Voting
[0076] The local consensus module completes block generation within the pool based on the Fast-Hotstuff protocol. The proposal, voting, and confirmation process generates a legal certificate when at least 2f+1 valid votes are collected. The system then submits the block. It subsequently writes the block transaction to the ledger, updates the account status, and persists the block header and certificate information, achieving eventual consistency for the single-pool transactions.
[0077] Cross-pool transaction execution:
[0078] In this example, the sharding system is configured with 4 transaction pools ( Each transaction pool is responsible for maintaining a set of accounts. A client submits a transfer transaction: User A (account in...) ) to user B (account in Transfer 100 units of assets. This transaction involves the source pool. and target pool Therefore, it belongs to cross-pool transaction.
[0079] Step S1: Source Pool Local Consensus
[0080] 1. The client submits the transaction tx{from:A,to:B,amount:100} to... ;
[0081] 2. After the transaction pool module completes signature verification, tx uniqueness check, nonce order check and balance verification, it determines that the transaction is a cross-pool transaction;
[0082] 3. The local consensus module runs the Fast-Hotstuff consensus protocol, and the leader node of the current round packages the transaction into a block. During this phase, the balance of Account A will be temporarily frozen by 100 units;
[0083] 4. By The current leader node constructs a cross-pool transaction message and submits it to the cached transaction pool;
[0084] Step S2: Global caching and window aggregation
[0085] 1. The current cache transaction pool leader node broadcasts a window opening message to align the time window with all replica nodes. It takes 50ms;
[0086] 2. During this window, the cache pool collects The submitted cross-pool transaction records are aggregated after being submitted concurrently by multiple source pools.
[0087] Step S3: Global Batch Consensus
[0088] 1. After the window expires, the leader node constructs a global block. And execute the Fast-Hotstuff consensus protocol on the replica nodes;
[0089] 2. After each replica node verifies the validity of the proposal, it returns to the voting stage, and the leader node generates the global certificate. and broadcast the submitted message;
[0090] 3. All replica nodes record global blocks. This completes the consistency verification of the global cache pool.
[0091] 4. The leader node will control the global block. The broadcast is sent to each trading pool;
[0092] Step S4: Target Pool Distribution and Ledger Update
[0093] 1. Receive global block After verifying the validity of the block, the block transaction information is extracted.
[0094] 2. The leader node packages the current cross-pool transaction into a block. It runs the Fast-Hotstuff consensus protocol with each replica node in the pool;
[0095] 3. Write the transaction to the local account, deduct 100 units of assets from account A, add 100 units of assets to account B, and complete the status update;
[0096] 4. After the ledger is updated, Return a transaction success receipt to the client.
[0097] This invention proposes a high-throughput blockchain sharding management method. Based on this, a transaction coordination mechanism integrating a global cache pool is designed, dividing the lifecycle of high-concurrency cross-pool transactions into four stages: local execution in the source pool, global caching, global batch consensus, and execution in the target pool. This mechanism differs from the traditional pre-commit / rollback interaction mode, employing a source pool local consensus + global asynchronous confirmation approach to achieve low latency, low communication overhead, and rollback-free execution of cross-pool transactions in high-concurrency environments, exhibiting a structural advantage with an overall complexity of O(n).
[0098] The above description is merely a detailed explanation of preferred embodiments and principles of the present invention. For those skilled in the art, there may be changes in specific implementation methods based on the ideas provided by the present invention, and these changes should also be considered within the scope of protection of the present invention.
Claims
1. A high-throughput blockchain sharding management method, characterized in that, Includes the following steps: S1, Transaction Receipt and Type Determination: The system receives a transaction submitted by the client and determines whether the transaction is a single-pool transaction or a cross-pool transaction based on the mapping relationship between the account involved in the transaction and the transaction pool. If it is a single-pool transaction, step S2 is executed; if it is a cross-pool transaction, step S3 is executed. S2, Single Pool Transaction Processing: If the transaction is a single-pool transaction, each transaction pool will independently complete the local consensus, block generation and ledger update of the transaction based on the intra-slice consensus protocol; S3, Cross-pool Transaction Processing: If the transaction is a cross-pool transaction, a global coordination process is executed; the global coordination process is as follows: Each transaction pool submits the blocks that have achieved local consensus on cross-pool transaction sets to the global cache pool; then the global cache pool coordinates and executes batch consensus blocks, and forwards the completed cross-pool transactions to the target transaction pool in batches; In step S3, the global cache pool operates with a fixed time window δ as the scheduling cycle, and in each cycle, it aggregates multiple cross-pool transaction blocks from different transaction pools; at the end of the time window, the current round leader node of the global cache pool constructs a batch of transaction blocks. And initiate a consensus process involving all replicas within the shard; Step S3 includes the following steps: S31, Cross-pool transaction submission: Source Transaction Pool i Local consensus generates block B i A cross-pool transaction set is generated based on the cross-pool transaction screening rules. `tx` represents a submitted transaction, and `tx.target` represents the target object of the transaction `tx`; Pool i The leader node submits a collection to the global cache pool GBP, along with the local certificate QC. i ; i represents the transaction pool number; S32, Global Cache Pool Batch Processing: Set a fixed time window δ, with a window start time t. start Triggered by a broadcast from the GBP leader node, the global cache pool collects a set of cross-pool transactions within a time window δ. Record the global transaction list to form an ordered set, and construct global block B based on the transaction mapping grouped by the target pool. G , containing all T global ; Broadcasting a message to the replica nodes triggers the global cache pool consensus process and generates a global certificate. Record blocks and push them in parallel to the relevant transaction pools; S33, Cross-pool transaction distribution and execution: Analysis of each trading pool B G Extract transactions belonging to the Pool according to the target transaction pool dst_pool. j Transaction tx j Construct local block B j Attach global certificate σ G As proof, it is broadcast and submitted to the replica nodes, which then verify σ. G Validity is confirmed, the transaction is globally approved, and then the consensus process is executed to generate block B. j QC Certificate j Pool j It is the target pool that receives and executes the corresponding cross-pool transactions; Finally, update the target account balance and mark it as tx. j Submitted.
2. The high-throughput blockchain sharding management method according to claim 1, characterized in that, In step S1, a single-pool transaction refers to all accounts involved belonging to the same transaction pool; a cross-pool transaction refers to accounts involved belonging to at least two different transaction pools.
3. The high-throughput blockchain sharding management method according to claim 1, characterized in that, Step S2 includes the following steps: S21. In a single transaction pool scenario, when a single pool transaction is received, the leader node in the current pool votes according to the consensus protocol, and the replica nodes participate in voting and confirmation in parallel. S22: After each transaction pool completes its local consensus, it directly writes the block to its local ledger and updates the corresponding account status, without the need for cross-pool coordination.
4. The high-throughput blockchain sharding management method according to claim 1, characterized in that, In step S3, the global cache pool exists as a buffer table in the local memory of each replica node. Each replica node maintains a buffer state view and ensures state consistency through a periodic consensus protocol.
5. A high-throughput blockchain sharding management system, used to implement the high-throughput blockchain sharding management method according to any one of claims 1-4, characterized in that, The high-throughput blockchain sharding management system includes: The transaction receiving module is used to verify the transaction signature and account mapping, as well as to determine the transaction type; The local consensus module is used to execute the consensus protocol and generate local blocks and certificates; The global cache coordination module is used to maintain the cache state table and run global batch consensus. The state update module is used to verify the validity of the global certificate, and at the same time perform ledger updates and transaction commits; The synchronization and cleanup module is used to periodically synchronize cache status and clean up expired transaction records.