A blockchain transaction conflict fast re-execution method based on memory state tracking

Abstract

The embodiment of the application provides a blockchain transaction conflict fast re-execution method based on memory state tracking. The method is applied to the field of blockchain technology, and one or more pre-execution domains and a global decision domain are set in a blockchain node; wherein, the pre-execution domain preferentially inquires a local transient version cache through a unified state access interface, executes a transaction, and generates a pre-execution result package containing original transaction input, read record, write record and source batch; the global decision domain checks the version of the read record according to a determined order by using a global decision version cache; for an effective transaction, the original write record is reused; for a transaction with invalid read items, the invalid read items are replaced by the latest state, the effective read items are reused, a modified state package is constructed, re-execution is performed in an isolated execution context, modified write records are generated, and version backfilling is completed; and the batch is submitted, the cache is rotated and cleaned. The method can reduce conflict processing delay and improve system resource utilization.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a fast re-execution method for blockchain transaction conflicts based on memory state tracking. Background Technology

[0002] Blockchain systems typically use consensus mechanisms to determine the order of transactions, with each node executing transactions and updating the world state according to the same rules to maintain consistency across multiple ledgers. As blockchain applications increase in scenarios such as financial clearing and settlement, supply chain collaboration, government data exchange, and IoT collaboration, executing transactions sequentially becomes insufficient to fully utilize node computing resources. To improve processing power, existing systems are increasingly adopting pipelined processing, batch submission, multi-threaded execution, or partitioned execution, enabling the sorting, execution, verification, and submission processes to proceed in parallel.

[0003] Parallel execution of transactions can lead to state contention. When different transactions read or modify the same account, contract variable, or business state at similar times, the later-executed or later-decided transaction may rely on an outdated version of the state. If the system fails to identify and correct this dependency according to unified rules, different nodes may obtain inconsistent execution results; if the system directly discards conflicting transactions, previously completed state reads, contract calculations, and result propagation will be difficult to continue to utilize.

[0004] Existing conflict handling methods typically include pessimistic concurrency control, deterministic scheduling, and optimistic concurrency control. Pessimistic concurrency control requires transactions to declare or predict read / write sets before execution and to lock or queue potentially conflicting states. However, the state access path of a smart contract may simultaneously depend on runtime parameters, historical states, and conditional branches, making it difficult to accurately obtain the complete read / write range before execution. Excessive locking can also reduce parallelism. Deterministic scheduling reduces conflicts through dependency analysis or pre-ordering, but may increase the preprocessing stage or impose additional constraints on contract writing and deployment methods.

[0005] Optimistic concurrency control allows transactions to be executed in parallel first, and then conflicts are determined based on the read and write records generated at runtime, which imposes relatively few restrictions on the business model. However, when an invalid read state version is detected, the common approach is to abandon the execution result of the transaction and re-initiate the transaction. In contention scenarios such as hot account transfers, centralized request processing, and batch settlement, multiple transactions may continuously read the old state, resulting in the problem of repeatedly reading persistent state and repeatedly executing transaction logic.

[0006] Some existing execution engines employ in-memory multi-version architectures or expose uncommitted writes during the pre-execution phase to reduce the probability of subsequent transactions reading old values. These approaches primarily focus on intra-block scheduling or reducing conflicts, and have not yet fully developed a universal processing link that can connect multiple pre-execution domains with the global commit process. Summary of the Invention

[0007] This application provides a fast re-execution method for blockchain transaction conflicts based on memory state tracking, which addresses the problems of insufficient reuse of existing execution results, repeated access to persistent state, and unclear version connection between the pre-execution phase and the global commit phase after concurrent transactions experience state version conflicts. The method includes:

[0008] The blockchain node receives a subset of transactions through a pre-execution domain and processes the subset to obtain a pre-execution result. The pre-execution result includes: original transaction input, state read record, state write record, and source batch. The pre-execution domain is equipped with a local transient version cache.

[0009] The system receives pre-execution results through a preset global adjudication domain in the blockchain node, and adjudicates each transaction in a preset order according to the pre-execution results. The global adjudication domain is equipped with a global adjudication version cache.

[0010] If all reads of the pending transaction are deemed valid, the global adjudication domain directly uses the original state of the transaction to write records and writes the original state records into the current adjudication mapping of the global adjudication version cache.

[0011] If there are one or more invalid reads in the pending transaction, the global adjudication domain constructs a corrected state packet and re-executes the transaction based on the corrected state packet to generate a corrected write record;

