High-performance parallel block chain method and system for stable currency

Abstract

The invention provides a high-performance parallel block chain method and system for stable currency. The method comprises the following steps: S1, layering a system architecture; s2, realizing parallel block production and pipelined voting of multiple suggestors in combination with role setting; s3, determining a certificate QC through an aggregation signature construction method, and implementing a two-round voting submission rule; s4, implementing a consensus process; s5, based on the key value storage model of the multi-version state, performing dynamic switching between transaction execution and transaction verification; s6, optimistic parallel control and multi-version state management are adopted, and scheduling and execution of an LEAP execution engine are achieved; s7, executing a state fragmentation mechanism in the high-concurrency hotspot scene; and S8, establishing an interface constraint and cooperation mechanism between the consensus layer and the execution layer. According to the method, an MP3-BFT protocol, an LEAP execution engine and a state fragmentation mechanism can be combined, approximately linear throughput expansion is achieved, a large amount of rollback and retry overhead are effectively avoided, the probability of write conflicts is reduced, and sequence consistency is ensured.

Description

Technical Field

[0001] This invention relates to a blockchain method in the context of stablecoin applications, particularly to a high-performance parallel blockchain method for stablecoins, and further to a high-performance parallel blockchain system employing this high-performance parallel blockchain method for stablecoins. Background Technology

[0002] Against the backdrop of the rapid development of stablecoin applications globally, existing general-purpose public blockchains and some specialized stablecoin blockchains are finding it increasingly difficult to meet the business needs of the next stage in terms of performance, efficiency, and stability. Specifically, this includes the following aspects.

[0003] First, existing BFT (Byzantine Fault Tolerance) consensus protocols generally employ a single-leader sequential proposal mechanism, meaning that within a given view or height, only one elected leader is responsible for collecting transactions and packaging blocks. This design is sufficient for smaller node sizes, but in large-scale stablecoin networks, the limited computing power, network bandwidth, and I / O capabilities of a single leader easily make block generation and voting aggregation bottlenecks. Furthermore, for future global stablecoin settlement infrastructures that may need to support hundreds of thousands or even millions of TPS, relying solely on a single-leader scheme is clearly insufficient to achieve near-linear throughput expansion.

[0004] Second, existing parallel execution engines incur excessive overhead for rollback and retry in high-conflict scenarios, making it difficult to reliably support large-scale stablecoin payment and settlement operations. A prominent feature of stablecoin transactions is the presence of a small number of frequently accessed custodian addresses, payment aggregation addresses, and merchant receiving addresses. These accounts receive a massive number of transfer requests within a short period, leading to severe write conflicts to their balances and related counters. If a traditional optimistic parallel execution mechanism is used, frequent rollbacks and retries are required in such scenarios, easily resulting in a significant decrease in CPU utilization, a marked drop in throughput, and even, in extreme cases, a degradation into inefficient serial execution.

[0005] Third, existing systems lack in-depth optimization in the unified design of the consensus and execution layers. The design of the consensus layer in terms of transaction organization order, batch division, and certificate structure when generating blocks and batches substantially affects the order and parallelism of transaction processing in the execution layer. If these two are designed independently and are unaware of each other, it is difficult to maximize the utilization of parallelism and pipelined opportunities at the system-wide level.

[0006] Fourth, the application layer is currently mainly responsible for alleviating the write conflicts in high-frequency access accounts. Application parties often split multiple sub-accounts manually or use off-chain accounting systems to disperse the pressure, but this cannot be reflected as a unified, transparent, and auditable mechanism at the protocol level, nor can it reduce the probability of write conflicts, reduce transaction rollbacks and latency jitter without changing the account semantics.

[0007] Therefore, it is necessary to provide a high-performance parallel blockchain method and system for stablecoins to address the above technical issues. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a high-performance parallel blockchain method for stablecoins, aiming to allow multiple proposers to parallelly package transactions at the same height, achieve approximate linear throughput expansion, effectively avoid a large amount of rollback and retry overhead, reduce the probability of write conflicts, and establish interface constraints and coordination mechanisms between the consensus layer and the execution layer to ensure sequential consistency, so as to maximize the parallelism and pipelining of the system. On this basis, a high-performance parallel blockchain system adopting the above high-performance parallel blockchain method for stablecoins is further provided.

[0009] In response to this, the present invention provides a high-performance parallel blockchain method for stablecoins, including the following steps: Step S1, perform hierarchical planning on the system architecture, including the consensus layer, execution layer, protocol layer, native service layer, and application layer from bottom to top; Step S2, establish a consensus cluster composed of n nodes, where the number of Byzantine nodes f satisfies the security threshold of f < n / 3, elect proposers through the random lottery mechanism of the verifiable random function VRF, and achieve parallel block production and pipelined voting by multiple proposers in combination with role settings; Step S3, construct a legal certificate QC corresponding to the batch through aggregate signature under the Byzantine Fault Tolerance (BFT) framework, package multiple batches using a chained block structure, implement a two-round voting submission rule, and establish a locking rule for the legal certificate highQC of the parent block; Step S4, implement the consensus process through a lottery phase, a proposal phase, a voting phase, and a submission phase; Step S5, based on a key-value storage model with multiple versions of states, maintain a multi-version linked list for each state key, record the transaction number and retry sequence number, and maintain two atomic indexes in the execution layer, and dynamically switch between executing transactions and verifying transactions in combination with worker threads; Step S6: Adopt optimistic parallel control and multi-version state management. The worker threads obtain transaction numbers through atomic increment operations and execute business logics, record read-write sets, and reserve write positions in the multi-version storage. During the verification phase,复查 the consistency of the read set versions in the order of the global verification index, and introduce the Estimate marking mechanism to predict and prompt conflicting versions. Combine with the limited retry strategy, increment the execution index and verification index through atomic operations, and use a lock-free linked list to maintain the waiting queue and dependency relationships to实现 the scheduling and execution of the LEAP execution engine, where the LEAP execution engine refers to a lock-free prediction-aware parallel execution engine. Step S7: Execute the state sharding mechanism in high-concurrency hotspot scenarios. For each high-frequency access account, logically divide its balance state into several sub-slots internally, and each sub-slot corresponds to an independent counter. Step S8: Establish interface constraints and coordination mechanisms between the consensus layer and the execution layer.

[0010] A further improvement of the present invention is that in Step S1, the consensus layer is responsible for replicating transaction logs and generating a deterministic total order of transactions; the execution layer is responsible for interpreting and executing transactions in the order of transactions determined by the consensus to complete the conversion of the on-chain state from the old version to the new version; the protocol layer is used to provide protocol primitives and system functions; the native service layer is used to integrate high-frequency intelligent contract services; the application layer is used to carry terminal services.

[0011] A further improvement of the present invention is that Step S2 includes the following sub-steps: Step S201: Under the Dwork-Lynch-Stockmeyer synchronous network model, establish a consensus cluster composed of n nodes, and establish a mathematical constraint relationship of f < n / 3 as the boundary condition for security verification. Step S202: Elect proposers through the random lottery mechanism of the verifiable random function VRF. Each proposer can independently propose one or more batches at the current height, and thus实现 multi-proposer parallel block production within the same height. Step S203: All members of the consensus committee act as voters. After each voter receives a proposal, verify its legality, transaction correctness, and internal batch conflicts, and vote in favor or against the batch of the proposal according to the verification results. Consider the batch that obtains the approval votes of at least 2f + 1 nodes as obtaining the legal certificate QC. Step S204: Select the proposer with the smallest number at each height as the aggregator at that height. When the aggregator detects that there are batches that have obtained the legal certificate QC reaching the preset threshold at the current height, pack the verified batches into the final block at that height and broadcast it to the whole network. In step S205, all full nodes act as executors, executing transactions locally in the order of the final blocks and updating their local states. During execution, all executors replay transactions on the same state machine to obtain a consistent state.

[0012] A further improvement of the present invention is that step S3 includes the following sub-steps: Step S301: When the aggregator collects at least 2f+1 valid signatures from different nodes, it uses the aggregate signature algorithm to compress these valid signatures into a constant-size aggregate signature, and combines the aggregate signature with the batch hash value to form the legal certificate QC for that batch. In step S302, at each height, the aggregator packages several batches that have obtained legal certificates (QCs) into a single block. The block header includes the hash value of the previous block, the list of batch hashes contained in the current block, the legal certificate QCs of each batch, the height, and the view number. Step S303: A two-round voting mechanism is adopted. The first voting stage is used to initially confirm the batch of proposals, and the second voting stage is used to confirm the blocks formed in the previous round. When the second round of voting reaches the statutory certificate QC, the corresponding block is considered to be finalized, and the proposal and voting are executed overlapping in the continuous view. In step S304, when each proposer generates a new batch, it references the currently known highest height or highest view of the legal block as the parent block, and the parent block holds the parent block's legal certificate highQC; when voters vote on a proposal, they check whether the parent block's legal certificate highQC referenced by the proposal satisfies the monotonically increasing locking condition. If it does, they vote in favor; otherwise, they refuse to vote on the fork chain. In step S305, when multiple proposers submit proposals for different transaction sets at the same height, each batch is allowed to form an independent legal certificate (QC). When constructing the final block, the aggregator follows the following constraints: batches with conflicting transaction content are excluded, and deterministic sorting and filtering strategies are used to generate blocks.