[0012] The reused original state write records or the modified write records generated by re-execution based on the modified state package are backfilled into the global adjudication version cache with the corresponding version identifier to form a state update set;

[0013] The state update set is submitted to the world state in batches, and the local transient version cache and the global adjudication version cache are rotated and cleaned up after the batch submission.

[0014] Optionally, the step of receiving a subset of transactions through a pre-defined pre-execution domain in the blockchain node and processing the subset of transactions to obtain a pre-execution result includes:

[0015] In the pre-execution domain, the local transient version cache is queried through the unified state access interface. The local transient version cache is used to record the state that was recently written but has not yet been persisted in the pre-execution domain.

[0016] If a state version from the current batch or the previous batch that has not yet been persisted but can be referenced exists in the local transient version cache, then read the state value and its version identifier from the local transient version cache and generate the corresponding state read record.

[0017] If the local transient version cache does not contain a state version that has not yet been persisted but can be referenced in the current batch or the previous batch, then read the state value and its version identifier from the persistent world state and generate the corresponding state read record.

[0018] Execute the transaction in the pre-execution domain. When the transaction is completed, generate a state write record and register the written state in the local transient version cache.

[0019] Optionally, the step of receiving pre-execution results through a preset global adjudication domain in the blockchain node and adjudicating transactions one by one according to the pre-execution results in a preset order includes:

[0020] Retrieve the status read record of pending transactions;

[0021] Each state read record is checked to determine whether the state address pointed to by each state read record exists in the global adjudication version cache;

[0022] If the state address exists in the global adjudication version cache, then the version identifier in the state read record is compared with the version identifier of the corresponding cache entry in the global adjudication version cache;

[0023] If the version identifier in the status read record matches the version identifier of the corresponding cache entry in the global adjudication version cache, then the read item is determined to be a valid read item;

[0024] If the version identifier in the status read record is inconsistent with the version identifier of the corresponding cache entry in the global adjudication version cache, the read item will be marked as an invalid read item.

[0025] If the state address does not exist in the global adjudication version cache, then determine whether the version type pointed to by the state read record exists in the confirmed world state version;

[0026] If so, the read item will be determined as a valid read item;

[0027] If not, mark the read item as a failed read item.

[0028] Optionally, the global adjudication domain constructs a corrected state packet and re-executes the transaction based on the corrected state packet to generate a corrected write record, including:

[0029] Construct a corrected state packet based on the original transaction input, the set of valid reads, the latest replacement value of the invalid read, the necessary execution parameters, and supplementary read rules;

[0030] In an isolated execution context, the smart contract or transaction logic is re-executed using the original transaction inputs and the corrected state package to generate a corrected write record.

[0031] The correction write record will overwrite the original pre-execution result of the transaction, and will be written to the global adjudication version cache with the version identifier corresponding to the current batch in the global adjudication domain.

[0032] Optionally, the step of receiving a subset of transactions and processing the subset of transactions through a pre-execution domain preset in the blockchain node to obtain a pre-execution result further includes:

[0033] The read and write operations of the transaction pair state are encapsulated through a unified state access interface;

[0034] For each status read, the unified status access interface records the status address, read value, version identifier, read source, and transaction identifier, wherein the version identifier is determined by at least one of the batch number, adjudication number, transaction number, and status sequence number;

[0035] For each state write, the unified state access interface records the state address, the write value, the source batch, and the write transaction identifier.

[0036] Optionally, the local transient version cache adopts a two-layer or multi-layer mapping structure to maintain the recent state. The local transient version cache includes at least the current batch mapping and the previous batch mapping. The current batch mapping is used to save the write state of transactions in the current batch that have been generated but have not yet been globally committed, and the previous batch mapping is used to save the temporary state in the previous batch that may still be depended on by subsequent transactions. Each local transient version cache entry includes at least a state address, a state value, and a version identifier.

[0037] Optionally, the global adjudication version cache includes at least a current adjudication mapping and adjacent confirmed mappings. The current adjudication mapping stores the latest status of adjudicated decisions in the current adjudication batch, and the adjacent confirmed mapping stores the status of adjacent confirmed batches that are still participating in recent version verification. Each global adjudication version cache entry includes at least a status address, the latest status value, a version identifier, a source transaction, and a status flag.

[0038] Optionally, the step of rotating and cleaning up the local transient version cache and the global adjudication version cache after batch submission includes:

[0039] Delete entries in the local transient version cache that have been persisted, have been determined to be invalid, or are no longer likely to be referenced by subsequent transactions; convert the current batch mapping that still needs to be retained to the historical mapping and initialize a new current batch mapping;

[0040] Remove entries from the global adjudication version cache that have been stably committed and are no longer involved in recent version verification, while retaining the latest version required by the current adjudication process and adjacent commit processes.

[0041] Optionally, the step of receiving a subset of transactions and processing the subset of transactions through a pre-execution domain preset in the blockchain node to obtain a pre-execution result further includes:

[0042] For states written by the previous transaction and read by the next transaction within the same pre-execution domain, the state read record of the next transaction is made to point to the transient version generated by the previous transaction in order to track cascading dependencies.

[0043] For transactions output from different pre-execution domains, the global adjudication version cache is used to identify outdated references to state read records relative to the latest state in the determined adjudication order.

[0044] Optionally, the pre-execution result also includes the read source and transaction identifier indicated by the status read record, and the write transaction identifier indicated by the status write record; after the transaction is executed, the pre-execution domain registers the status write record to the current batch mapping, so that subsequent transactions in the same pre-execution domain can read the transient version corresponding to the status write record.

[0045] The present invention has the following beneficial effects:

[0046] 1. It can reduce simple aborts and full retries after detecting transaction conflicts, allowing the reuse of existing read information, original input, and part of the execution context of conflicting transactions. For business scenarios with frequent access to hot states, this approach can reduce the additional overhead caused by repeated execution and repeated storage access.

[0047] 2. By using a local transient version cache to store the state that has not yet been persisted within the pre-execution domain, and a global adjudication version cache to store the recent adjudication state, the transaction pre-execution, conflict detection, and re-execution processes are carried out around the state versions in memory as much as possible. Compared to reloading the entire state from the underlying storage after each conflict, this approach helps reduce conflict handling latency and alleviates the pressure on the storage system.

[0048] 3. Conflicting and non-conflicting states are handled separately. For reads that have become version invalid, the system replaces them with the latest state from the global adjudication version cache; for reads that are still valid, the system continues to reuse the state value obtained during the first execution. This mechanism avoids treating the entire transaction as an invalid object and improves the utilization rate of executed results.

[0049] 4. It does not require transactions to accurately declare the complete read and write sets before execution, nor does it require smart contracts to be written in a specific static dependency format. The system completes conflict detection and correction through runtime read and write records and version verification, making it easier to embed into the execution, verification, and submission processes of existing permissioned or consortium blockchain nodes.

[0050] 5. By controlling memory usage through cache rotation and state cleanup mechanisms, the local transient version cache and the global adjudication version cache only store the state required for recent conflict judgments and rapid re-execution, reducing the resource pressure caused by long-term storage of historical versions. This can improve the stability and resource utilization efficiency of high-concurrency blockchain systems under contention loads while ensuring deterministic commits. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0052] Figure 1 A flowchart illustrating the fast re-execution method for blockchain transaction conflicts based on memory state tracking provided in this application embodiment. Figure 1 ;

[0053] Figure 2 A flowchart illustrating the fast re-execution method for blockchain transaction conflicts based on memory state tracking provided in this application embodiment. Figure 2 ;

[0054] Figure 3 A flowchart illustrating a fast re-execution method for blockchain transaction conflicts based on memory state tracking, provided in this application embodiment. Figure 3 .

[0055] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0057] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0058] In this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0060] like Figure 1-3 As shown in the figure, this embodiment provides a fast re-execution method for blockchain transaction conflicts based on memory state tracking, including:

[0061] S1: Receive a subset of transactions through the pre-execution domain preset in the blockchain node and process the subset of transactions to obtain the pre-execution result.

[0062] The pre-execution result includes at least: original transaction input, status read record, status write record and source batch. The pre-execution domain is equipped with a local transient version cache, which is used to record the status recently written but not yet persisted within the pre-execution domain.

[0063] Specifically, one or more pre-execution domains are set up in the blockchain node. Each pre-execution domain can correspond to a thread group, process group, or execution queue capable of independently executing transactions. A local transient version cache is set up within the pre-execution domain to store states from the current batch and adjacent batches that have not yet been stably written to the persistent world state but may be read by subsequent transactions. The local transient version cache can be implemented using a hash table, skip list, segmented mapping table, or memory key-value structure. Each entry includes at least a state address, state value, and version identifier, and may include the source batch, state flag, creation time, read count, write transaction identifier, reference count, and cleanup flag.