[0013] A further improvement of the present invention is that step S4 includes the following sub-steps: Step S401: During the lottery phase, candidate accounting nodes use a verifiable random function (VRF) to locally calculate the seed information at the current height, obtaining a random output and proof. Based on the random output, the number of times the node wins at the current height is determined using the Bernoulli cumulative probability function. The number of winnings is proportional to the amount of tokens staked by the node or its accounting weight. Nodes with a winning count greater than zero broadcast their random output and proof, declaring that they have won at the current height and become proposers. In step S402, during the proposal phase, each successful proposer first selects unpackaged transactions from the local transaction pool and divides the transactions into one or more batches according to a preset number; then, a hash value is calculated for each batch, a proposal message containing height, view, parent block hash value and batch content is generated, and a randomly output proof and proof of the number of successful bids are added. The proposal message is then broadcast to all voters through a peer-to-peer network. Step S403: During the voting phase, after receiving the batch, the voter verifies the proof of the randomly output to confirm the proposer's qualification, checks the legality of the batch structure and transaction format, and checks whether the batch has a direct conflict with other received batches at the same height. Until the check is qualified and there is no direct conflict, a vote of approval containing the batch hash value and the voter's signature is generated and sent to the aggregator specified at the current height. In step S404, during the submission phase, the aggregator continuously accumulates the number of affirmative votes and corresponding signatures for each batch. When a batch receives no less than 2f+1 affirmative votes, it uses the aggregate signature algorithm to construct its legal certificate QC and broadcasts it. After at least one batch obtains a legal certificate QC at the current height, the aggregator packages these batches according to predetermined rules, constructs a block header containing the parent block hash value, a batch list, and the legal certificate QCs for each batch, and broadcasts it to the entire network. After receiving the block, each node confirms that the transaction set at this height has been finally determined and triggers the execution layer to update the state. Step S405 involves overlapping the four stages of step S401 from step S404 at different heights. Step S406: When the aggregator fails to collect enough votes or construct a valid block within the specified time, the current view aggregator is deemed invalid and the aggregator role is automatically transferred to the next candidate proposer; the new aggregator collects votes from other proposers at the same height and completes block construction within the new time window.

[0014] A further improvement of the present invention is that step S5 includes the following sub-steps: Step S501: After each block is determined by the consensus layer, the execution layer sequentially numbers the transactions in the block from 0 to N-1, where N represents the total number of transactions in the block; each transaction is treated as a state machine operation, which includes reading and writing several state keys in the state tree, and the read set of the i-th transaction is denoted as R_i, and the write set is denoted as W_i; Step S502: A multi-version key-value storage structure is adopted. A multi-version linked list is maintained for each state key. Each version item in the multi-version linked list records the transaction number, retry number, and write value of the state key. The retry number is used to distinguish different versions generated in multiple executions of the same transaction. The multi-version linked list is stored in chronological order or commit order. The latest committed version is located at the head, and uncommitted intermediate versions are distinguished by special markers, realizing lock-free access to the state history. Step S503: Maintain two atomic indices at the execution layer to indicate the current minimum transaction number to be executed and the minimum transaction number to be verified and submitted, respectively. Step S504: Set the conditions for worker threads to dynamically switch between executing and verifying transactions. If there are transactions that have been executed but not yet verified, they will participate in the verification work first. If there are no transactions to verify, new transactions will be taken from the sequence of unexecuted transactions for execution. Step S505: When a worker thread is executing a transaction, if it finds that the state key to be read currently only has an estimated version or has pending dependencies, it actively suspends the current transaction and releases computing resources; it will automatically wake up and resume execution after the dependencies are satisfied.

[0015] A further improvement of the present invention is that step S6 includes the following sub-steps: Step S601: During the execution phase, all worker threads retrieve the next transaction number to be executed from the global execution index through an atomic increment operation; when executing a transaction, the version information corresponding to each status key read by the transaction is recorded, and a position is reserved in the storage of the multi-version linked list for the status keys in the write set; after the business logic of executing the transaction is completed, the write result is recorded as a new version, and the transaction is marked as execution completed and pending verification. In step S602, during the verification phase, the completed transactions are checked according to the order of the global verification index. For transactions in the pending verification state, the read set version recorded during execution is reviewed. If the read set version is consistent with the version recorded during execution, the write version is committed, the write version of the transaction is marked as committed, and all waiting transactions that depend on this version are woken up. Otherwise, the write version is marked as Estimate and a retry is triggered. Subsequent transactions are suspended and wait until the transaction responsible for the Estimate state completes the retry and commit. The Estimate state refers to the conflict warning mark state. Step S603: In the retry strategy phase, a single retry limit is set. When a transaction is aborted due to a read set version conflict after its first execution, the transaction is suspended before the second execution, waiting for all related dependent transactions to complete and commit. If the transaction still fails to pass verification on the second attempt, it is marked as failed. In step S604, during the task scheduling and state update phase, the worker thread increments the execution index and verification index through atomic operations, and maintains the waiting queue and transaction dependencies using a lock-free linked list; when a transaction is committed or terminated, the worker thread traverses its transaction dependencies and updates the waiting transaction status to ready, so that it can re-enter the execution phase.

[0016] A further improvement of the present invention is that step S7 includes the following sub-steps: Step S701: For each high-frequency access account, its balance status is internally logically divided into p independent sub-slots, where p is a natural number. Each sub-slot corresponds to an independent counter and is stored in a different status key, so that the write operation of the balance status is distributed to multiple physically isolated storage units. Step S702: When updating the balance of the payee or payer, determine the target sub-slot number to be hit in this update based on the transaction characteristics. The transaction characteristics include at least one of the sender address hash value, transaction sequence number and stable allocation function. Step S703: Write operation is performed only on the target sub-slot determined in step S702. The write operation follows the multi-version storage mechanism and appends the new version to the version chain corresponding to the target sub-slot. In step S704, when reading the total balance of the account, traverse all sub-slots of the account, sum the count values ​​of each sub-slot, and return the sum.

[0017] A further improvement of the present invention is that step S8 includes the following sub-steps: Step S801: After generating multiple batches in parallel within the same height and forming statutory certificates (QCs) for each batch, the aggregator sorts all batches according to deterministic rules and assigns a unique global number to each transaction. The deterministic rules include at least one of the following: proposal timestamp, proposer weight, and batch hash value. Step S802: In the execution layer, after the LEAP execution engine executes transactions in parallel, the transactions are submitted one by one in ascending order of global number during the submission phase, ensuring that when the k-th transaction is submitted, all transactions with global numbers less than k have been submitted, and all transactions with global numbers greater than k have not been submitted. In step S803, when each transaction is aborted due to a read set version conflict and retried, its position in the global number remains unchanged, and it attempts to read the latest visible state again in the same order. In step S804, the consensus layer and the execution layer are decoupled through a unified block and state interface. When the consensus layer submits a block, it provides the execution layer with a block structure containing the transaction sequence and corresponding metadata. After the execution layer completes the submission of all transactions and the state update, it returns the latest state root and related digest to the consensus layer for the verification of subsequent blocks.

[0018] This invention also provides a high-performance parallel blockchain system for stablecoins, which employs the high-performance parallel blockchain method for stablecoins as described above, and includes: The layered planning module plans the system architecture in layers, including the consensus layer, execution layer, protocol layer, native service layer, and application layer from bottom to top. Consensus and Role Setting Module, which establishes a consensus cluster composed of n nodes. Among them, the number of Byzantine nodes f satisfies the security threshold of f < n / 3. The proposer is elected through the random lottery mechanism of the Verifiable Random Function (VRF), and multi-proposer parallel block production and pipelined voting are achieved by combining role setting; Block Submission Rule Module, which constructs a legal certificate QC corresponding to the batch through aggregate signature under the Byzantine Fault Tolerance (BFT) framework, packages multiple batches using a chained block structure, implements a two-round voting submission rule, and establishes a locking rule for the legal certificate highQC of the parent block; Consensus Module, which realizes the consensus process through the lottery stage, proposal stage, voting stage and submission stage; Execution and State Management Module, based on the key-value storage model of multi-version states, maintains a multi-version linked list for each state key, records the transaction number and retry sequence number, and maintains two atomic indexes at the execution layer. Combining with worker threads, it dynamically switches between executing transactions and verifying transactions; Scheduling and Execution Module of the LEAP Execution Engine, which adopts optimistic parallel control and multi-version state management. Worker threads receive transaction numbers through atomic increment operations and execute business logic, record read-write sets and reserve write positions in the multi-version storage; During the verification stage, it复查 the consistency of the read set versions in the order of the global verification index, and introduces the Estimate marking mechanism to predict and prompt conflict versions; Combining with a limited retry strategy, it increments the execution index and verification index through atomic operations, and uses a lock-free linked list to maintain the waiting queue and dependency relationship to实现 the scheduling and execution of the LEAP execution engine; State Sharding Module, which executes the state sharding mechanism in high-concurrency hotspot scenarios. For each high-frequency access account, its balance state is logically divided into several sub-slots internally, and each sub-slot corresponds to an independent counter; Collaboration Module, which establishes interface constraints and collaboration mechanisms between the consensus layer and the execution layer.

[0019] Compared with existing technologies, the advantages of this invention are as follows: First, the system architecture is planned in layers, adopting a layered architecture that separates the consensus layer and the execution layer. Through consensus protocols and role settings, parallel block production by multiple proposers and pipelined voting are achieved, enabling the system to have linearly scalable throughput. Then, block submission rules and consensus processes are defined. Under the premise of ensuring strict sequential semantics at the execution layer, the execution and verification processes of multiple transactions are advanced in parallel, maintaining a constant security threshold. The locking rules of the parent block's legal certificate, highQC, ensure no fork submissions, guaranteeing system security and achieving efficient processing of stablecoin transaction loads. Next, the scheduling and execution of the LEAP execution engine are implemented, effectively avoiding significant rollback and retry overhead. In high-concurrency hotspot scenarios, a state sharding mechanism is implemented, thereby reducing the probability of write conflicts and significantly improving system performance with minimal storage and read amplification costs. Finally, interface constraints and coordination mechanisms are established between the consensus layer and the execution layer to ensure sequential consistency, maximizing the parallelism and pipelined nature of the system. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating the operation of one embodiment of the present invention; Figure 2 This is a schematic diagram of the consensus process according to an embodiment of the present invention. Detailed Implementation