[0064] In one implementation, the local transient version cache uses a segmented hash structure, with each segment having its own independent concurrency control object to reduce contention when different state addresses access the cache simultaneously. The current batch mapping records the write status of transactions in this batch that have been generated but have not yet completed global adjudication, while the previous batch mapping records the status of transactions from the previous batch that may still be referenced by the current transaction. This mapping can be rotated using a double-buffering method, or multiple adjacent batch mappings can be set; the number of mappings retained is configured based on node memory conditions, transaction processing latency, and business contention.

[0065] When reading a transaction's status, the unified status access interface first queries the current batch mapping. If the query finds a match, the interface returns the status values ​​and version identifiers already generated within the current batch; if not, it queries the previous batch mapping; if still not a match, it reads the confirmed status from the persistent world state. The interface generates a status read record for each read, recording the status address, read value, version identifier, read source, and transaction identifier. Thus, the transaction logic obtains its status using the same interface, without needing to be aware of its specific storage location.

[0066] When a transaction is completed and a write result is generated, the unified state access interface generates a state write record, recording the state address, write value, source batch, and write transaction identifier, and registers the corresponding state in the current batch mapping. This registration does not directly update the persistent world state, but waits for global adjudication along with the pre-execution result package. Subsequent transactions in the same pre-execution domain can preferentially read the registered state to form a traceable intra-domain cascading dependency.

[0067] In an optional embodiment, the system determines a version identifier for the read or write status of a transaction. The version identifier can be generated based on one or more of the following: batch number, adjudication sequence number, transaction sequence number, and status sequence number, as long as all nodes can obtain consistent version comparison results according to the same rules. The version identifier for a status read from the persistent world state can correspond to a committed batch; the version identifier for a status generated in the pre-execution domain can correspond to the source batch and the write transaction; and the version identifier for a status that has completed version backfilling can correspond to the current adjudication batch and adjudication order.

[0068] The unified state access interface generates a state read record for each state read and a state write record for each state write; together, they constitute the state access trajectory of a transaction. The system can also maintain a lightweight dependency index in memory, associating state addresses with transactions that read or write to that state, to help determine subsequent transactions that may be affected by state version changes. This dependency index is formed based on runtime access records, eliminating the need for static analysis of smart contracts or for transactions to declare complete read / write sets before execution.

[0069] For cascading dependencies within the same pre-execution domain, when a previous transaction writes its state to the current batch mapping, and a subsequent transaction reads that state through the unified state access interface, its state read record points to the transient version generated by the previous transaction. If the state write record of the previous transaction is directly reused in the global adjudication domain, the subsequent transaction continues to use the read item through version verification; if the previous transaction is re-executed in the global adjudication domain and changes the state value or version, the state read record of the subsequent transaction is identified as an invalid read item, and re-execution is performed according to the corrected state package.

[0070] For stale references between different pre-execution domains, suppose a transaction in one pre-execution domain reads an earlier version of a state, and a preceding transaction in another pre-execution domain updates that state according to a globally determined order. When the global adjudication domain processes the aforementioned read transaction, it compares its state read record with the latest version in the global adjudication version cache to identify stale references and replaces the invalid read with the latest state. Thus, the local transient version cache is responsible for preserving transient dependencies within a domain, while the global adjudication version cache is responsible for uniformly handling cross-domain version changes according to a determined order.

[0071] S2: Receive the pre-execution results through the preset global adjudication domain in the blockchain node, and adjudicate the transactions one by one according to the preset order based on the pre-execution results.

[0072] The global adjudication domain has a global adjudication version cache, which stores the latest status of the current adjudication batch and adjacent confirmed batches. Each entry includes at least the status address, the latest status value, the version identifier, the source transaction, and the status flag.

[0073] Specifically, the global adjudication domain processes transactions one by one according to consensus results, batch numbers, transaction numbers, or other deterministic rules, and maintains a global adjudication version cache. When adjudicating a transaction, the global adjudication domain checks the state read records of that transaction item by item. If the state address pointed to by the read record exists in the global adjudication version cache, the version identifier in the read record is compared with the version identifier of the cache entry. If they match, the read entry is still valid; if they do not match, the state read during the pre-execution of the transaction has been updated by other preceding transactions, and the read entry is marked as invalid. If the state address does not exist in the global adjudication version cache, but the read record points to a confirmed world state version, the read entry can continue to be considered valid; if the read record points to a local temporary version and this temporary version has not been confirmed by the global adjudication, the read entry is also marked as invalid.

[0074] S3: If all reads of the transaction to be adjudicated are deemed valid, the global adjudication domain directly uses the original state of the transaction to write records and writes the original state write records into the current adjudication mapping of the global adjudication version cache.

[0075] Understandably, if all reads of a transaction are valid, the global adjudication domain directly uses the original state of the transaction to write records and writes these records into the current adjudication mapping in the global adjudication version cache. In this case, there is no need to re-execute the transaction.

[0076] S4: If there are one or more invalid reads in the pending transaction, the global adjudication domain constructs a corrected state packet and re-executes the transaction based on the corrected state packet to generate a corrected write record.

[0077] Specifically, if one or more invalid reads exist, the global adjudication domain does not discard the transaction directly, but instead constructs a corrected state package. The corrected state package includes at least the original transaction input, a set of valid reads, the latest replacement values ​​for invalid reads, necessary execution parameters, and supplementary read rules. Valid reads retain the read values ​​from the first pre-execution; invalid reads are replaced by the latest values ​​of the corresponding state addresses in the global adjudication version cache; if the transaction accesses a new state according to deterministic rules during re-execution, the unified state access interface supplements the reads and records them. Supplementary read rules define the read paths and format constraints when a transaction accesses a new state according to deterministic rules during re-execution.

[0078] Furthermore, after the modified state packet is constructed, the global adjudication domain re-executes the smart contract or transaction logic within the isolated execution context using the original transaction input and the modified state packet. The isolated execution context is only visible to the current transaction, does not directly modify the persistent world state, and does not overwrite the results of other transactions that have already been adjudicated.

[0079] S5: Reuse the original state write records or the modified write records generated based on the modified state package and fill them back into the global adjudication version cache with the corresponding version identifier to form a state update set.

[0080] Specifically, when all read records of a transaction are consistent with the global adjudication version cache, or when the relevant state does not appear in the cache and its version points to the confirmed world state, the system determines that the pre-execution result of the transaction is still valid, directly reuses its write records, and updates the global adjudication version cache with the version identifier corresponding to the current adjudication process.

[0081] After re-execution, a corrected write record is generated, overwriting the original state write record of the transaction. This corrected write record is then written to the global adjudication version cache with the version identifier corresponding to the current batch in the global adjudication domain. Subsequent transactions continue to undergo version verification based on this, thus forming a continuous and deterministic adjudication chain.

[0082] S6: Submit the state update set to the world state in batches, and rotate and clean up the local transient version cache and the global adjudication version cache after the batch submission.

[0083] Specifically, after a batch or epoch is committed, the system triggers cache rotation and cleanup. Local transient version caches delete entries that have been persisted, deemed invalid, or are no longer likely to be referenced by subsequent transactions. Current batch mappings that still need to be retained are converted to historical mappings, and new current batch mappings are initialized. Global adjudication version caches delete entries that have been stably committed and are no longer involved in recent version validation, retaining only the latest versions required for the current adjudication and adjacent commit processes. Through cache rotation, the system limits memory usage and prevents the infinite accumulation of version entries after long-term operation.

[0084] In an optional embodiment, in a concurrent execution environment, the local transient version cache and the global adjudication version cache can be access controlled using segmented locks, read-write locks, optimistic locks, atomic comparison swaps, or multi-version read snapshots. The concurrency control method used can be selected according to the node's operating environment, but version updates for the same state address must take effect in the determined order adopted by the global adjudication domain.

[0085] In one implementation, cached entries are configured with a version control field, which is determined by batch and sequence information. When updating the state, both the state address and the version control field are checked. If the current cached entry's version is still the expected version, a new state value is written and the version control field is updated; if the version has changed, the latest entry is retrieved and processed according to version verification rules. For multiple concurrent updates to the same state address, fine-grained locks or atomic comparison swaps can be used to allow updates to different state addresses to proceed in parallel, while ensuring that updates to the same state address follow a predetermined order.