[0021] Before providing a detailed description of the preferred embodiments of the present invention, related technologies will be introduced first.

[0022] First, regarding stablecoins and their importance in blockchain.

[0023] Stablecoins are a type of crypto asset whose value is anchored to fiat currency, commodities, or other stable assets. They aim to reduce the usage and settlement risks associated with the price volatility of traditional cryptocurrencies and are widely used in centralized and decentralized exchanges, cross-border payments and clearing, on-chain fund management, synthetic asset collateralization, and the issuance and settlement of emerging real-world assets (RWAs). In these scenarios, stablecoins not only act as units of account and payment mediums but also serve as a bridge between on-chain credit and off-chain financial systems, promoting the integration of the digital asset economy with traditional financial infrastructure. The advantages of stablecoins are particularly prominent in cross-border payments and real-time clearing scenarios. Cross-border payments based on stablecoins can complete value transfers within minutes or even seconds, significantly reducing reliance on intermediaries and regional clearing systems.

[0024] However, the widespread adoption of stablecoins has pushed the underlying blockchain systems to their performance and cost limits. First-generation smart contract public blockchains, such as Ethereum, were not specifically optimized for large-scale stablecoin payments. During peak periods, congestion easily occurs, transaction confirmation times increase significantly, and users have to pay much higher gas fees than during off-peak hours to obtain the same confirmation speed.

[0025] The above reality shows that simply making minor optimizations to existing common approaches is no longer enough to support the future growth trend of stablecoins. Providing a high-performance, high-throughput, low-latency, and low-cost underlying blockchain system has become an urgent need for the industry and academia.

[0026] Second, regarding the performance bottlenecks and parallelization trend of blockchain.

[0027] The performance of blockchain systems is constrained by several bottlenecks, the two most critical of which stem from the consensus protocol layer and the execution engine layer. The consensus layer is responsible for ensuring the security and consistency of the system by uniformly determining the order and content of blocks, even in the presence of Byzantine faults and partial network synchronization issues. The execution layer, on the other hand, replays consensus-reached transactions in a specific order, driving deterministic changes in the on-chain state.

[0028] At the consensus layer, Proof-of-Work (PoW) suffers from low throughput and high latency. While BFT protocols such as PBFT and HotStuff offer deterministic finality, their communication complexity increases polynomially with the number of nodes, and the single-leader serial proposal mechanism limits throughput in high-concurrency scenarios. Although DAG structures support parallel propagation, they increase design complexity and the difficulty of security analysis. At the execution layer, Ethereum's single-threaded sequential execution cannot utilize multi-core CPU capabilities. Existing parallel solutions such as Block STM (optimistic concurrency control based on software transaction memory) and Solana (static scheduling, transaction pre-declaration of read / write account sets) improve performance, but still face performance instability and rollback overhead issues in high-frequency conflict scenarios common in stablecoins involving hot accounts.

[0029] One related technology offers BFT consensus protocols and improved versions for high-performance stablecoins or general-purpose assets, with HotStuff and its variants being typical examples. HotStuff and its improved version, Fast HotStuff, are representative BFT consensus protocols for stablecoin scenarios. HotStuff employs a chained pipeline design, reducing view switching complexity to linear through three rounds of voting, thus solving the problem of high switching overhead in PBFT. Fast HotStuff further reduces latency by optimizing submission rules, enabling block confirmation within two rounds of communication. However, these protocols still face performance bottlenecks in large-scale, high-frequency stablecoin payment scenarios.

[0030] First, these protocols generally employ a single leader responsible for proposing blocks in each view. In high-concurrency transaction scenarios, the single leader's transaction collection and packaging capabilities, network sending capabilities, and signature aggregation processing capabilities all become bottlenecks in system throughput. Even with pipelined techniques to overlap the execution of multiple views, the overall throughput is still subject to a hard constraint determined by the performance limit of a single node, making it difficult to scale linearly with network size.

[0031] Secondly, these protocols often employ a one-person-one-vote voting rule to ensure security, without distinguishing the size or weight of participating nodes' interests. In stablecoin scenarios, this often fails to reflect a governance and economic weight structure, necessitating additional staking and penalty mechanisms to compensate for economic security in practice.

[0032] Furthermore, a mechanism for multiple proposers to produce blocks concurrently has not been introduced for specific high-value assets such as stablecoins. Simply allowing multiple leaders to propose blocks simultaneously without strict order constraints and certificate rules could lead to frequent forks and even security issues. Existing technologies are mostly single-leader protocols, and even with significant optimizations in communication rounds and view switching, their throughput is still insufficient to meet the demands of future global stablecoin settlement networks.

[0033] Finally, while some implementations of these protocols can reduce confirmation latency to two rounds of communication, complex view switching and proof propagation processes are still required on abnormal paths, such as when the leader fails or a network partition occurs. For global stablecoin networks with large node scales or complex network environments, these mechanisms may significantly amplify confirmation latency under adverse conditions, impacting the end-user experience.

[0034] Another related technology refers to parallel execution schemes targeting the blockchain execution layer, represented by Block-STM and related Optimistic Parallel Execution (OPE) technologies. Compared with the characteristics of stablecoin transaction loads, existing parallel execution engines have some obvious shortcomings. Stablecoin networks in real-world payment scenarios typically exhibit characteristics of high concurrency, high hotspots, and low latency tolerance. That is, a large number of transactions occur frequently between a few popular addresses, leading to a high probability of read-write conflicts, while end users are very sensitive to confirmation delays.

[0035] In such scenarios, traditional Block-STM solutions often encounter frequent rollback issues. When many transactions contend for the same hot account or counter, later-executed transactions can easily read older versions that have already been updated by concurrent transactions, thus being judged as conflicting and rolled back during the verification phase. This rollback not only wastes CPU computing resources but can also trigger cascading rollbacks, meaning that a rollback of one transaction can cause multiple subsequent transactions that depend on it to also need to roll back, thereby multiplying the execution time. In extreme conflict situations, the performance of Block-STM may even degrade to below that of single-threaded sequential execution.

[0036] Furthermore, existing solutions are insufficient in suppressing hotspot write conflicts. For certain stablecoin businesses, such as large merchant receiving addresses or custodian addresses receiving a massive number of small transfers in a short period, traditional multi-version and rollback mechanisms are difficult to handle efficiently. This is because multiple transactions must continuously write to and update the same balance or counter, making conflicts almost inevitable, without specific state sharding or partitioned counter designs to reduce the probability of conflicts. Therefore, in real-world business deployments, blockchain operators often have to introduce additional sub-account or sub-address designs to circumvent this problem, thereby increasing system complexity and operational costs.

[0037] Therefore, existing general-purpose public blockchains and some dedicated stablecoin blockchains are no longer able to meet the business needs of the next stage in terms of performance, efficiency and stability.

[0038] To address the aforementioned issues, this invention aims to propose a high-performance parallel blockchain method and system for stablecoins, employing a systematic design from both the consensus and execution layers. On one hand, the multi-proposer pipelined parallel Byzantine fault-tolerant protocol MP3-BFT (also known as the multi-proposer pipelined parallel protocol), or simply MP3-BFT protocol, allows multiple proposers to package transactions concurrently within the same height. Finality is determined in two rounds of voting through VRF lottery and a two-phase commit mechanism, achieving near-linear throughput scaling. On the other hand, the lock-free predictive-aware parallel execution engine LEAP, combined with multi-version state and transaction prediction mechanisms, achieves near-linear acceleration in low-conflict regions and ensures that each transaction is retried at most once in high-conflict regions, avoiding numerous rollbacks and livelocks. Simultaneously, a Partitioned-Counter state sharding mechanism is proposed, splitting counters such as balances of hot accounts into multiple sub-slots, significantly reducing the probability of write conflicts, thus maintaining superior throughput performance compared to traditional parallel execution engines even in extreme hotspot scenarios. Furthermore, while taking into account the Byzantine fault tolerance threshold and system scalability, it can fully leverage the parallel capabilities of multi-core and multi-node systems in both consensus and execution dimensions to achieve sub-second finality and comprehensive performance of hundreds of thousands of TPS.

[0039] The following further elaborates on the preferred embodiments of the present invention in conjunction with the accompanying drawings.