[0086] Fast re-execution can be implemented in the order of state loading, transaction computation, and result backfilling. During state loading, a consistent input view of the current transaction is constructed based on the corrected state packet and necessary persistent world state reads. During transaction computation, the transaction logic is run in an isolated execution context. During result backfilling, corrected write records are written to the global adjudication version cache. For multiple state writes involved in a transaction, the result backfilling process treats them as the adjudication result of that transaction for consistent processing. If a version change affecting the transaction input is detected before backfilling, version verification is performed again to prevent partial writes from becoming the basis for verification in subsequent transactions.

[0087] For read-only transactions, a snapshot view based on version identifiers can be provided. When a read-only transaction begins execution, the visible version boundary is recorded, and the confirmed state at or above that boundary is read. Upon entering the global adjudication domain, if its read state has not been updated by preceding transactions, the pre-execution result is reused; if the read state has been updated, the current valid state is retrieved again according to the same version verification rules, and the transaction is re-executed or an updated read result is generated according to the transaction processing requirements.

[0088] In an optional embodiment, in a distributed deployment, each blockchain node maintains its own local transient version cache and global adjudication version cache. Different nodes can generate pre-execution results based on the same original transaction inputs and deterministic execution rules, or they can receive pre-execution results generated by nodes specified by the consensus protocol. Each node employs the same transaction order, version comparison rules, modified state packet construction rules, and transaction execution rules in the global adjudication domain to obtain consistent adjudication results.

[0089] After a node completes the adjudication of the current batch, it can send the state update set, version digest, and necessary transaction adjudication results to other nodes. The version digest can be formed based on a hash digest, Merkle root, state address list digest, or batch signature digest. The receiving node checks the adjudication result corresponding to its local global adjudication version cache against the version digest. If the digests match, it continues processing subsequent batches; if the digests do not match, it can request the difference in state entries, re-execute the affected transactions, or restore the batch to the most recent consistent state based on consensus and then re-adjudicate.

[0090] Local transient version caches are used for local pre-execution on nodes. All entries do not need to be synchronized across nodes and can be processed according to rotation and cleanup rules after batch commits. The objects confirmed between nodes include the set of state updates derived from the global adjudication version cache and its version summary. By distinguishing between local transient states and global adjudication results, network propagation of transient states can be reduced, while ensuring consistency across nodes in updates ultimately committed to the persistent world state.

[0091] In situations with high network latency or a large number of nodes, nodes can synchronize version summaries and difference states of adjudicated batches in the background while continuing to process pre-execution transactions that do not depend on missing states. If subsequent adjudications require states that have not yet been synchronized, nodes can postpone the adjudication of the relevant transactions, request the corresponding state, or reconstruct the corrected state package based on the locally confirmed persistent world state. All of the above processes follow the version verification and correction re-execution rules of the global adjudication domain.

[0092] In an optional embodiment, checkpoints can be set for the global adjudication domain to handle node failures, process restarts, or network partitions. Checkpoints record the most recently committed batch, a persistent world state summary, a global adjudication version cache summary, and information on transactions that have not yet been adjudicated. Checkpoints can be generated at configured batch intervals, or when memory maintenance conditions are met, network anomalies occur, or a node is preparing to stop service.

[0093] After a node fails and recovers during rapid re-execution, it first loads the most recent stable checkpoint and reconstructs the persistent world state view based on the batch information in the checkpoint. Transactions that have already been committed do not require re-adjudication; transactions that have not yet been adjudicated can retrieve their pre-execution result packages or be re-executed in the pre-execution domain, and then the global adjudication domain determines the validity of the state read record according to the version verification rules. Because all nodes use the same transaction order, version verification rules, and corrected state package construction rules, the recovery process can reconstruct a result that is consistent with the confirmed adjudication chain.

[0094] During network partitioning, nodes can continue local pre-execution, but decisions that cannot obtain global confirmation are marked as pending confirmation. After network recovery, nodes determine whether their local results are consistent with the consensus confirmation results by exchanging batch digests and state update sets. If the local version lags behind, the global decision version cache is updated based on the confirmed results, and version verification is re-executed for affected transactions; if the local result has been confirmed, the corresponding state update set is synchronized to nodes that have not yet updated.

[0095] For transactions with long execution times or high resource consumption, a partial re-execution state can be saved. This partial re-execution state includes at least the original transaction input, the constructed corrected state package, the read state entries, and the current execution stage. Before resuming a transaction, the version contained in the corrected state package is checked to ensure it is still valid; if it is still valid, execution continues; if it is invalid, the corrected state package is reconstructed before execution. This process allows paused transactions to reuse still valid re-execution inputs.

[0096] In an optional embodiment, the local transient version cache and the global adjudication version cache can adjust their memory layout based on the node's hardware conditions. For frequently accessed states, the state address, version identifier, and state value digest can be placed in a contiguous memory region. For entries with large state values, the cache can store a state value reference or digest, while storing the complete state value in a separate data area. For steps that only require version comparison, the version identifier and state digest can be read first, and the required complete state value can be obtained when constructing the corrected state packet.

[0097] The system allows for multi-level cleanup strategies. After a batch commit, entries that are already persistent and no longer participate in recent version verification are deleted. Transient entries with a reference count of zero and exceeding the retention window are deleted according to the configured cleanup conditions. When memory usage reaches maintenance thresholds, entries with low access frequency can be compressed, their complete state values ​​moved to the temporary storage area, and their state addresses and version summaries retained in the cache. Cleanup can be triggered by batch commits, memory usage, the number of cached entries, or maintenance tasks.

[0098] The unified state access interface can also identify frequently accessed states based on recent state access records and prefetch the corresponding states into memory before processing related transactions in the pre-execution domain or global adjudication domain. The prefetching results do not change the state reading order or version verification rules; if the prefetched state is not obtained, the current batch mapping, the previous batch mapping, and the persistent world state are still queried in sequence.

[0099] In a multi-core processor environment, local read caches can be set up for different execution threads to store the recently read state address, state value, and version identifier. Before using a local read cache, its version identifier is compared with the currently valid version in a local transient version cache or a global adjudication version cache. If the versions match, the local read result is reused; if the versions do not match, the corresponding local entry is discarded and the currently valid state is reread. This process can reuse recently read results while maintaining version consistency.

[0100] This application provides a fast re-execution method for blockchain transaction conflicts based on memory state tracking. Upon detecting a version conflict, it retains the original transaction input and valid reads, replacing only invalid reads. This helps reduce repeated readings of persistent states and repeated preparation of execution inputs. By managing dependencies within pre-execution domains and global adjudication version changes through local transient version caching and global adjudication version caching respectively, multiple pre-execution domains can be integrated with the deterministic commit process under unified version rules. It eliminates the need for transactions to declare complete read / write sets before execution and controls memory usage through post-commit cache rotation and cleanup, facilitating adaptation to permissioned blockchains, consortium blockchains, or other deterministic ledger systems.

[0101] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0102] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for fast re-execution of blockchain transaction conflicts based on memory state tracking, characterized in that, The method includes: The blockchain node receives a subset of transactions through a pre-execution domain and processes the subset to obtain a pre-execution result. The pre-execution result includes: original transaction input, state read record, state write record, and source batch. The pre-execution domain is equipped with a local transient version cache. The system receives pre-execution results through a preset global adjudication domain in the blockchain node, and adjudicates each transaction in a preset order according to the pre-execution results. The global adjudication domain is equipped with a global adjudication version cache. If all reads of the pending transaction are deemed valid, the global adjudication domain directly uses the original state of the transaction to write records and writes the original state records into the current adjudication mapping of the global adjudication version cache. If there are one or more invalid reads in the pending transaction, the global adjudication domain constructs a corrected state packet and re-executes the transaction based on the corrected state packet to generate a corrected write record; The reused original state write records or the modified write records generated by re-execution based on the modified state package are backfilled into the global adjudication version cache with the corresponding version identifier to form a state update set. The state update set is submitted to the world state in batches, and the local transient version cache and the global adjudication version cache are rotated and cleaned up after the batch submission.

2. The method according to claim 1, characterized in that, The process of receiving a subset of transactions through a pre-defined pre-execution domain in a blockchain node and processing the subset of transactions to obtain a pre-execution result includes: In the pre-execution domain, the local transient version cache is queried through the unified state access interface. The local transient version cache is used to record the state that was recently written to but has not yet been persisted in the pre-execution domain. If a state version from the current batch or the previous batch that has not yet been persisted but can be referenced exists in the local transient version cache, then read the state value and its version identifier from the local transient version cache and generate the corresponding state read record. If the local transient version cache does not contain a state version that has not yet been persisted but can be referenced in the current batch or the previous batch, then read the state value and its version identifier from the persistent world state and generate the corresponding state read record. Execute the transaction in the pre-execution domain. When the transaction is completed, generate a state write record and register the written state in the local transient version cache.