[0040] As Figure 1 shown, this embodiment provides a high-performance parallel blockchain method for stablecoins, including the following steps: Step S1, perform hierarchical planning on the system architecture, including a consensus layer, an execution layer, a protocol layer, a native service layer, and an application layer from bottom to top; Step S2, establish a consensus cluster composed of n nodes. Among them, the number of Byzantine nodes f satisfies the security threshold of f < n / 3. Elect a proposer through the random lottery mechanism of the verifiable random function VRF, and achieve parallel block production by multiple proposers and pipelined voting in combination with role settings; Step S3, construct a legal certificate QC corresponding to the batch through aggregate signature under the Byzantine Fault Tolerance (BFT) framework, package multiple batches using a chained block structure, implement a two-round voting submission rule, and establish a locking rule for the legal certificate highQC of the parent block; Step S4, implement the consensus process through a lottery stage, a proposal stage, a voting stage, and a submission stage; Step S5, based on a key-value storage model with multiple versions of states, maintain a multi-version linked list for each state key, record the transaction number and retry sequence number, and maintain two atomic indexes in the execution layer. Combine working threads to dynamically switch between executing transactions and verifying transactions; Step S6, adopt optimistic parallel control and multi-version state management. Working threads obtain transaction numbers through atomic increment operations and execute business logic, record read-write sets and reserve write positions in the multi-version storage; During the verification stage, review the consistency of the read set versions in the order of the global verification index, and introduce an Estimate marking mechanism to predict and prompt conflicting versions; Combine a limited retry strategy, increment the execution index and verification index through atomic operations, and use a lock-free linked list to maintain the waiting queue and dependencies, realizing the scheduling and execution of the LEAP execution engine, where the LEAP execution engine refers to a lock-free prediction-aware parallel execution engine; Step S7, execute a state sharding mechanism in a high-concurrency hotspot scenario. For each high-frequency access account, logically divide its balance state into several sub-slots internally, and each sub-slot corresponds to an independent counter; Step S8, establish an interface constraint and coordination mechanism between the consensus layer and the execution layer.

[0041] In step S1 of this embodiment, a layered architecture separating the consensus layer and the execution layer is adopted, and a protocol layer, native service layer, and application layer are further superimposed on top to form a five-layer system from bottom to top. The bottom layer is the consensus layer, which is responsible for replicating transaction logs and generating a deterministic total order of transactions under the Byzantine fault-tolerant partially synchronous network model, ensuring the consistency of the blockchain state machine replication. Above the consensus layer is the execution layer, which is responsible for interpreting and executing transactions according to the transaction order determined by the consensus, completing the transformation of the on-chain state from the old version to the new version. The execution layer adopts the lock-free predictive awareness parallel execution mechanism proposed in this invention, namely the LEAP execution engine, and combines a multi-version storage structure and transaction scheduling strategy to achieve efficient parallelism.

[0042] Above the consensus and execution layers lies the protocol layer, which provides specialized protocol primitives and system functions for stablecoin business scenarios. These include multi-currency fee models, transaction privacy protection primitives, cross-chain interoperability modules, and a maximum extractable value (MEV) suppression mechanism. Through a series of verifiable rules, the protocol layer ensures that stablecoin issuance, transfer, freezing, and redemption operations have consistent semantics and compliance attributes on the blockchain.

[0043] Moving upwards is the native service layer, which integrates frequently used smart contract services on top of the basic primitives provided by the protocol layer. These services include invoice payment, bulk payroll disbursement, foreign exchange and exchange rate matching, and fund escrow, enabling upper-layer application developers to directly call these services to build business logic and reduce redundant development and error risks.

[0044] The top layer is the application layer, which carries various payment, settlement, and financial innovation applications, including cross-border payment applications, on-chain foreign exchange settlement, real-world asset delivery and delivery versus payment (RWA DvP), decentralized finance (DeFi) protocols, and fund management platforms for enterprises or institutions. The application layer interacts with the native service layer and protocol layer, leveraging the sub-second confirmation and high throughput capabilities provided by the underlying high-performance stablecoin chain to deliver high-quality payment and settlement services to end users.

[0045] In the aforementioned system, the design of the consensus layer and execution layer is crucial for performance improvement and is also one of the inventive points of this invention. Specifically, this embodiment proposes a multi-proposer pipelined parallel Byzantine fault-tolerant protocol MP3-BFT (steps S2 to S4) and a LEAP execution engine (step S6) for these two layers, and further enhances performance in hotspot scenarios through a Partitioned-Counter state sharding mechanism (step S7). The following will elaborate on these aspects through steps S2 to S8 of the collaborative process.

[0046] Step S2 in this embodiment is used to implement the consensus layer system model and role setting. Preferably, it includes steps S201 to sub-step S205.

[0047] The MP3-BFT protocol of the consensus layer in this embodiment runs under the partially synchronous network model proposed by Dwork-Lynch-Stockmeyer. There is an unknown global stable time GST in the system. After the global stable time GST, there is a known upper bound Δ for the message transmission delay between any two correct nodes. Under this model, the protocol needs to provide liveness within a finite time after the global stable time GST while ensuring security, that is, continuously generate new confirmed blocks.

[0048] In terms of the failure model, the system consists of several nodes participating in consensus, denoted as set V. In step S201, a consensus cluster consisting of n nodes is established, where at most f nodes are Byzantine nodes, and a mathematical constraint relationship of f < n / 3 is established as the boundary condition for security verification. The MP3-BFT protocol refers to the multi-proposer pipelined parallel Byzantine fault tolerance protocol, also known as the multi-proposer pipelined parallel protocol. Byzantine nodes can exhibit any malicious behavior, including sending inconsistent information, refusing to vote, attempting double proposals, etc.; correct nodes will strictly follow the behavior specified by the protocol and follow unified rules when verifying messages and generating votes. The protocol of the present invention guarantees security and liveness under this failure bound.

[0049] In terms of role setting, to ensure the efficient operation of the protocol and reduce communication complexity, this embodiment introduces several different roles logically for nodes. The proposer is responsible for selecting transactions from the transaction pool and packing them into a proposal batch within a given height or view. In step S202, the proposer is elected through the random lottery mechanism of the verifiable random function VRF; at each height, several nodes may be selected as proposers; each proposer can independently propose one or more batches at the current height, thereby achieving multi-proposer parallel block production within the same height.

[0050] The voter is the set of nodes participating in verifying and voting on the proposal batch. In step S203, all members of the consensus committee simultaneously act as voters. After each voter receives a proposal, it verifies its legality, transaction correctness, and internal batch conflicts, and votes in favor or against the batch of the proposal according to the verification results; to ensure BFT security, a batch that obtains at least 2f + 1 nodes' votes in favor is regarded as obtaining a quorum certificate QC; the quorum certificate QC is also called a legal certificate.

[0051] The aggregator is responsible for collecting votes and generating legal certificates. To simplify the design and avoid additional election costs, in step S204, the proposer with the smallest number is selected as the aggregator for each height. When the aggregator detects that a batch at the current height has already obtained a legal certificate QC that has reached a preset threshold, it packages the verified batch into the final block for that height and broadcasts it to the entire network. The preset threshold refers to the batch threshold set in advance within a specified time period. The specified time and the preset threshold can be customized and adjusted according to actual needs.

[0052] In step S205, all full nodes act as executors, responsible for executing transactions locally in the order of the final blocks and updating their local states. During execution, all executors replay transactions on the same state machine to obtain a consistent state, achieving consistency semantics. After the consensus layer determines the block order, the execution layer performs parallel scheduling and execution according to this order to ensure the consistency of state replication.

[0053] Through the aforementioned role division, at the consensus layer, this embodiment achieves a multi-proposer parallel block production mechanism and a pipelined voting process while ensuring that the BFT consensus security threshold is not lowered, effectively breaking the throughput bottleneck of traditional single-leader BFT protocols. Simultaneously, the use of VRF lottery and Bernoulli random sampling ensures the fairness and unpredictability of the proposer election process, reducing the risk of Sybil attacks. The parallel packaging of transactions by multiple proposers at the same height allows the system to fully utilize network bandwidth and node computing power, theoretically enabling near-linear throughput scaling with the number of nodes.

[0054] In this embodiment, step S3 is used to define block submission rules. Preferably, it includes steps S301 to S305.

[0055] This embodiment adopts the concept of Quorum Certificate (QC) in the BFT protocol, but makes some adjustments to the construction method. For a certain proposal batch, when the aggregator receives affirmative votes from different voters, these votes contain the hash of the proposal batch and the voter's signature. In step S301, when the aggregator collects at least 2f+1 valid signatures from different nodes, it uses an aggregate signature algorithm to compress these valid signatures into a constant-size aggregate signature, and combines this aggregate signature with the hash value of the corresponding batch to form the Quorum Certificate (QC) for that batch. Unlike traditional BFT, this embodiment allows multiple batches that have obtained quorum certificates to exist at the same height, and the final block is constructed by the aggregator based on the set of valid batches it has collected.

[0056] To describe the block relationships in the case of multiple proposers producing blocks in parallel, this embodiment uses a chained block structure. In step S302, at each height, the aggregator packages several batches that have obtained a Validation Certificate (QC) into a single block. The block header includes metadata such as the hash value of the previous block, a list of batch hashes contained in the current block, the QC of each batch, the height, and the view number. This design maintains the simplicity of a chained structure while accommodating the feature of multiple proposal batches being confirmed in parallel at the same height.

[0057] Regarding the submission rules, this embodiment modifies the HotStuff protocol series, optimizing the traditional three-stage proposal-voting-submission process into a two-round voting process for final determination. Specifically, in step S303, a two-round voting mechanism is adopted. The first voting stage is used for initial confirmation of the proposal batch, and the second voting stage is used to confirm the block formed in the previous round. When the second round of voting achieves the statutory certificate QC, the corresponding block is considered finalized. Through a multi-view pipeline approach, this embodiment executes proposals and votes overlapping in consecutive views, making the submission delay of each block approximately two round-trip times, close to 2Δ, which significantly reduces the confirmation time compared to the traditional three-stage BFT protocol. This is of great significance for stablecoin payment scenarios that are extremely sensitive to latency.

[0058] To prevent forks and conflicts, this embodiment sets strict parent-child pointer constraints and certificate locking rules in the block submission rules. In step S304, when each proposer generates a new batch, it references the currently known highest-height or highest-view valid block as the parent block, and this parent block holds the parent block's legal certificate highQC. When voting on a proposal, voters check whether the parent block's legal certificate highQC referenced by the proposal satisfies a monotonically increasing locking condition, i.e., it will not vote on a forked chain with a lower view than the already locked one. If the condition is met, a vote is cast in favor; otherwise, voting on that forked chain is rejected. Through this locking rule, it can be ensured that the final submitted blockchain will not experience a security fork, thus theoretically guaranteeing security attributes.

[0059] In a multi-proposer environment, different proposers may submit proposals for different transaction sets at the same height. To address this issue, in step S305 of this embodiment, when multiple proposers submit proposals for different transaction sets at the same height, each batch is allowed to form an independent legal certificate (QC). The aggregator adheres to the following constraints when constructing the final block: batches with conflicting transaction content are excluded, and it must be ensured that all batches, as a whole, do not disrupt the execution consistency of subsequent heights. The aggregator employs deterministic sorting and filtering strategies when generating blocks. For example, sorting by proposal timestamp, proposer weight, or batch hash value ensures that the content of the blocks ultimately formed by different nodes under the same input is completely consistent.

[0060] Through the above design, the MP3-BFT protocol in this embodiment implements a multi-proposer parallel block production mechanism at three levels: legal certificates, block structure, and block submission rules.

[0061] like Figure 2 As shown, step S4 in this embodiment is used to implement the consensus process, and preferably includes steps S401 to S406.

[0062] In step S401, during the lottery phase, candidate accounting nodes use a verifiable random function (VRF) to locally compute the seed information at the current height, obtaining a random output and corresponding proof. Based on the random output, each node determines its winning count at the current height using a Bernoulli cumulative probability function, thus determining the number of proposal batches it can propose within that height. The winning count is proportional to the amount of tokens staked by the node or its accounting weight, ensuring that more contributing nodes receive a higher probability of proposing, while maintaining the system's anti-Syllabic properties. If a node's winning count at a certain height is greater than zero, the node broadcasts its random output and proof, declaring itself a winner at the current height and a proposer. Unselected nodes wait for the next round.

[0063] Step S402, during the proposal phase, each successful proposer (in...) Figure 2 In the process (represented by proposer i), a set of unpacked transactions is first selected from the local transaction pool. The transactions are then divided into one or more batches according to a preset number, i.e., each batch contains a specified number of transactions (which can be customized and adjusted). The proposer then calculates the hash value for each batch, generates a proposal message containing the height, view, parent block hash value, and batch content, and adds a randomly output proof (VRF proof) and proof of the number of times the proposal has been won, so that other nodes can verify its proposal qualification. The proposal message is broadcast to all voters through a peer-to-peer network.

[0064] Step S403, during the voting phase, voters (corresponding to...) Figure 2Upon receiving a batch of proposals at a certain height, the Voters' Committee verifies the proof of the randomly generated proposal to confirm the proposer's eligibility, including verifying the VRF proof to confirm that the proposer has indeed been selected at the current height; checks the legality of the batch structure and transaction format, such as the correct signature of each transaction, sufficient balance, and compliance with basic format specifications; and checks whether there is a direct conflict between this batch and other batches already received at the same height. Once the checks are passed and there are no direct conflicts, a vote (also known as a ballot) containing the batch hash value and the voter's signature is generated and sent to the aggregator designated at the current height.

[0065] In step S404, during the submission phase, the aggregator continuously accumulates the number of affirmative votes and corresponding signatures for each batch. When a batch receives at least 2f+1 affirmative votes, it uses the aggregate signature algorithm to construct its legal certificate QC and broadcasts it. After at least one batch obtains a legal certificate QC at the current height, the aggregator packages these batches according to predetermined rules, constructs a block header containing the parent block hash value, a batch list, and the legal certificate QCs for each batch, and broadcasts it to the entire network. After receiving the block, each node confirms that the transaction set at this height has been finalized and triggers the execution layer to update the state, i.e., the batch is executed by the executor. Preferably, if a timeout occurs, a new proposal is started through a backup aggregator. Backup aggregators can be configured according to actual conditions, such as selecting backup aggregators by number to ensure that all nodes have a common understanding of the backup aggregators and avoid disputes; or based on a rotation mechanism, etc.

[0066] To fully utilize pipeline parallelism, in step S405 of this embodiment, the four stages from step S401 to step S404 are executed overlapping between different heights. Specifically, while the voting stage is underway at height h, the lottery and proposal stages can be run in advance at height h+1, thus allowing the block generation and confirmation processes to overlap continuously in time, significantly reducing the overall confirmation delay. Under normal network conditions, the MP3-BFT protocol can complete block submission within two rounds of voting, making the delay from proposal initiation to final confirmation approximately 2Δ.

[0067] Step S406: When an aggregator fails to collect enough votes or construct a valid block within the specified time, the current view aggregator is deemed invalid. At this point, the aggregator role is automatically transferred to the next candidate proposer. The new aggregator collects votes from other proposers at the same height and completes block construction within a new time window. Failure to collect enough votes means that the number of votes exceeds a pre-set threshold, which can be adjusted according to actual needs. In this way, as long as there is at least one correct proposer and an available aggregator within a sufficiently long period, the system can resume the consensus process and ensure protocol liveness.

[0068] Step S5 in this embodiment is used to implement the execution layer system model and state management, and preferably includes steps S501 to S505. In this embodiment, the execution layer needs to maximize the use of multi-core parallel execution of transactions while ensuring consistency with the total transaction order established by the consensus layer. To this end, this embodiment introduces a key-value storage model based on multi-version state and a lock-free task scheduling and state update mechanism.

[0069] Step S501: After each block is determined by the consensus layer, the execution layer sequentially numbers the transactions within the block from 0 to N-1, where N represents the total number of transactions in the block. Each transaction is treated as a state machine operation, which includes reading and writing several state keys in the state tree. The read set of the i-th transaction is denoted as R_i, and the write set is denoted as W_i. The state key is abbreviated as key. The execution layer needs to ensure that after the final commit, the sequence of state changes of all transactions is completely equivalent to the execution in ascending order of the numbers.

[0070] Step S502: The state storage adopts a multi-version key-value storage structure. A multi-version linked list is maintained for each state key. Each version entry in the multi-version linked list records the transaction number, retry number, and write value for that state key. The retry number distinguishes different versions generated in multiple executions of the same transaction. The multi-version linked list is stored in chronological or commit order, with the latest committed version at the head. Uncommitted intermediate versions are distinguished by special markers to achieve lock-free access to the state history. The multi-version linked list refers to the list of state change versions, used to store the historical version history of each state key, including the transaction number, retry number, and write value.

[0071] To support low-latency parallel execution, in step S503 of this embodiment, two atomic indices are maintained at the execution layer to indicate the current minimum transaction number to be executed and the minimum transaction number to be verified and submitted, respectively. Each worker thread dynamically switches between executing and verifying tasks during runtime. In step S504, the conditions for worker threads to dynamically switch between executing and verifying transactions are set. If there are transactions that have been executed but not yet verified, they will participate in the verification work first; if there are no transactions to verify, new transactions will be taken from the sequence of unexecuted transactions for execution. In step S505, during the execution phase, when a worker thread is executing a transaction, if it finds that the state key to be read currently only has an estimated version or has pending dependencies, it will actively suspend the current transaction and release computing resources; it will automatically wake up and resume execution after the dependencies are satisfied, thus avoiding wasting CPU resources by continuing to calculate on the basis of obvious conflicts.

[0072] Through the aforementioned multi-version state design and task scheduling mechanism, the execution layer of this invention can advance the execution and verification processes of multiple transactions in parallel while ensuring strict sequential semantics, and at the same time control the number of rollbacks and avoid livelock, thereby achieving efficient processing of stablecoin transaction load.

[0073] In this embodiment, step S6 is used to implement the scheduling and execution process of the lock-free predictive awareness parallel execution engine (i.e., LEAP execution engine), and preferably includes steps S601 to S604.

[0074] The LEAP execution engine proposed in this embodiment refers to Lock-free Estimate-Aware Parallel Execution, also known as a lock-free prediction-aware parallel execution engine. It is a lock-free parallel scheduling algorithm based on optimistic parallel control and multi-version state management. The design goal of the LEAP execution engine is to achieve near-linear acceleration in low-conflict scenarios, and to control the number of rollbacks within a limited range in high-conflict hotspot scenarios through estimation and concession mechanisms, thereby maintaining the stability and predictability of execution performance. For medium-to-high conflict regions, the LEAP execution engine's Estimate mechanism can issue early warnings to subsequent transactions as soon as conflicts appear, avoiding a large amount of unnecessary computation and thus controlling rollback overhead within a relatively stable range. Experimental results show that the parallel efficiency of the LEAP execution engine approaches its theoretical limit in low-conflict regions, still provides significantly better throughput performance than Block-STM in high-conflict situations, and is several times higher than pure serial execution in extremely serialized conflict scenarios.

[0075] In the overall process, the LEAP execution engine treats transactions within a block as a sequence of transactions that need to be committed in order. In step S601, during the execution phase, all worker threads retrieve the next transaction number to be executed from the global execution index through an atomic increment operation; for example, an idle thread checks whether the verification index is less than the execution index. If so, the transaction at the verification index is verified, and the process jumps to step S602. When a thread executes a transaction, it records the version information corresponding to each status key read by the transaction and reserves a position in the storage of the multi-version linked list for the status keys in the write set. After the business logic of executing the transaction is completed, the write result is recorded as a new version, marking the transaction as an execution completed state and a pending verification state (i.e., not yet committed).

[0076] Preferably, if the verification index is not less than the execution index (i.e., no transaction can be verified), then it is further determined whether the execution index is less than the total amount. If so, the EXEC flag is set and the transaction is executed through the virtual machine, the read set version is recorded, and a write position is reserved. If not, the transaction waits for the active counter to reach 0. In this way, a new transaction is executed through a branch.