3. The method according to claim 2, characterized in that, The process of receiving pre-execution results through a preset global adjudication domain in a blockchain node, and adjudicating transactions one by one according to the pre-execution results in a preset order, includes: Retrieve the status read record of pending transactions; Each state read record is checked to determine whether the state address pointed to by each state read record exists in the global adjudication version cache; If the state address exists in the global adjudication version cache, then the version identifier in the state read record is compared with the version identifier of the corresponding cache entry in the global adjudication version cache; If the version identifier in the status read record matches the version identifier of the corresponding cache entry in the global adjudication version cache, then the read item is determined to be a valid read item; If the version identifier in the status read record is inconsistent with the version identifier of the corresponding cache entry in the global adjudication version cache, the read item will be marked as an invalid read item. If the state address does not exist in the global adjudication version cache, then determine whether the version type pointed to by the state read record exists in the confirmed world state version; If so, the read item will be determined as a valid read item; If not, mark the read item as a failed read item.

4. The method according to claim 1, characterized in that, The global adjudication domain constructs a corrected state packet, and based on the corrected state packet, re-executes the transaction to generate a corrected write record, including: Construct a corrected state packet based on the original transaction input, the set of valid reads, the latest replacement value of the invalid read, the necessary execution parameters, and supplementary read rules; In an isolated execution context, the smart contract or transaction logic is re-executed using the original transaction inputs and the corrected state package to generate a corrected write record. The correction write record will overwrite the original pre-execution result of the transaction, and will be written to the global adjudication version cache with the version identifier corresponding to the current batch in the global adjudication domain.

5. The method according to claim 2, characterized in that, The step of receiving a subset of transactions through a pre-execution domain preset in a blockchain node and processing the subset of transactions to obtain a pre-execution result also includes: The read and write operations of the transaction pair state are encapsulated through a unified state access interface; For each status read, the unified status access interface records the status address, read value, version identifier, read source, and transaction identifier, wherein the version identifier is determined by at least one of the batch number, adjudication number, transaction number, and status sequence number; For each state write, the unified state access interface records the state address, the write value, the source batch, and the write transaction identifier.

6. The method according to claim 2, characterized in that, The local transient version cache uses a two- or multi-layer mapping structure to maintain the recent state. The local transient version cache includes at least the current batch mapping and the previous batch mapping. The current batch mapping is used to store the write state of transactions in the current batch that have been generated but have not yet been globally committed. The previous batch mapping is used to store the temporary state in the previous batch that may still be depended on by subsequent transactions. Each local transient version cache entry includes at least the state address, state value and version identifier.

7. The method according to claim 3, characterized in that, The global adjudication version cache includes at least a current adjudication mapping and adjacent confirmed mappings. The current adjudication mapping stores the latest status of adjudicated decisions in the current adjudication batch, and the adjacent confirmed mapping stores the status of adjacent confirmed batches that are still participating in recent version verification. Each global adjudication version cache entry includes at least a status address, the latest status value, a version identifier, a source transaction, and a status flag.

8. The method according to claim 1, characterized in that, The process of rotating and cleaning up the local transient version cache and the global adjudication version cache after batch submission includes: Delete entries in the local transient version cache that have been persisted, have been determined to be invalid, or are no longer likely to be referenced by subsequent transactions; convert the current batch mapping that still needs to be retained to the historical mapping and initialize a new current batch mapping; Remove entries from the global adjudication version cache that have been stably committed and are no longer involved in recent version verification, while retaining the latest version required by the current adjudication process and adjacent commit processes.

9. The method according to claim 1, characterized in that, The step of receiving a subset of transactions through a pre-execution domain preset in a blockchain node and processing the subset of transactions to obtain a pre-execution result also includes: For states written by the previous transaction and read by the next transaction within the same pre-execution domain, the state read record of the next transaction is made to point to the transient version generated by the previous transaction in order to track cascading dependencies. For transactions output from different pre-execution domains, the global adjudication version cache is used to identify outdated references to state read records relative to the latest state in the determined adjudication order.

10. The method according to claim 1, characterized in that, The pre-execution result also includes the read source and transaction identifier indicated by the status read record, and the write transaction identifier indicated by the status write record; after the transaction is executed, the pre-execution domain registers the status write record to the current batch mapping, so that subsequent transactions in the same pre-execution domain can read the transient version corresponding to the status write record.

Images