[0077] In step S602, during the verification phase, the completed transactions are checked according to the order of the global verification index. For transactions in the pending verification state, the thread reviews the read set version recorded during execution to determine whether these versions are still the latest versions under the currently visible snapshot. If the read set version is consistent with the version at execution, it means that the transaction has not been affected by concurrent transactions, and the write version is committed. At this time, the write version of the transaction is marked as committed, and all waiting transactions that depend on this version are woken up. Otherwise, if it is found that a read key has been updated by a subsequent transaction, it means that the current transaction has read expired data and must be rolled back and retried. The write version is first marked as the Estimate state and a rollback retry is triggered. Subsequent transactions are suspended and wait until the transaction responsible for the Estimate state completes the retry and commit. The Estimate state refers to the conflict warning mark state.

[0078] Unlike traditional optimistic parallel execution schemes, the LEAP execution engine introduces an Estimate marking mechanism to predict and alert users to versions that may conflict. When a transaction is identified as Aborted during the verification phase due to a conflict, this embodiment does not simply delete the write versions generated during the execution phase. Instead, it marks these write versions as Estimate. If a subsequent transaction, during execution, attempts to read the version chain of a key and finds the latest version in the Estimate state, it can determine that the state is unstable and has potential conflicts. In this case, the subsequent transaction will not continue execution but will suspend, waiting for the transaction responsible for that Estimate version to complete its retry and commit. In this way, the LEAP execution engine exposes potential conflicts to subsequent transactions in advance, preventing them from performing a large amount of unnecessary computation on an obviously unstable foundation.

[0079] In step S603, during the retry strategy phase, a limited retry limit is set for each transaction. The default limit is a single retry limit. When a transaction is aborted due to a read set version conflict after its first execution, the transaction is suspended before the second execution, waiting for all related dependent transactions to complete and commit. This ensures that the same conflict will not be encountered again during the second execution. Since the Estimate version has already indicated the location of hotspot conflicts, the system can avoid these unstable states during the second execution, thus greatly reducing the probability of repeated aborts. If the transaction still fails verification on the second attempt, it means that the transaction cannot succeed under the current total order. It is marked as failed and processed according to the upper-layer protocol strategy, thereby ensuring that the number of aborts for each transaction has a clear upper bound and avoiding livelock.

[0080] In terms of task scheduling and state updates, the LEAP execution engine employs lock-free data structures and atomic operations to avoid severe lock contention bottlenecks in high-concurrency scenarios. In step S604, during the task scheduling and state update phase, worker threads increment the execution index and verification index using atomic operations, and maintain the waiting queue and transaction dependencies using a lock-free linked list. When a transaction commits or terminates, the worker thread traverses its transaction dependencies and updates the waiting transaction status to ready, allowing it to re-enter the execution phase. Since the entire process does not require a global mutex lock, the system can provide each thread with ample execution opportunities in a multi-core environment, further improving parallel efficiency. The lock-free linked list refers to the task to-do list, also known as the execution layer's task scheduling list, used to manage the transaction waiting queue and dependencies. Its content includes the pending transaction ID and dependency pointers.

[0081] Through the above mechanism, the LEAP execution engine can enable most transactions to be successfully submitted after one execution in low-conflict scenarios, so as to achieve a near-linear parallel speedup. In high-conflict hotspot scenarios, it relies on Estimate hints and limited retry strategies to limit repeated aborts to a limited range, avoiding the cascading rollback phenomenon common in Block-STM. Even in extreme cases, the throughput is still significantly better than sequential execution.

[0082] In this embodiment, step S7 is used to implement the Partitioned-Counter state sharding mechanism in high-concurrency hot spot scenarios, and preferably includes steps S701 to S704.

[0083] To address the issue of highly concentrated write hotspots in stablecoin payment networks, this embodiment proposes a Partitioned-Counter state sharding mechanism at the execution layer state model to reduce the probability of concurrent write conflicts to the same account or other frequently accessed objects. This state sharding mechanism is particularly suitable for balances, counters, and other frequently incremented or decremented numerical states.

[0084] In traditional state models, each account's balance is represented by a single counter, and all operations that increase or decrease that balance directly read and write to the same state key. In scenarios where a large number of transfers are concentrated and point to the same receiving address, different transactions must perform write operations on the same balance key, resulting in a write-write conflict probability approaching 100%. In parallel execution engines, this causes numerous conflicts and rollbacks, significantly limiting overall throughput.

[0085] In step S701 of this embodiment, for each high-frequency access account, its balance status is internally logically divided into p independent sub-slots, where p is a natural number. Each sub-slot corresponds to an independent counter and is stored in a different status key, so that the write operation of the balance status is distributed to multiple physically isolated storage units.

[0086] In step S702, for a transfer transaction, when updating the balance of the payee or payer, the target sub-slot number to be hit in this update is determined according to the transaction characteristics. The transaction characteristics include at least one of the sender address hash value, transaction sequence number and stable allocation function.

[0087] Step S703: Write operations are performed only on the target sub-slot determined in step S702. The write operation follows a multi-version storage mechanism, and a new version is appended to the version chain corresponding to the target sub-slot.

[0088] In step S704, when reading the total balance of the account, traverse all sub-slots of the account, sum the count values ​​of each sub-slot, and return the sum.

[0089] In this way, the probability of multiple transactions landing in the same sub-slot when transferring funds to the same account simultaneously is significantly reduced. Assuming an account's balance is divided into p sub-slots, for randomly distributed transactions, the probability of any two transactions writing to the same slot simultaneously is approximately 1 / p, whereas in the traditional model this probability is 1. By choosing an appropriate value for p, such as 4 or 8, the probability of write conflicts can be significantly reduced while keeping read operation burden and storage overhead acceptable, thereby shortening the length of the concurrent conflict chain and improving parallel execution performance.

[0090] It's worth noting that the advantages of the Partitioned-Counter state sharding mechanism are even more pronounced within the LEAP execution engine framework. Because write operations in each sub-slot become relatively independent, different transactions no longer directly conflict when operating on different sub-slots, thus avoiding frequent Abort and Estimate flag triggers. Combined with the lock-free parallel execution framework of the LEAP execution engine, this mechanism effectively reduces the number of Aborts and rollback overhead. Even in extreme hotspot scenarios, a large number of transactions that previously had to be executed serially can now be distributed across multiple sub-slots for concurrent execution, significantly improving overall system throughput. Even in extreme hotspot scenarios such as a single merchant handling millions of writes per day, it maintains high throughput and relatively smooth latency, providing robust technical support for stablecoin commercial payment networks. Based on the evaluation of simulation experiments and prototype implementations according to this invention, the Partitioned-Counter state sharding mechanism with 4 sub-slots can reduce the probability of high-frequency account write conflicts by more than 75%, still resulting in approximately a 42% throughput improvement in hotspot scenarios.

[0091] It is important to emphasize that the Partitioned-Counter state sharding mechanism is implemented only within the execution layer's internal state structure, remaining completely unchanged from the account semantics provided by the upper application and protocol layers. The application layer still sees a unified account balance; however, concurrency performance is improved through multi-slot sharding in the underlying storage, ensuring the mechanism's transparency and compatibility with the upper layers.

[0092] In this embodiment, step S8 is used to ensure the coordination and sequential consistency between the consensus layer and the execution layer, and preferably includes step S801 from step S804.

[0093] To ensure that the entire blockchain system maintains strict sequential consistency while simultaneously employing the MP3-BFT protocol and the LEAP parallel execution engine, this embodiment establishes clear interface constraints and coordination mechanisms between the consensus layer and the execution layer.

[0094] The consensus layer MP3-BFT protocol is responsible for total ordering of transactions. In step S801, after multiple batches are generated in parallel within the same height and each batch forms a legal certificate (QC), the aggregator sorts all batches according to deterministic rules, assigning a unique global number to each transaction. These deterministic rules include at least one of the proposal timestamp, proposer weight, and batch hash value. This global number is a global sequence number, completely consistent across all participating nodes, and remains unchanged once a block is committed and confirmed. The execution layer LEAP execution engine uses this total order as the sole reference for the transaction sequence and does not reorder transactions; therefore, the final state result has verifiable determinism.

[0095] In step S802, at the execution layer, after the LEAP execution engine executes transactions in parallel, transactions are submitted one by one in ascending order of global ID. This ensures that when the k-th transaction is submitted, all transactions with global IDs less than k have been submitted, and all transactions with global IDs greater than k have not been submitted; k is a natural number. Through this monotonic submission strategy, the LEAP execution engine guarantees that the final state result is completely consistent with the transaction sequence determined by consensus, avoiding the non-determinism caused by parallel execution.

[0096] In designing the Estimate flag and transaction retry strategy, this embodiment always requires that conflict detection and rollback decisions rely solely on the already determined transaction states without altering the total order relationship between transactions. In step S803, when each transaction is aborted and retried (i.e., re-executed) due to a read set version conflict, its position in the global number remains unchanged, and it attempts to read the latest visible state again in the same order. This design ensures that all optimizations performed by the LEAP execution engine do not semantically change the execution order of transactions.

[0097] Step S804: The consensus layer and execution layer are decoupled through a unified block and state interface. When the consensus layer submits a block, it provides the execution layer with a block structure containing the transaction sequence and corresponding metadata. After completing the submission of all transactions and state updates, the execution layer returns the latest state root and related digest to the consensus layer for verification of subsequent blocks. This interdependent yet modularly separated design allows the invention to flexibly evolve the execution layer while ensuring security and consistency, achieving more efficient parallel execution and state optimization without modifying the core logic of the consensus protocol.

[0098] Through the above collaborative design, this embodiment constructs an end-to-end consistency guarantee mechanism, enabling the system to still meet the core requirement of strong consistency in blockchain under the dual optimization of multi-proposer parallel consensus and lock-free predictive awareness parallel execution.

[0099] In summary, this embodiment first plans the system architecture in layers, adopting a layered architecture that separates the consensus layer and the execution layer. It then uses consensus protocols and role settings to achieve parallel block production by multiple proposers and pipelined voting, enabling the system to have linearly scalable throughput. Next, it defines block submission rules and consensus processes. While ensuring strict sequential semantics at the execution layer, it advances the execution and verification processes of multiple transactions in parallel, maintaining a constant security threshold. The locking rules of the parent block's legal certificate, highQC, ensure no fork submissions, guaranteeing system security and achieving efficient processing of stablecoin transaction loads. Then, it implements the scheduling and execution of the LEAP execution engine, effectively avoiding significant rollback and retrieval overhead. In high-concurrency hotspot scenarios, it implements a state sharding mechanism, thereby reducing the probability of write conflicts and significantly improving system performance with relatively low storage and read amplification costs. Finally, it establishes interface constraints and coordination mechanisms between the consensus layer and the execution layer to ensure sequential consistency, maximizing the system's parallelism and pipelined nature.

[0100] This embodiment proposes a high-performance parallel blockchain system architecture for stablecoins from two key dimensions: consensus layer and execution layer. Based on this architecture, it implements the MP3-BFT multi-proposer pipeline parallel protocol, LEAP execution engine, and Partitioned-Counter state sharding mechanism, which brings significant benefits overall.

[0101] This embodiment also provides a high-performance parallel blockchain system for stablecoins, which employs the high-performance parallel blockchain method for stablecoins as described above, and includes: The layered planning module plans the system architecture in layers, including the consensus layer, execution layer, protocol layer, native service layer, and application layer from bottom to top. Consensus and Role Setting Module: Establish a consensus cluster composed of n nodes, where the number of Byzantine nodes f satisfies the security threshold of f < n / 3. Elect proposers through the random lottery mechanism of the Verifiable Random Function (VRF), and implement parallel block production by multiple proposers and pipelined voting in combination with role setting. Block Submission Rule Module: Under the Byzantine Fault Tolerance (BFT) framework, construct a legal certificate QC corresponding to the batch through aggregate signature, package multiple batches using a chained block structure, implement a two-round voting submission rule, and establish a locking rule for the legal certificate highQC of the parent block. Consensus Module: Implement the consensus process through a lottery phase, a proposal phase, a voting phase, and a submission phase. Execution and State Management Module: Based on a key-value storage model with multiple versions of states, maintain a multi-version linked list for each state key, record transaction numbers and retry sequence numbers, and maintain two atomic indexes at the execution layer. Dynamically switch between executing transactions and verifying transactions in combination with worker threads. Scheduling and Execution Module of the LEAP Execution Engine: Adopt optimistic parallel control and multi-version state management. Worker threads obtain transaction numbers through atomic increment operations and execute business logic, record read-write sets, and reserve write positions in the multi-version storage.复查读集合版本的一致性,并引入Estimate标记机制对冲突版本进行预测提示;结合有限重试策略,通过原子操作递增执行索引和验证索引,并采用无锁链表维护等待队列和依赖关系,实现LEAP执行引擎的调度和执行。 State Sharding Module: Execute the state sharding mechanism in high-concurrency hotspot scenarios. For each high-frequency access account, logically divide its balance state into several sub-slots internally, and each sub-slot corresponds to an independent counter. Collaboration Module: Establish interface constraints and collaboration mechanisms between the consensus layer and the execution layer.

[0102] At the overall system level, this embodiment provides a good integration foundation for functions such as cross-chain interoperability, privacy protection, and MEV suppression required in the stablecoin scenario through a consensus-execution separation architecture, supplemented by a protocol layer and a native service layer. The MP3-BFT protocol fully considers the combined security with confidential transactions and cross-chain packaging modules during design, so that the introduction of these extended functions does not weaken the consensus security. Execution layer mechanisms such as the LEAP execution engine and the Partitioned-Counter state sharding mechanism are transparent to upper-layer applications during implementation, without changing the logical semantics of stablecoin assets and accounts, and thus can be seamlessly docked with existing stablecoin contracts and application ecosystems.

[0103] It should be noted that there is an unclear part in the translation of item . The original text seems to be incomplete or has some typos. The translated part is as accurate as possible based on the existing content. You may need to check and correct the original text for a more precise translation.More importantly, the high-performance stablecoin blockchain architecture provided in this embodiment offers a solid underlying foundation for the future digitization of fiat currencies such as digital dollars and digital yuan, as well as the construction of a large-scale global stablecoin settlement network. By directly embedding high-performance consensus and parallel execution capabilities at the protocol layer, this embodiment facilitates high-frequency fund transfers and real-time clearing across regions and institutions, reducing the cost and barriers to entry for financial infrastructure and providing strong technical support for the development of the digital economy.

[0104] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A high-performance parallel blockchain method for stablecoins, characterized in that, It includes the following steps: Step S1: Conduct hierarchical planning for the system architecture, including a consensus layer, an execution layer, a protocol layer, a native service layer, and an application layer from bottom to top; Step S2: Establish a consensus cluster consisting of n nodes. Among them, the number of Byzantine nodes f satisfies the security threshold of f < n / 3. Elect proposers through the random lottery mechanism of the verifiable random function VRF, and achieve parallel block production by multiple proposers and pipelined voting in combination with role settings; Step S3: Under the Byzantine fault tolerance BFT framework, construct a legal certificate QC corresponding to the batch through aggregate signature, package multiple batches using a chained block structure, implement a two-round voting submission rule, and establish a locking rule for the legal certificate highQC of the parent block; Step S4: Implement the consensus process through a lottery stage, a proposal stage, a voting stage, and a submission stage; Step S5: Based on a key-value storage model with multiple versions of states, maintain a multi-version linked list for each state key, record the transaction number and retry sequence number, and maintain two atomic indexes in the execution layer. Combine with worker threads to dynamically switch between executing transactions and verifying transactions; Step S6: Adopt optimistic parallel control and multi-version state management. Worker threads obtain transaction numbers through atomic increment operations and execute business logic, record read-write sets, and reserve write positions in the multi-version storage; During the verification stage,复查 the consistency of the read set versions in the order of the global verification index, and introduce an Estimate marking mechanism to predict and prompt conflicting versions; Combine with a limited retry strategy, increment the execution index and verification index through atomic operations, and use a lock-free linked list to maintain the waiting queue and dependency relationships to实现 the scheduling and execution of the LEAP execution engine, where the LEAP execution engine refers to a lock-free prediction-aware parallel execution engine; Step S7: Implement a state sharding mechanism in a high-concurrency hotspot scenario. For each high-frequency access account, logically divide its balance state into several sub-slots internally, and each sub-slot corresponds to an independent counter; Step S8: Establish an interface constraint and coordination mechanism between the consensus layer and the execution layer.

2. The high-performance parallel blockchain method for stablecoins according to claim 1, characterized in that, In the said Step S1, the consensus layer is responsible for replicating transaction logs and generating a deterministic total order of transactions; the execution layer is responsible for interpreting and executing transactions in the transaction order determined by the consensus, and completing the conversion of the on-chain state from the old version to the new version; The protocol layer is used to provide protocol primitives and system functions; the native service layer is used to integrate high-frequency intelligent contract services; the application layer is used to carry terminal services.

3. The high-performance parallel blockchain method for stablecoins according to claim 1, characterized in that, The said Step S2 includes the following sub-steps: Step S201: Under the Dwork-Lynch-Stockmeyer synchronous network model, establish a consensus cluster consisting of n nodes, and establish a mathematical constraint relationship of f < n / 3 as the boundary condition for security verification; Step S202: Elect proposers through the random lottery mechanism of the verifiable random function VRF. Each proposer can independently propose one or more batches at the current height, and thus实现 parallel block production by multiple proposers at the same height; In step S203, all members of the consensus committee act as voters. After receiving a proposal, each voter verifies its legality, the correctness of the transactions, and the internal conflict of the batch. Based on the verification results, they cast a vote for or against the batch of the proposal. A batch that receives votes from at least 2f+1 nodes is considered to have obtained the legal certificate QC. Step S204: Select the proposer with the smallest number at each height as the aggregator for that height. When the aggregator detects that a batch at the current height has already obtained a legal certificate QC that has reached a preset threshold, it packages the verified batch into the final block for that height and broadcasts it to the entire network. In step S205, all full nodes act as executors, executing transactions locally in the order of the final blocks and updating their local states. During execution, all executors replay transactions on the same state machine to obtain a consistent state.

4. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, Step S3 includes the following sub-steps: Step S301: When the aggregator collects at least 2f+1 valid signatures from different nodes, it uses the aggregate signature algorithm to compress these valid signatures into a constant-size aggregate signature, and combines the aggregate signature with the batch hash value to form the legal certificate QC for that batch. In step S302, at each height, the aggregator packages several batches that have obtained legal certificates (QCs) into a single block. The block header includes the hash value of the previous block, the list of batch hashes contained in the current block, the legal certificate QCs of each batch, the height, and the view number. Step S303: A two-round voting mechanism is adopted. The first voting stage is used to initially confirm the batch of proposals, and the second voting stage is used to confirm the blocks formed in the previous round. When the second round of voting reaches the statutory certificate QC, the corresponding block is considered to be finalized, and the proposal and voting are executed overlapping in the continuous view. In step S304, when each proposer generates a new batch, it references the currently known highest height or highest view of the legal block as the parent block, and the parent block holds the parent block's legal certificate highQC; when voters vote on a proposal, they check whether the parent block's legal certificate highQC referenced by the proposal satisfies the monotonically increasing locking condition. If it does, they vote in favor; otherwise, they refuse to vote on the fork chain. In step S305, when multiple proposers submit proposals for different transaction sets at the same height, each batch is allowed to form an independent legal certificate (QC). When constructing the final block, the aggregator follows the following constraints: batches with conflicting transaction content are excluded, and deterministic sorting and filtering strategies are used to generate blocks.

5. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, Step S4 includes the following sub-steps: Step S401: During the lottery phase, candidate accounting nodes use a verifiable random function (VRF) to locally calculate the seed information at the current height, obtaining a random output and proof. Based on the random output, the number of times the node wins at the current height is determined using the Bernoulli cumulative probability function. The number of winnings is proportional to the amount of tokens staked by the node or its accounting weight. Nodes with a winning count greater than zero broadcast their random output and proof, declaring that they have won at the current height and become proposers. In step S402, during the proposal phase, each successful proposer first selects unpackaged transactions from the local transaction pool and divides the transactions into one or more batches according to a preset number; then, a hash value is calculated for each batch, a proposal message containing height, view, parent block hash value and batch content is generated, and a randomly output proof and proof of the number of successful bids are added. The proposal message is then broadcast to all voters through a peer-to-peer network. Step S403: During the voting phase, after receiving the batch, the voter verifies the proof of the randomly output to confirm the proposer's qualification, checks the legality of the batch structure and transaction format, and checks whether the batch has a direct conflict with other received batches at the same height. Until the check is qualified and there is no direct conflict, a vote of approval containing the batch hash value and the voter's signature is generated and sent to the aggregator specified at the current height. In step S404, during the submission phase, the aggregator continuously accumulates the number of affirmative votes and corresponding signatures for each batch. When a batch receives no less than 2f+1 affirmative votes, it uses the aggregate signature algorithm to construct its legal certificate QC and broadcasts it. After at least one batch obtains a legal certificate QC at the current height, the aggregator packages these batches according to predetermined rules, constructs a block header containing the parent block hash value, a batch list, and the legal certificate QCs for each batch, and broadcasts it to the entire network. After receiving the block, each node confirms that the transaction set at this height has been finally determined and triggers the execution layer to update the state. Step S405 involves overlapping the four stages of step S401 from step S404 at different heights. Step S406: When the aggregator fails to collect enough votes or construct a valid block within the specified time, the current view aggregator is determined to be invalid and the aggregator role is automatically transferred to the next candidate proposer. The new aggregator collects votes from other proposers at the same height and completes block construction within a new time window.

6. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, Step S5 includes the following sub-steps: Step S501: After each block is determined by the consensus layer, the execution layer sequentially numbers the transactions in the block from 0 to N-1, where N represents the total number of transactions in the block; each transaction is treated as a state machine operation, which includes reading and writing several state keys in the state tree, and the read set of the i-th transaction is denoted as R_i, and the write set is denoted as W_i; Step S502: A multi-version key-value storage structure is adopted. A multi-version linked list is maintained for each state key. Each version item in the multi-version linked list records the transaction number, retry number, and write value of the state key. The retry number is used to distinguish different versions generated in multiple executions of the same transaction. The multi-version linked list is stored in chronological order or commit order. The latest committed version is located at the head, and uncommitted intermediate versions are distinguished by special markers, realizing lock-free access to the state history. Step S503: Maintain two atomic indices at the execution layer to indicate the current minimum transaction number to be executed and the minimum transaction number to be verified and submitted, respectively. Step S504: Set the conditions for worker threads to dynamically switch between executing and verifying transactions. If there are transactions that have been executed but not yet verified, they will participate in the verification work first. If there are no transactions to verify, new transactions will be taken from the sequence of unexecuted transactions for execution. Step S505: When a worker thread is executing a transaction, if it finds that the state key to be read currently only has an estimated version or has pending dependencies, it actively suspends the current transaction and releases computing resources; it will automatically wake up and resume execution after the dependencies are satisfied.

7. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, Step S6 includes the following sub-steps: Step S601: During the execution phase, all worker threads retrieve the next transaction number to be executed from the global execution index through an atomic increment operation; when executing a transaction, the version information corresponding to each status key read by the transaction is recorded, and a position is reserved in the storage of the multi-version linked list for the status keys in the write set; Once the business logic for executing a transaction is complete, the result will be recorded as a new version, marking the transaction as either completed or pending verification. In step S602, during the verification phase, the completed transactions are checked according to the order of the global verification index. For transactions in the pending verification state, the read set version recorded during execution is reviewed. If the read set version is consistent with the version recorded during execution, the write version is committed, the write version of the transaction is marked as committed, and all waiting transactions that depend on this version are woken up. Otherwise, the write version is marked as Estimate and a retry is triggered. Subsequent transactions are suspended and wait until the transaction responsible for the Estimate state completes the retry and commit. The Estimate status refers to the conflict warning marker status; Step S603: In the retry strategy phase, a single retry limit is set. When a transaction is aborted due to a read set version conflict after its first execution, the transaction is suspended before the second execution, waiting for all related dependent transactions to complete and commit. If the transaction still fails to pass verification on the second attempt, it is marked as failed. In step S604, during the task scheduling and state update phase, the worker thread increments the execution index and verification index through atomic operations, and maintains the waiting queue and transaction dependencies using a lock-free linked list; when a transaction is committed or terminated, the worker thread traverses its transaction dependencies and updates the waiting transaction status to ready, so that it can re-enter the execution phase.

8. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, Step S7 includes the following sub-steps: Step S701: For each high-frequency access account, its balance status is internally logically divided into p independent sub-slots, where p is a natural number. Each sub-slot corresponds to an independent counter and is stored in a different status key, so that the write operation of the balance status is distributed to multiple physically isolated storage units. Step S702: When updating the balance of the payee or payer, determine the target sub-slot number to be hit in this update based on the transaction characteristics. The transaction characteristics include at least one of the sender address hash value, transaction sequence number and stable allocation function. Step S703: Write operation is performed only on the target sub-slot determined in step S702. The write operation follows the multi-version storage mechanism and appends the new version to the version chain corresponding to the target sub-slot. Step S704, when reading the total balance of the account, traverse all sub-slots of the account, sum up the count values of each sub-slot and return the sum.

9. The high-performance parallel blockchain method for stablecoins according to any one of claims 1 to 3, characterized in that, The said Step S8 includes the following sub-steps: Step S801, after generating multiple batches in parallel at the same height and respectively forming legal certificates QC, the aggregator sorts all batches according to a deterministic rule, and assigns a unique global number to each transaction therein. The deterministic rule includes at least one of the proposal timestamp, proposer weight, and batch hash value; Step S802, at the execution layer, after the transactions are executed in parallel by the LEAP execution engine, they are submitted one by one in ascending order of the global number in the submission stage, ensuring that when submitting the kth transaction, all transactions with a global number less than k have been submitted, and all transactions with a global number greater than k have not been submitted; Step S804, decouple between the consensus layer and the execution layer through a unified block and state interface. When the consensus layer submits a block, it provides the execution layer with a block structure containing the transaction sequence and the corresponding metadata; After the execution layer completes the submission of all transactions and the state update, it returns the latest state root and related summaries to the consensus layer for the verification of subsequent blocks. Adopt the high-performance parallel blockchain method for stablecoins as described in any one of claims 1 to 9, and include:

10. A high-performance parallel blockchain system for stablecoins, characterized in that, A hierarchical planning module that hierarchically plans the system architecture, including a consensus layer, an execution layer, a protocol layer, a native service layer, and an application layer from bottom to top; A consensus and role setting module that establishes a consensus cluster composed of n nodes, where the number f of Byzantine nodes satisfies the security threshold of f < n / 3. The proposer is elected through the random lottery mechanism of the verifiable random function VRF, and multi-proposer parallel block production and pipelined voting are achieved by combining role settings; A block submission rule module that constructs a legal certificate QC corresponding to the batch through aggregate signature under the Byzantine fault tolerance BFT framework, packs multiple batches using a chained block structure, implements a two-round voting submission rule, and establishes a locking rule for the legal certificate highQC of the parent block; A consensus module that realizes the consensus process through a lottery stage, a proposal stage, a voting stage, and a submission stage; An execution and state management module that, based on a key-value storage model with multi-version states, maintains a multi-version linked list for each state key, records the transaction number and retry sequence number, and maintains two atomic indexes at the execution layer, and dynamically switches between executing transactions and verifying transactions in combination with worker threads; ​ The scheduling and execution module of the LEAP execution engine adopts optimistic parallel control and multi-version state management. Worker threads use atomic increment operations to retrieve transaction numbers and execute business logic, record read and write sets, and reserve write positions in multi-version storage. During the verification phase, the consistency of read set versions is checked according to the global verification index order, and an Estimate marking mechanism is introduced to predict and prompt conflicting versions. Combined with a finite retry strategy, the execution index and verification index are incremented atomically, and a lock-free linked list is used to maintain the waiting queue and dependency relationships to realize the scheduling and execution of the LEAP execution engine. The state sharding module executes a state sharding mechanism in high-concurrency hot spot scenarios. For each frequently accessed account, its balance status is internally divided into several sub-slots, and each sub-slot corresponds to an independent counter. The collaboration module establishes interface constraints and collaboration mechanisms between the consensus layer and the execution layer.

Images