Distributed ledger asynchronous data processing method and system based on MEMO state machine

Abstract

The present application relates to the field of computer communication technology and provides a distributed ledger asynchronous data processing method and system based on a MEMO state machine, which is used to improve the intelligent adaptability of a distributed ledger network to dynamic business scenarios. The method comprises: obtaining a transaction request set in a distributed ledger network, extracting asynchronous processing trigger events of the transaction request set, parsing the asynchronous processing trigger events, generating a state transition instruction sequence including M state migration paths associated with K transaction data blocks, asynchronously processing the M state migration paths using a parallel prediction module based on a MEMO state machine, generating N predicted state vectors and corresponding conflict detection tags; performing feature fusion on the N predicted state vectors based on the conflict detection tags to generate a global state update matrix; writing the global state update matrix into a consensus node set of the distributed ledger network, and generating an asynchronous processing state log matching the transaction request set.

Description

Technical Field

[0001] The present application belongs to the field of computer communication technology, and specifically relates to a distributed accounting asynchronous data processing method and system based on a MEMO state machine. Background Art

[0002] In the field of distributed ledger networks, traditional architectures generally adopt a linear synchronous processing mechanism, which implements ledger updates through globally sorted transaction serialization, resulting in system throughput being limited by a single-threaded processing bottleneck.

[0003] While current parallel processing frameworks incorporate multithreading, they still rely on atomicity guarantees under strong synchronization constraints. For example, batch processing solutions based on optimistic locking trigger full rollbacks when state conflicts are detected, causing resource utilization to fluctuate significantly as the conflict rate increases. Furthermore, traditional state machine replication technology, constrained by deterministic instruction execution logic, lacks the ability to concurrently deduce potential state migration paths, leading to rigid resource allocation when processing heterogeneous transactions.

[0004] Existing asynchronous processing mechanisms often focus on optimizing load distribution within task queues, but fail to fully deconstruct the inherent state transition semantics of transactions. While typical event-driven architectures decouple transaction reception and execution, their triggering conditions still rely on fixed thresholds or periodic polling mechanisms, making them unable to dynamically adapt to fluctuating network loads.

[0005] At the conflict resolution level, mainstream technologies rely on post-verification mechanisms, such as version comparison during the ledger submission phase to identify state divergences. This delayed processing significantly increases the risk of system uncertainty. Furthermore, traditional global state synchronization utilizes a multi-layer relay topology, and the complexity of inter-node communication surges with network scale. Transaction logs only record raw data sequences and lack multi-dimensional feature extraction of state evolution processes. This requires the reconstruction of the entire execution chain during audits, resulting in low operational efficiency. These deficiencies collectively restrict the application capabilities of distributed ledger networks in high-concurrency, high-real-time scenarios. Therefore, improving the intelligent adaptability of distributed ledger networks to dynamic business scenarios is a technical challenge that currently needs to be addressed. Summary of the Invention

[0006] The present application provides a distributed ledger asynchronous data processing method and system based on a MEMO state machine, which is used to improve the intelligent adaptability of the distributed ledger network to dynamic business scenarios.

[0007] In a first aspect, an embodiment of the present application provides a distributed ledger asynchronous data processing method based on a MEMO state machine, which is applied to an asynchronous data processing system, the method comprising: obtaining a transaction request set in a distributed ledger network, and extracting an asynchronous processing trigger event of the transaction request set, wherein the transaction request set includes K transaction data blocks, where K is a positive integer; parsing the asynchronous processing trigger event to generate a state transition instruction sequence, wherein the state transition instruction sequence includes M state migration paths associated with the K transaction data blocks, where M is a positive integer not greater than K; asynchronously processing the M state migration paths based on a parallel prediction module of the MEMO state machine to generate N predicted state vectors and corresponding conflict detection tags, where N is a positive integer not greater than M; performing feature fusion on the N predicted state vectors according to the conflict detection tags to generate a global state update matrix; writing the global state update matrix into a consensus node set of the distributed ledger network, and generating an asynchronous processing state log matching the transaction request set.

[0008] In a second aspect, an embodiment of the present application provides an asynchronous data processing system, which includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the above method.

[0009] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program runs on an asynchronous data processing system, the computer program is used to enable the asynchronous data processing system to execute the steps of the above method.

[0010] The embodiment of the present application significantly improves the dynamic processing efficiency and system robustness of the distributed ledger network by constructing an asynchronous event-driven intelligent state transition mechanism. Different from the traditional synchronous processing mode, the embodiment of the present application innovatively decouples the transaction request set into a state migration path that can be independently analyzed, and realizes the asynchronous deduction of multi-path conflict prediction and potential state evolution under the parallel prediction architecture of the MEMO state machine. The intelligent state transition mechanism of the embodiment of the present application breakthroughly adopts the feature fusion strategy of the predicted state vector, and generates a global state update matrix through nonlinear combination, so that distributed nodes can dynamically coordinate the concurrent state change requirements generated by heterogeneous transactions without relying on sequential execution constraints. In detail, the intelligent arbitration mechanism based on the conflict detection mark of the embodiment of the present application effectively eliminates the data competition risk caused by multi-path state migration, and at the same time realizes full life cycle verifiability by generating asynchronous processing state logs. On the basis of ensuring strong consistency of the ledger, a high-throughput, low-latency elastic consensus framework is constructed. Therefore, the above-mentioned self-organizing state management paradigm for asynchronous event streams can improve the intelligent adaptability of the distributed ledger network for dynamic business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A flow chart of a distributed ledger asynchronous data processing method based on a MEMO state machine provided in an embodiment of the present application.

[0012] Figure 2 A schematic diagram of the structure of an asynchronous data processing system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0013] See also Figure 1 , which is a distributed ledger asynchronous data processing method based on a MEMO state machine provided in an embodiment of the present application. The method can be applied to an asynchronous data processing system. The specific process is as follows: steps 100 to 180.

[0014] Step 100: Acquire a transaction request set in a distributed ledger network and extract an asynchronous processing trigger event of the transaction request set, wherein the transaction request set includes K transaction data blocks, where K is a positive integer.

[0015] In this embodiment, the asynchronous data processing system can receive a set of transaction requests from an external payment gateway, smart contract execution engine, or cross-chain bridge module through the transaction entry node cluster of the distributed ledger network. Each transaction request is encapsulated as a transaction data block with an independent blockchain address identifier. Each transaction data block complies with the transaction encoding specifications defined by the distributed ledger network and includes a transaction version number, input and output script hashes, multi-signature verification rules, and a nested metadata payload. For example, the asynchronous data processing system uses a layered verification mechanism to process the transaction request set: first, the transaction filtering layer performs a preliminary screening of K transaction data blocks to eliminate transactions with illegal formats or signature verification failures; then, the transaction classification layer marks and classifies legitimate transactions according to a preset rule engine. For example, operations involving high-concurrency accounts are marked as high-priority transactions, and batch liquidation transactions are marked as asynchronous processing candidates.

[0016] In the above process, the generation of asynchronous processing trigger events relies on the distributed ledger network's real-time monitoring probes, which continuously collect metrics such as network throughput, node computing load, and memory pool queue depth. When it detects that the processing delay of a single node exceeds a threshold or the number of backlogged transactions in the memory pool exceeds a critical value, the asynchronous data processing system will automatically trigger batch processing mode, packaging the K transaction data blocks accumulated in the current memory pool into asynchronous processing units. It also generates a trigger event tuple containing a time window identifier and load balancing strategy. For example, when a regional node in the distributed ledger network detects that its memory pool contains more than a few hundred cross-regional remittance transactions, the asynchronous data processing system will initiate a cross-regional sharding processing mechanism, dividing these transactions into multiple subsets based on the time zone of the target account and attaching a geographic routing label to each subset to optimize subsequent processing paths.

[0017] Step 120: Parse the asynchronous processing trigger event to generate a state transition instruction sequence, where the state transition instruction sequence includes M state transition paths associated with the K transaction data blocks, where M is a positive integer not greater than K.

[0018] In this embodiment, the asynchronous data processing system can invoke a distributed state parser to perform in-depth semantic analysis of triggering events. This parser, built on an improved finite state transition model, maps the operational semantics of transaction data blocks into state migration paths in a MEMO state machine. Each state migration path consists of a quadruple consisting of an initial state node, a migration condition predicate, a target state node, and a migration constraint function. The migration constraint function verifies the path feasibility by accessing a global state snapshot of the distributed ledger network.

[0019] For example, for a transaction data block involving digital asset staking, the state parser will generate a migration path from "operable state → pledged locked state" and embed dynamic pledge rate calculation rules into the migration constraint function to ensure that the target state transition complies with the requirements of the on-chain governance protocol. The asynchronous data processing system uses an event-sourced dependency analysis algorithm to perform causal relationship modeling on M state migration paths. By parsing the timestamp sequence and account interaction graph in the transaction data block, a cross-transaction state dependency matrix is ​​constructed. Each element of this matrix indicates whether two state migration paths have a read-write conflict on a shared account.

[0020] During this process, the asynchronous data processing system introduces a priority-weighted mechanism, assigning higher execution weights to state transition paths involving key system accounts (such as the fee collection account), ensuring they pass the MEMO state machine's verification process first. For example, if a transaction data block is detected requiring an update to the distributed ledger network's benchmark interest rate parameters, the asynchronous data processing system will automatically elevate the priority of that path, placing it at the front of the state transition instruction sequence.

[0021] Step 140: The parallel prediction module based on the MEMO state machine performs asynchronous processing on the M state transition paths to generate N predicted state vectors and corresponding conflict detection flags, where N is a positive integer not greater than M.

[0022] In this embodiment, the asynchronous data processing system activates the multi-dimensional prediction engine of the MEMO state machine, which consists of three core components: a transaction simulator, a conflict detector, and a vector generator. The transaction simulator performs a sandboxed pre-execution of each state migration path in an isolated off-chain environment. By cloning a snapshot of the current global state of the distributed ledger network as a simulation baseline, it applies transaction operations one by one and records the state change trajectory.

[0023] During the above process, the asynchronous data processing system utilizes improved snapshot isolation technology to create an independent, versioned state view for each simulation thread, preventing state contamination between different prediction tasks. The conflict detector identifies cross-transaction data races by comparing the intermediate states of multiple simulation threads in real time. For example, if two state transition paths attempt to simultaneously modify the balance field of the same account, a conflict detection flag is generated containing the conflicting account address and the type of competing operation. The vector generator encodes the final simulation results into predicted state vectors. Each vector contains not only basic state information such as account balances and contract storage tree root hashes, but also embeds operation validity proofs and state version watermarks. For example, when processing state transition paths involving token swap protocols, the prediction engine generates a composite vector containing changes in liquidity pool reserves, slippage verification results, and price impact factors of the trading pair, providing fine-grained decision-making information for subsequent feature fusion. The asynchronous data processing system utilizes dynamic thread pool management technology to achieve elastic scalability of prediction tasks. When a state transition path is detected that requires complex computation (such as zero-knowledge proof verification), dedicated computing units are automatically allocated to accelerate processing.

[0024] Step 160: Perform feature fusion on the N predicted state vectors according to the conflict detection flags to generate a global state update matrix.

[0025] In this embodiment, the asynchronous data processing system deploys a vector fusion framework based on the principle of quantum entanglement. This vector fusion framework projects N predicted state vectors into a high-dimensional feature space for conflict resolution. Specifically, the conflict detection tags are first hierarchically classified using a topological sorting algorithm, and vectors involving modifications to the same account state are grouped into conflict groups. Within each conflict group, a partial order relationship is established based on transaction timestamps and block heights. For conflict groups with write-after-read dependencies, the system adopts an optimistic concurrency control strategy, comparing the overlap of operation time windows to determine whether a state rollback is required. For example, when two predicted state vectors perform operations of +100 and -50 on an account balance, respectively, and their timestamps partially overlap, the feature fusion engine will create a virtual merge operation (+50) to eliminate the conflict.

[0026] Furthermore, the global state update matrix is ​​constructed using a layered accumulation mechanism: the base layer stores absolute account state values ​​(e.g., balance), the incremental layer records relative state changes (e.g., accrued interest), and the metadata layer stores the smart contract execution context associated with each transaction. Each cell in the matrix is ​​attached with a version lock mechanism to prevent dirty writes during the consensus verification phase. The asynchronous data processing system incorporates fuzzy hashing technology at this stage to verify state correlations across accounts within the matrix. For example, it checks whether the initiator's debit and the recipient's credit in a transfer transaction adhere to the law of value conservation, thereby proactively preventing the risk of account imbalances caused by forecasting errors.

[0027] Step 180: Write the global state update matrix into the consensus node set of the distributed ledger network, and generate an asynchronous processing state log that matches the transaction request set.

[0028] In this embodiment, the asynchronous data processing system can distribute the global state update matrix to the consensus node cluster of the distributed ledger network via an atomic broadcast protocol. Each consensus node runs an improved practical Byzantine fault-tolerance algorithm, performing multiple rounds of cross-validation on the matrix data: the first round of verification checks the integrity of the matrix's digital signature chain, the second round of verification verifies the correctness of state changes by re-executing key transaction paths, and the third round of verification performs an arithmetic consistency check on the final account state after conflict resolution. It can be understood that the matrix data that passes consensus is encoded as a new block of the blockchain, and the block header specifically embeds the periodic check code of the MEMO state machine. This check code is generated by aggregating the hash digests of all predicted state vectors through a Merkle tree structure.

[0029] The asynchronous data processing system synchronously generates fine-grained asynchronous processing status logs, and the log entries adopt a layered storage architecture: the hot storage layer retains the complete operation traces of the last two days and supports real-time audit queries; the cold storage layer compresses historical logs into state difference snapshots and stores them in distributed edge nodes through distributed hash tables. For example, the asynchronous data processing system performs log rolling operations every morning, column-compressing MEMO transaction records from 48 hours ago, and sharding them according to account addresses to geographically distributed archive nodes, while only retaining the index pointer of the latest transaction record in the front-end database. The entire processing flow is continuously optimized through a closed-loop feedback mechanism. The asynchronous data processing system regularly analyzes conflict patterns and processing delay data in historical logs, dynamically adjusts the parameter configuration and thread scheduling strategy of the state prediction algorithm, and realizes autonomous improvement of system performance.

[0030] Based on the above, in an exemplary application scenario of a cross-border payment platform supported by a distributed ledger network, the asynchronous processing mechanism demonstrated strong capacity when a regional node encountered a sudden surge in high-concurrency transactions. A large number of user requests for cross-regional remittances, digital asset pledges, and other services, initiated through external payment gateways, flooded the asynchronous data processing system, generating a collection of thousands of standardized transaction data blocks to be processed. These data blocks were uniquely identified by blockchain addresses and adhered to strict encoding rules, including transaction versions, multi-signature verification, and metadata embedding. For example, a cross-time zone transfer included both fund flow path parameters and embedded dynamic business indicators such as exchange rate fluctuation tolerance thresholds. The asynchronous data processing system rapidly eliminated transactions with invalid signatures or abnormal formats through an automated filtering layer. Furthermore, based on pre-set rules, operations involving core system accounts were marked as high-priority transactions, and scenarios such as cross-time zone settlements were classified as candidates for asynchronous processing. When the real-time monitoring module finds that the backlog of the node memory pool exceeds the critical value and the processing delay continues to rise, the asynchronous data processing system immediately triggers the batch processing mechanism, encapsulating the pending transactions together with the load balancing strategy and resource allocation plan into a structured event unit, establishing standardized input for subsequent distributed processing.

[0031] In this application scenario, faced with a heterogeneous set of transactions, the asynchronous data processing system uses a semantic parsing engine to convert each transaction into a migration path recognizable by the state machine. For example, when processing a digital asset pledge request, the asynchronous data processing system dynamically verifies the ratio between the collateral value and the loan amount, obtains real-time price data from an on-chain oracle to assess migration conditions, and generates target instructions containing smart contract state locks. During this process, the asynchronous data processing system accurately identified data contention between multiple transactions concurrently modifying core system accounts and discovered that the validation of remittances in a certain time zone depends on the periodic batch processing results of a specific node. By constructing a cross-transaction state dependency topology, the asynchronous data processing system dynamically assigns execution priorities to paths involving core accounting logic, ensuring that critical state changes are prioritized for verification. This mechanism, combined with timestamp sequence analysis and dynamic weight adjustment, maintains accounting atomicity while providing flexible processing space for cross-regional transaction timing coordination.

[0032] During the parallel prediction phase, the asynchronous data processing system creates an isolated sandbox environment for each transaction to simulate state transitions. For example, when processing a staking contract, the asynchronous data processing system clones the on-chain storage state and deduces the precise relationship between asset lockup and interest calculation. Simultaneously, it detects a smart contract storage conflict with another operation modifying liquidation parameters. For cross-regional remittance scenarios, the asynchronous data processing system simulates settlement verification processes in different time zones and identifies compliance verification exceptions in one target region due to reaching regulatory limits. Using versioned snapshot isolation technology, the asynchronous data processing system creates an independent view for transactions that concurrently modify the same account state. For example, when processing concurrent income and expenditure operations on an account, a state replica with a timestamp is generated to ensure data isolation during pre-execution. This high-precision simulation not only outputs a prediction vector containing proof of operation validity but also uses a tagging system to precisely locate account-level data races and contract-level logic conflicts. During the feature fusion phase, a multi-dimensional conflict resolution strategy can be employed to ensure account integrity. The asynchronous data processing system uses high-dimensional spatial projection technology to perform correlation analysis on prediction vectors. For example, it merges the values ​​of concurrent income and expenditure operations for an account, converting discrete transactions into net balance changes. Transactions that reach regulatory limits are automatically deferred to the next processing cycle. The system also coordinates the order of smart contract state updates based on timestamp priority. When constructing the global state matrix, the asynchronous data processing system implements a layered recording mechanism: the base layer solidifies the final account state values, the incremental layer captures continuous changes such as interest calculations, and the metadata layer preserves the transaction context chain. Fuzzy hashing technology is used to verify cross-account value conservation. For example, it verifies that the total expenditures and total receipts plus fees for a batch of remittance transactions are precisely balanced, thus preventing accounting vulnerabilities caused by simulation errors. This integration of mathematical induction and policy scheduling significantly improves throughput efficiency in high-concurrency scenarios while maintaining strong consistency in the distributed ledger.

[0033] After multiple rounds of consensus verification, the state matrix ultimately forms an immutable account record, which is synchronized to the global node network via the atomic broadcast protocol. Nodes in specific regions verify the integrity of the data signature chain, while some nodes ensure zero error in the calculation process through sampling re-execution. All nodes collaboratively verify the Merkle root consistency of the ledger data. The asynchronous processing logs generated by the asynchronous data processing system implement a hierarchical storage strategy. Recent data is retained in a hot storage layer for rapid retrieval, while historical records are sharded and compressed according to regional characteristics and stored in distributed edge nodes. By analyzing conflict patterns in the logs through a machine learning module, the asynchronous data processing system autonomously optimizes its processing strategy: dynamically expanding prediction resources during peak trading hours and offloading complex cryptographic verification tasks to heterogeneous computing units. This closed-loop optimization system enables the platform to demonstrate significant advantages in handling sudden traffic bursts, not only significantly improving the error interception rate but also reducing the average processing time for cross-regional remittances to seconds. Therefore, the asynchronous processing framework provided in the embodiments of the present application effectively ensures the technical robustness and stability of high-concurrency, multi-time zone, and heterogeneous transaction scenarios.

[0034] In an optional embodiment, the MEMO state machine-based parallel prediction module in step 140 asynchronously processes the M state transition paths to generate N predicted state vectors and corresponding conflict detection flags, including:

[0035] Step 141: calling the state transition probability model of the MEMO state machine, performing path segmentation on each of the M state transition paths, and obtaining L path segmentation units.

[0036] In this embodiment, when the state transition probability model of the MEMO state machine is invoked to segment each of the M state transition paths, the asynchronous data processing system analyzes the conditional predicates and transition constraint functions preset in the state transition paths to identify nonlinear operation nodes within the paths. For example, when processing a state transition path involving a digital asset pledge transaction, the state transition probability model detects that the path contains two operation nodes: the collateral lockup phase and the interest calculation phase. Based on the segmentation threshold in the dynamic pledge rate calculation rules, the original path is segmented into two path segments: the collateral lockup unit and the interest calculation unit. Each path segment consists of an independent initial state node, a transition condition predicate, a target state node, and a transition constraint function. The segmentation process ensures that the state dependencies between each unit are verified through a global state snapshot. Specifically, the collateral lockup unit's transition constraint function verifies whether the collateral amount meets the minimum limit specified by the smart contract, while the interest calculation unit generates an accumulated interest value based on the lockup period and the benchmark interest rate parameter.

[0037] Step 142: Use an asynchronous thread pool to perform parallel processing on the L path segmentation units to generate a state transition prediction value for each path segmentation unit.

[0038] In this embodiment, when an asynchronous thread pool is used to process the L path segmentation units in parallel, the asynchronous data processing system dynamically allocates thread resources based on the computational complexity of the path segmentation units. For example, when processing the state migration path segmentation unit of a cross-border remittance transaction, the asynchronous data processing system allocates a high-priority thread to the account balance verification unit. This thread calls the global account state tree of the distributed ledger network in an isolated off-chain sandbox environment to verify whether the available balance of the initiating account satisfies the sum of the transfer amount and the handling fee. At the same time, a standard thread is allocated to the exchange rate conversion unit. This thread obtains real-time exchange rate data through an on-chain oracle and performs multi-currency conversion calculations. The state transition prediction value generated by each thread includes an operation result code, a state change summary, and a resource consumption indicator. The output prediction value of the account balance verification unit includes a hash summary after the balance is deducted, and the output prediction value of the exchange rate conversion unit includes the target currency amount and the exchange rate fluctuation tolerance verification result. The asynchronous data processing system uses a thread isolation mechanism to ensure that the intermediate states of different segmentation units do not interfere with each other.

[0039] Step 143: Time-series aggregate the state transition prediction values ​​of the path segment units belonging to the same state transition path to generate an initial predicted state vector of the state transition path.

[0040] In this embodiment, when time-sequentially aggregating the state transition prediction values ​​of path segment units belonging to the same state transition path, the asynchronous data processing system establishes a timestamp dependency chain based on the execution order of each segment unit. For example, when processing the state transition path of a smart contract triggering a transaction, the predicted value of the contract initialization unit includes the storage space allocation result, the predicted value of the contract parameter loading unit includes the input parameter parsing status, and the predicted value of the contract execution unit includes the function call return value. The system (the asynchronous data processing system) hierarchically overlays the predicted values ​​of the three segment units according to the timestamp sequence, and uses a weighted average algorithm to combine the storage space address, parameter check flag, and execution result to generate an initial predicted state vector containing the contract storage tree root hash, execution context pointer, and total gas consumption. During this process, the asynchronous data processing system uses version merging technology to resolve state version conflicts across segment units. For example, when the parameter loading unit and the execution unit write to the same storage slot, the system retains the last valid written value based on the overlap of the operation time windows.

[0041] Step 144: performing conflict feature extraction on the initial predicted state vector to obtain the conflict type identifier and conflict weight in the conflict detection mark.

[0042] In this embodiment, when extracting conflict features from the initial predicted state vector, the asynchronous data processing system uses a multi-dimensional feature analysis engine to identify abnormal patterns within the vector. For example, if a predicted state vector indicates that a leaf node in the smart contract storage tree experiences a nonlinear numerical transition during an interest calculation cycle, the system calculates the standard deviation offset of the current vector in the time dimension by comparing the interest accumulation curves of similar contracts in the historical state vectors. When the offset exceeds a preset threshold, the conflict classification model identifies it as a smart contract logic conflict and generates a high-priority conflict type identifier. Simultaneously, the system calculates a conflict weight using a linear proportional formula based on the peak memory usage and CPU time usage of the vector during simulation execution. This ensures that conflict events with higher resource consumption receive a higher priority for subsequent correction. During this process, the asynchronous data processing system maintains a dynamic mapping between the conflict weight and the real-time load status of the distributed ledger network, ensuring that the calculated resource utilization reflects the actual processing capacity of the current node.

[0043] Step 145: Dynamically modify the initial prediction state vector based on the conflict weight, generate a target prediction state vector, and mark the target prediction state vector as an element in the N prediction state vectors.

[0044] In this embodiment, the asynchronous data processing system implements a multi-stage correction strategy when dynamically revising the initial predicted state vector based on the conflict weights. For example, when a predicted vector is detected to contain an account balance conflict and the conflict weight reaches 0.7, the system first queries the global account lock status of the distributed ledger network. After confirming that the conflicting account is not locked by other transactions, it uses an optimistic locking mechanism to perform a secondary validation of the predicted value: the difference between the initial predicted balance change and the account's latest on-chain state is calculated. If the difference is within a reasonable fluctuation range within the transaction time window, the predicted value is corrected by smoothing interpolation proportional to the conflict weight. The corrected target predicted state vector not only contains the adjusted final account state value, but also includes a version compatibility indicator and conflict resolution proof. The system marks the corrected vector as a valid prediction element and feeds back the resource usage metrics associated with the vector to the load balancing controller for optimizing the allocation strategy of subsequent transaction data blocks. During this process, the correction results of high-weight conflict events trigger detailed records in the asynchronous processing state log, providing complete behavioral chain evidence for subsequent audit trails.

[0045] In a preferred embodiment, the step 144 of extracting conflict features from the initial predicted state vector to obtain the conflict type identifier and conflict weight in the conflict detection mark includes:

[0046] Step 1441: Extract the dimensional distribution features of the initial predicted state vector, and calculate the dimensional offset between the dimensional distribution features and the historical state vector.

[0047] In this embodiment, when extracting the dimensional distribution features of the initial predicted state vector, the asynchronous data processing system converts the dimensional data in the vector, such as account balance, contract storage tree depth, and operation timestamp, into a standardized feature matrix. For example, for the predicted state vector of a cross-chain asset transfer transaction, the system calculates the balance growth rate of the target chain account address, the balance decay gradient of the source chain locked account, and the storage tree change frequency of the cross-chain bridge contract, respectively, to form a three-dimensional feature distribution map. By comparing the feature distribution of historical successful transaction cases, the system quantifies the offset amplitude of the current vector in each dimension. For example, if it detects that the growth rate of the target chain account balance is two standard deviations lower than the historical mean, it marks the dimension as potentially abnormal. The calculation of the dimensional offset uses the Mahalanobis distance algorithm to eliminate the impact of the dimensional differences of different dimensions on conflict detection.

[0048] Step 1442: Input the dimension offset into a pre-trained conflict classification model and output the conflict type identifier.

[0049] In this embodiment, when the dimension offset is input into the pre-trained conflict classification model, the asynchronous data processing system activates a multi-layer convolutional network to perform local gradient pattern matching on the feature matrix. For example, when it is detected that the account balance dimension and the contract storage dimension of a certain predicted state vector have inverse fluctuation characteristics, the convolution kernel extracts the high gradient change area in the corresponding area of ​​the feature matrix, aggregates the feature response values ​​of these areas through the pooling layer, and outputs the type identification of the conflict as being inconsistent between the account state and the contract logic. The conflict type labels used in the model training phase include seven predefined categories, such as account balance conflicts, smart contract storage conflicts, and cross-chain transaction consistency conflicts. Each category corresponds to a specific correction strategy template. During the real-time classification process, the system synchronously updates the convolution kernel weights of the feature extraction layer to adapt to the new conflict patterns brought about by the protocol upgrade of the distributed ledger network.

[0050] Step 1443: Call the corresponding weight calculation rule according to the conflict type identifier to generate a conflict weight that is positively correlated with the resource occupancy rate of the current transaction data block.

[0051] In this embodiment, when invoking the corresponding weight calculation rule based on the conflict type identifier, the asynchronous data processing system configures differentiated calculation parameters for different conflict types. For example, for account balance conflicts, the weight calculation rule weights the transaction data block's memory usage and network bandwidth consumption in a 1:3 ratio; for smart contract storage conflicts, the system prioritizes a composite metric of CPU computing time and storage IO operations. The system uses a sliding window mechanism to calculate the current node's resource usage baseline and uses the ratio of the transaction data block's actual resource usage to the baseline value as the adjustment coefficient for the conflict weight. When processing a concurrent operation conflict for a high-frequency trading account, the system detects that the transaction occupies 70% of the node's memory resources and immediately generates a conflict weight of 0.85. This weight directly influences the intervention intensity of subsequent state corrections.

[0052] In this embodiment, the conflict classification model is trained through step 14420. Step 14420: State vector samples of historical conflict events are collected, conflict type labels are assigned to the state vector samples, local gradient features of the state vector samples are extracted using a multi-layer convolutional network, and the classification loss function is optimized through backpropagation. In this embodiment, when training the conflict classification model, the asynchronous data processing system constructs a training dataset containing millions of historical conflict event samples. Each sample includes complete predicted state vector metadata, conflict type label, and processing result feedback. The system uses a depthwise separable convolutional structure to hierarchically extract the spatiotemporal features of the state vector: the first convolution kernel captures the correlation pattern between account balances and timestamps, the second convolution kernel identifies topological changes in the smart contract storage tree, and the third convolution kernel analyzes the hash locking relationship of cross-chain transactions. During training, the cross-entropy loss function is optimized through a backpropagation algorithm, and an attention mechanism is introduced to enhance the ability to identify rare conflict types. For example, for cross-chain atomic swap conflicts, which only account for 0.3% of the total sample, the system automatically increases its weight coefficient in the loss function to ensure that the model does not ignore the detection of such key conflicts due to uneven data distribution.

[0053] In a preferred embodiment, writing the global state update matrix to the consensus node set of the distributed ledger network in step 180 includes:

[0054] Step 181: Divide the global state update matrix into P data shards according to the write priority of the asynchronous processing status log; the write priority is determined by counting the historical processing delay of the transaction data block associated with each data shard in the global state update matrix, and generating a priority score that is negatively correlated with the historical processing delay.

[0055] In this embodiment, the asynchronous data processing system dynamically determines write priorities based on the historical processing delays of different data shards in the global state update matrix. For example, when processing a global state update matrix containing digital asset pledge transactions and cross-chain remittance transactions, the system first searches historical logs for similar transactions. Digital asset pledge transactions, due to the smart contract state locking operation, have a historical average processing delay of 450 milliseconds; whereas cross-chain remittance transactions, due to the multi-node collaborative verification required, have a historical average processing delay of 1200 milliseconds. The system assigns a priority score of 0.85 to the data shard corresponding to the digital asset pledge transaction and a priority score of 0.65 to the cross-chain remittance transaction shard, forming a negative correlation mapping. During the segmentation process, the asynchronous data processing system uses a space-filling curve algorithm to partition the matrix into P data shards, ensuring that high-priority shards contain contiguously stored account state units. For example, the pledge transaction shard centrally stores associated fields such as the pledged account address, the amount of pledged collateral, and the smart contract lock status. This physical storage continuity optimizes read efficiency for subsequent nodes.

[0056] Step 182: Assign a target node group in the consensus node set to each data shard, and generate a data shard hash identifier with a timestamp.

[0057] In this embodiment, the asynchronous data processing system implements a geo-aware strategy when assigning target node groups to each data shard. For example, for a cross-chain remittance transaction shard, which involves collaborative verification between nodes in Asia and Europe, the system selects consensus nodes located in Singapore and Frankfurt as its target node group. This node group is pre-configured with a low-latency cross-border communication line. After the assignment is complete, the system generates a hash identifier with a nanosecond timestamp for each shard. This structure employs a two-layer hashing structure: an inner hash generates a SHA3-512 digest value based on the byte stream of the shard content, and an outer hash concatenates the digest value with the timestamp and hashes it again to form a shard identifier with strong collision resistance. For example, for a digital asset pledge transaction shard, its hash identifier not only includes a summary of core fields such as the pledge amount and lockup time, but also embeds a distributed clock synchronization timestamp accurate to 100 nanoseconds, ensuring that global nodes can verify the authenticity of the shard generation time.

[0058] Step 183: Broadcast the data shard and the hash identifier of the data shard to the target node group, and receive a verification pass signal returned by the target node group.

[0059] In this embodiment, the asynchronous data processing system implements a layered verification mechanism when sending data shards and their hash identifiers to the target node group via the atomic broadcast protocol. For example, when broadcasting a cross-chain remittance shard to the A2 node group, the first round of verification requires the node to verify the consistency of the inner and outer hashes of the shard hash identifier to confirm that the shard content has not been tampered with; the second round of verification triggers the smart contract execution engine to replay the key transaction path in the shard to verify whether the account status change complies with the business rules. The verification pass signal returned by the node group contains three authentication elements: the digital signature of the shard hash identifier, the content integrity check code, and the business logic compliance proof. Taking the verification of the digital asset pledge shard as an example, after receiving the shard, the Frankfurt node first verifies whether the timestamp of the hash identifier is within the valid time window, then calls the pledge contract verification module to confirm that the pledge rate calculation process is completely consistent with the on-chain governance rules, and finally generates a verification pass signal containing the node digital certificate signature.

[0060] Step 184: When more than a preset ratio of verification pass signals are received, the data shards are written into the persistent storage chain of the target node group.

[0061] In this embodiment, the asynchronous data processing system performs a shard write operation after receiving a preset proportion of verification pass signals. For example, when the cross-chain remittance shard obtains verification pass signals from 80% of the members of the node group in region A, the system triggers the cross-region write coordination protocol: first, a temporary write buffer is created in the shared storage pool of the target node group, and the shard data and the verification signal metadata are combined into an atomic write unit; then, a two-phase commit protocol is used to ensure that the transaction logs of all nodes are updated synchronously; finally, the shard data is written to the block body of the persistent storage chain, and the digital signature set of the verification node group is recorded in the block header. Taking the digital asset pledge shard as an example, after the write is completed, the system marks the atomicity mark of the shard in the metadata layer of the storage chain, and constructs a Merkle tree index structure containing the shard hash identifier, so that subsequent query operations can quickly verify the integrity of the shard through Merkle proof. After all write operations are completed, the participating nodes synchronously update the local state copy and broadcast the write confirmation event to the entire network, forming a closed-loop verification chain.

[0062] In a preferred embodiment, the parsing of the asynchronous processing triggering event to generate a state transition instruction sequence in step 120 includes:

[0063] Step 121: extracting the event type code and event dependency graph from the asynchronous processing trigger event.

[0064] In this embodiment, the asynchronous data processing system extracts event type codes and event dependency graphs from asynchronous processing trigger events by parsing the semantic structure of the triggering event tuples to achieve precise classification. For example, when a regional node in a distributed ledger network triggers a batch processing event due to a memory pool backlog, the system first identifies the "high-throughput cross-chain remittance" identifier in the event type code. This code uses a hierarchical bitfield structure: the first 16 bits indicate the transaction type (0x01 indicates a cross-chain operation), the middle 32 bits record the priority score (0x85 indicates high priority), and the last 64 bits store the time window identifier (a combination of a UTC timestamp and a processing cycle number). The event dependency graph is constructed by analyzing the account interaction patterns between transaction data blocks. For example, if five cross-chain remittance transactions are detected, all involving asset transfers from the same liquidity pool, the system draws a topological graph consisting of five nodes and twelve directed edges. The edge weights indicate the strength of the balance change dependency between transactions. Specifically, in the event dependency graph, a remittance transaction from chain A to chain B points to another relay remittance transaction from chain B to chain C, forming a cross-chain transaction dependency chain.

[0065] Step 122: Generate dependency constraints for state transition instructions based on the event dependency graph.

[0066] In this embodiment, the asynchronous data processing system uses graph theory algorithms to transform transaction association rules when generating dependency constraints for state transition instructions based on an event dependency graph. For example, when processing a dependency graph involving digital asset staking and interest settlement, the system identifies the predecessor-successor relationship between the staking transaction node and the interest calculation node, generating a hard constraint requiring interest calculation to be initiated before the collateral lock status is verified. For dependencies involving parallel paths, the system introduces a resource lock mechanism: when two transactions are detected requiring simultaneous modifications to a smart contract's storage tree, a dynamic constraint requiring exclusive locks to be acquired for access to shared contract storage slots is generated. For example, in a cross-chain remittance scenario, a node in the dependency graph must wait for the inter-chain bridge contract to confirm the cross-chain asset freeze operation. To address this, the system generates a composite dependency constraint consisting of a timestamp threshold and on-chain proof verification conditions.

[0067] Step 123: calling the instruction generation model to decode the event type code and generate a candidate instruction set carrying dependency constraints.

[0068] In step 123, the asynchronous data processing system invokes the instruction generation model to decode the event type code and generate a candidate instruction set, implementing a multi-stage semantic transformation. For example, for the "high-priority cross-chain remittance" event type code, the model first generates a basic instruction sequence: "lock source chain account balance → verify cross-chain bridge contract status → create target chain posting transaction," each instruction carrying dependency constraints. When processing a digital asset pledge event, the model outputs an instruction chain: "verify pledge ownership → calculate dynamic pledge ratio → update smart contract lock status," where the dynamic pledge ratio calculation instruction carries the constraint of "requiring real-time data from an on-chain price oracle." During this process, the instruction generation model analyzes the priority identifier in the event type code and inserts preemptive resource allocation instructions for high-priority transactions. For example, for cross-chain operations involving core system accounts, the constraint of "preferentially occupying cross-chain channel bandwidth" is added.

[0069] Step 124: Perform instruction conflict detection on the candidate instruction set, filter out invalid instructions with circular dependencies or resource contention conflicts, and obtain a target instruction set.

[0070] In this embodiment, the asynchronous data processing system adopts a strategy that combines static analysis and dynamic simulation when performing instruction conflict detection on candidate instruction sets. For example, when it is detected that there are concurrent operations of "locking the balance of source chain account A" and "modifying the fee parameters of source chain account A" in a certain cross-chain remittance candidate instruction set, the system marks it as a storage conflict between the balance and parameter areas, triggering the instruction filtering mechanism. For instructions involving smart contract state migration, the system simulates the execution path through a sandbox environment. When it is found that the "update the pledge contract storage tree" instruction and the "liquidation contract trigger condition detection" instruction have a read-write dependency loop, it is determined to be a circular dependency conflict and removed from the candidate set. During the detection process, a resource competition matrix is ​​used to record the occupancy pattern of each instruction on the distributed ledger network resources. For example, when identifying that two instructions apply for exclusive access rights to the same batch processing queue at the same time, the higher priority instruction is automatically retained.

[0071] Step 125: Sort the target instruction set according to the dependency constraints to generate the state transition instruction sequence.

[0072] In this embodiment, the asynchronous data processing system implements topological sorting and dynamic scheduling when sorting the target instruction set according to dependency constraints to generate a state transition instruction sequence. For example, the instruction set for a digital asset staking scenario includes four instructions: "Verify collateral ownership → Obtain on-chain price data → Calculate dynamic staking ratio → Update contract lock status." The system constructs a directed acyclic graph based on the dependency constraints, generating a linear execution sequence. When encountering instructions with parallel constraints, such as "Verify source chain balance" and "Obtain target chain exchange rate" in cross-chain remittances, which can execute in parallel, the system inserts synchronization barrier instructions, forming a "parallel execution block → wait for all completion → continue with subsequent steps" structure. The sorting algorithm monitors the resource load of the distributed ledger network in real time and dynamically adjusts the instruction execution order. For example, when node computing resources are limited, the memory-intensive staking ratio calculation instruction is deferred to prioritize lightweight verification instructions.

[0073] In a preferred embodiment, the call instruction generation model in step 123 decodes the event type code to generate a candidate instruction set carrying dependency constraints, including:

[0074] Step 1231: Input the event type code into the encoder of the sequence generation sub-model of the instruction generation model, and output the event semantic feature vector; the instruction generation model is trained in the following manner: adopting a masked sequence-to-sequence architecture, performing autoregressive prediction on the historical event type codes and the corresponding target instructions, and optimizing the conflict avoidance reward value of the target instructions through reinforcement learning.

[0075] In this embodiment, the asynchronous data processing system implements feature space mapping when inputting event type codes into the sequence generation sub-model of the instruction generation model. For example, the binary bit stream encoding the cross-chain remittance event type passes through the encoder's multi-head self-attention layer and is converted into a 512-dimensional event semantic feature vector. This vector captures core semantics such as transaction type, priority weight, and spatiotemporal constraints. The model training phase utilizes millions of samples from historical event logs, randomly masking local bit fields of the encoding fields through a masking mechanism to force the model to learn the inherent relevance of the encoding structure. During the reinforcement learning optimization process, the system calculates a conflict avoidance reward for each generated candidate instruction. For example, instructions that successfully avoid account lock contention receive positive rewards, while instructions that trigger storage tree version conflicts are penalized, driving the model parameters to converge toward low-conflict scenarios.

[0076] Step 1232: Use the attention mechanism to match the event semantic feature vector with the historical instruction template library to generate an attention weight distribution.

[0077] In this embodiment, the asynchronous data processing system uses an attention mechanism to match event semantic feature vectors with historical instruction templates, enabling context-aware template retrieval. For example, when processing the feature vector of a digital asset pledge event, the attention layer activates template entries related to "collateral verification," "interest rate calculation," and "status lock" in the historical template library, generating corresponding attention weight distributions. This weighting is calculated using a scaled dot-product attention algorithm. The similarity score between the pledge event feature vector and the pledge operation template vector in the historical template library is calculated, resulting in a high weight of 0.78, while the similarity score with the cross-chain remittance template is only 0.12. The system uses a sliding window mechanism to limit the scope of attention, ensuring that template matching focuses on the optimal historical solution for similar events.

[0078] Step 1233: Filter the Top-R candidate templates from the historical instruction template library according to the attention weight distribution.

[0079] In this embodiment, the asynchronous data processing system implements dynamic threshold control when screening the top-R candidate templates based on the attention weight distribution. For example, when processing a cross-chain remittance event, the system selects the top five weighted templates from the historical template library, including the "Fast Track Cross-Chain Template," the "Multi-Signature Verification Cross-Chain Template," and the "Batch Processing Cross-Chain Template." This screening process utilizes an adaptive threshold algorithm: when the semantic difference between high-weight templates falls below a preset threshold, the number of candidates is automatically expanded to R+3 to avoid missing key variant templates. For example, in the case of digital asset staking, the system selects three top-R candidates: the "Standard Staking Template," the "Over-Staking Template," and the "Joint Staking Template," each with a distinct set of constraints.

[0080] Step 1234: logically combine the candidate template and the dependency constraint conditions to generate the candidate instruction set.

[0081] In this embodiment, the asynchronous data processing system implements formal verification to ensure consistency when logically splicing candidate templates with dependent constraints. For example, when splicing a "Fast Track Cross-Chain Template" with a constraint requiring execution after the target chain's block height reaches a threshold, the system inserts a block height listener clause before the template's bridge contract call instruction, forming a compound instruction: "Wait for target chain block height ≥ N → trigger cross-chain transfer." For templates involving multiple competing resources, the splicing process incorporates a logical disjunction: when the "Multi-Signature Verification Cross-Chain Template" encounters the constraint requiring consensus verification within 30 seconds, the system generates a branch instruction: "If multi-signature verification times out, switch to fast track mode." All spliced ​​candidate instructions are checked by the formal verification engine to ensure temporal logical consistency between the constraints and the template operations.

[0082] In an optional embodiment, the method further comprises:

[0083] Step 200: When it is detected that there is a pending state in the global state update matrix, a sub-state machine splitting mechanism of the MEMO state machine is triggered.

[0084] In this embodiment, when a pending state is detected in the global state update matrix, the asynchronous data processing system triggers the sub-state machine splitting mechanism of the MEMO state machine. For example, when processing the global state update matrix involving cross-chain atomic swaps, the system discovers that the target chain account entry operation of a cross-chain remittance transaction failed to complete due to network delays, resulting in a pending conflict between the asset lock state of the source chain and the account entry state of the target chain. At this time, the system analyzes the metadata associated with the pending state and identifies that the transaction includes three separable operation stages: source chain lock, cross-chain bridge verification, and target chain account entry, triggering the sub-state machine splitting mechanism. Specifically, the MEMO state machine generates a sub-state machine splitting condition containing transaction rollback compensation logic based on the transaction atomicity identifier of the pending state, ensuring that the split sub-state machine instance has independent transaction integrity protection capabilities.

[0085] Step 202: Extract Q sub-transaction features from the transaction data block associated with the pending state and generate Q independent sub-state machine instances; the sub-transaction features are extracted in the following manner: based on the operation type, resource access mode and transaction atomicity identifier of the transaction data block, generate a feature vector that matches the sub-state machine splitting condition.

[0086] In this embodiment, the asynchronous data processing system utilizes a multi-dimensional feature extraction engine to extract Q sub-transaction features from transaction data blocks associated with pending states. For example, for the pending transaction data block of the aforementioned cross-chain atomic swap, the system interprets the operation type field as "cross-chain asset transfer," analyzes the resource access pattern as "source chain account read lock → cross-chain bridge contract write operation → target chain account write operation," and identifies the transaction atomicity as "full-chain transaction atomicity." Based on this, three sub-transaction feature vectors are generated: a source chain lock feature vector containing the account address, locked amount, and timestamp; a bridge verification feature vector containing the bridge contract address and the cross-chain proof hash value; and a target chain credit feature vector containing the target account address and exchange rate conversion parameters. Each feature vector is converted through a hash mapping algorithm into a 128-bit feature code that matches the sub-state machine splitting condition, ensuring that the generated sub-state machine instances accurately correspond to the semantic segmentation requirements of the original transaction.

[0087] Step 204: Use an asynchronous pipeline to process the Q sub-state machine instances in parallel and generate a sub-state machine processing result queue.

[0088] In this embodiment, the asynchronous data processing system implements resource isolation and dynamic scheduling when using asynchronous pipelines to process Q sub-state machine instances in parallel. For example, independent resource isolation domains are allocated to the three sub-state machine instances of cross-chain atomic swaps: the source chain locking instance is allocated a high-priority CPU core and memory pool block; the bridge verification instance is allocated a dedicated cryptographic acceleration unit; and the target chain accounting instance is allocated the local storage partition of the target chain node. The system deploys a flow control strategy in the asynchronous pipeline to monitor the resource consumption indicators of each instance in real time. When it is detected that the GPU memory occupancy rate of the bridge verification instance exceeds the 85% threshold, the PID controller automatically reduces its thread scheduling weight and increases the processing priority of the source chain locking instance. When the processing delay of the target chain accounting instance exceeds 3 seconds due to excessive load on the target node, the instance migration mechanism encapsulates its complete context state into a migration package and transmits it to the backup node group through a low-latency network for re-mounting and execution.

[0089] Step 206: Monitor the completion status of the sub-state machine processing result queues. When all sub-state machine instances are completed, merge the processing results and update the global state update matrix.

[0090] In this embodiment, when monitoring the completion status of the sub-state machine processing result queue, the asynchronous data processing system adopts an event-driven state synchronization protocol. For example, when the three sub-state machine instances of the cross-chain atomic exchange all return a completion signal, the system initiates a two-stage merge operation: the first stage verifies the integrity of the digital signature chain of each instance to confirm that the processing result has not been tampered with; the second stage performs a logical merge, combining the three results of source chain account unlocking, bridge proof cancellation, and target chain account confirmation into an atomic operation unit according to the transaction atomicity rules. The merged result is updated to the cross-chain transaction partition of the global state update matrix, and the original pending state is marked as resolved. During the update process, version superposition technology is used to record the contribution weight of each sub-state machine instance in the metadata layer of the matrix. For example, the source chain locking instance contributes 40%, the bridge verification accounts for 30%, and the target chain account accounts for 30%, providing a traceability basis for subsequent transaction analysis.

[0091] In an optional embodiment, the asynchronous pipeline in step 204 is used to process Q sub-state machine instances in parallel, including: allocating an independent resource isolation domain and processing thread to each sub-state machine instance; setting a flow control strategy in the asynchronous pipeline to dynamically adjust the processing order of the sub-state machine instances; when it is detected that the processing delay of the target sub-state machine instance exceeds a threshold, triggering the instance migration mechanism to migrate the target sub-state machine instance to a low-load node; wherein the flow control strategy is implemented by the following steps 2040: real-time collection of resource consumption indicators of each sub-state machine instance in the pipeline, and using a PID controller to adjust the thread scheduling weight so that the resource consumption indicator is within a preset safety range. In this embodiment, when collecting resource consumption indicators of each sub-state machine instance in the pipeline in real time, the asynchronous data processing system deploys a distributed indicator collection agent. For example, for the source chain locking sub-state machine instance, the agent continuously collects its CPU utilization, memory page error rate, and account lock contention number; for the bridge verification instance, it focuses on monitoring the zero-knowledge proof verification time and the cross-chain message queue depth. The PID controller normalizes various metrics into resource consumption pressure values ​​and dynamically adjusts thread pool weights using a proportional-integral-derivative algorithm. When the pressure on a source chain lock instance exceeds the upper limit of the safety interval, the controller reduces its thread quota by 5% based on negative feedback, while simultaneously increasing the quota of the bridge verification instance by 3% to maintain overall pipeline throughput stability. The system's preset safety intervals are dynamically adjusted based on historical load patterns. For example, during peak cross-border payment periods, the GPU memory safety interval for the bridge verification instance is automatically extended to 90%.

[0092] In an optional embodiment, the method further comprises:

[0093] Step 300: When the generation period of the asynchronous processing status log reaches a preset threshold, a log compression optimization mechanism is triggered.

[0094] In this embodiment, when the generation cycle of the asynchronous processing status log reaches a preset threshold, the asynchronous data processing system triggers the log compression optimization mechanism. For example, the system is set to perform log compression once every 24 hours. When it is detected that the current log file size exceeds 128GB or the timestamp crosses UTC zero, the compression process is started. The system first freezes new log write requests, creates a log snapshot copy, and then performs compression on the snapshot copy. The compression trigger condition is linked to the load status of the distributed ledger network. When the network is in a low-load period, compression is automatically performed in advance to avoid resource competition during peak hours.

[0095] Step 302: extract frequent state transition patterns from the asynchronous processing state log and generate a state transition pattern index tree; the frequent state transition patterns are identified by using a sliding window to count the frequency of state transition events in the asynchronous processing state log, and using a clustering algorithm to classify state transition patterns with a frequency higher than a set frequency as frequent patterns.

[0096] In this embodiment, the asynchronous data processing system uses a sliding window analysis method combined with density clustering to extract frequent state transition patterns from asynchronous processing status logs. For example, when analyzing digital asset pledge transaction logs, the system set a 30-minute sliding window and found that the three-step transition pattern of "collateral lock → interest rate calculation → status update" occurred 1200 times within the window, exceeding the set threshold of 1000, classifying it as a frequent pattern. The clustering algorithm aggregates similar patterns into pattern clusters based on the temporal distribution characteristics of the transition events and account correlations. For example, it identified two sub-clusters: "fast pledge mode" (average completion time of 8 seconds) and "over-pledge review mode" (average completion time of 25 seconds). The generated pattern index tree uses a B+ tree structure, with leaf nodes storing pattern feature vectors and intermediate nodes recording temporal association rules between patterns, supporting pattern queries with O(logn) complexity.

[0097] Step 304: Merge and encode the consecutively repeated state transition events in the asynchronous processing state log to generate a compressed log block.

[0098] In this embodiment, when merging and encoding consecutive repeated state transition events in the asynchronous processing status log, the asynchronous data processing system implements differential encoding and run-length compression. For example, if it is detected that a clearing account has 50 consecutive interest accumulation operations with the same parameters within 10 minutes, the system will merge them into a single compressed log block, recording the start timestamp, end timestamp, number of operations, and cumulative total. The compression algorithm uses incremental storage technology. The basic record stores the complete context of the first operation, and subsequent operations only store the time difference and numerical increment. For smart contract status update logs, the system identifies multiple write operations with the same storage tree node path, retains only the final state value, and marks the version evolution path, reducing redundant storage consumption.

[0099] Step 306: Store the compressed log block in association with the state transition pattern index tree, and delete redundant entries in the asynchronous processing state log.

[0100] In this embodiment, when the compressed log block is stored in association with the state transition pattern index tree, the asynchronous data processing system establishes a bidirectional reference relationship. For example, when storing a compressed log block for cross-chain remittances, the node ID of the corresponding pattern index tree is embedded, and the index tree node extension stores a physical address pointer pointing to the compressed block. The associated storage adopts a sharding strategy, co-locating the frequently accessed compressed log block and the main body of the index tree in the storage node, and distributing the low-frequency historical data in the edge nodes. During the deletion of redundant entries, the system implements a three-level verification: the first level verifies the consistency of the compressed block hash value with the Merkle root of the original log; the second level verifies the reference integrity of the index tree node; and the third level audits the storage space release record to ensure that the deletion operation is traceable. The deleted storage space is updated to the resource scheduling center in real time and is preferentially allocated to high-priority log write requests.

[0101] In a preferred embodiment, the step 180 of generating an asynchronous processing status log matching the transaction request set includes:

[0102] Step 1801: extract the state change record set from the global state update matrix and generate an initial log sequence in chronological order.

[0103] In this embodiment, the asynchronous data processing system extracts state change records from the global state update matrix, capturing the complete operation trajectory by traversing the matrix's hierarchical storage structure. For example, when processing the global state update matrix for a cross-chain remittance transaction, the system extracts source chain account balance deduction records and target chain account credit records from the base layer, obtains the accumulated difference resulting from exchange rate conversion from the incremental layer, and reads the timestamp sequence of the smart contract execution context from the metadata layer. These records are sorted by operation completion time, forming an initial log sequence consisting of an operation type code, resource identifier, state change value, and a timestamp. For example, for a transaction involving digital asset staking, the initial log sequence sequentially records the collateral lockup time, the staking ratio calculation process, and the smart contract state update operation. Each log entry carries blockchain height and node location information, ensuring traceability across time and space.

[0104] Step 1802: Perform causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events.

[0105] In this embodiment, the asynchronous data processing system implements fine-grained resource dependency detection when performing causal relationship analysis on the initial log sequence. For example, when analyzing a cross-border payment log sequence, the system discovered that the balance write operation of a target account depends on the balance read operation of a source account. At the same time, it detected in the exchange rate conversion log entry that its input parameters come from the previous on-chain oracle query operation. By establishing read-write dependencies across log entries, the system constructs a causal chain with a clear sequence. When processing digital asset pledge logs, the system recognizes that the pledge rate calculation operation requires reading two resource items: the pledge value and the loan amount. These two resource items are written by the previous asset appraisal operation and loan approval operation, respectively, forming a multi-input dependency.

[0106] Step 1803: Rearrange the event sequence of the initial log sequence according to the topological sorting result of the directed acyclic graph.

[0107] In this embodiment, the asynchronous data processing system implements an event replay verification mechanism when rearranging the initial log sequence based on the topological sorting results of the directed acyclic graph. For example, events in cross-border payment logs, originally sorted by receipt time, are rearranged into a causal sequence of source chain lock → cross-chain proof generation → target chain account verification. For digital asset pledge logs, the parallel execution of pledge rate calculation and risk assessment log events is adjusted to a serial order to meet transaction atomicity requirements. During the reordering process, the system retains the original timestamp information as a secondary sorting key, ensuring maximum temporal authenticity while maintaining causal relationships.

[0108] Step 1804: Insert a checkpoint mark into the rearranged log sequence to generate a segment-verifiable asynchronous processing status log.

[0109] In this embodiment, when inserting checkpoint markers to generate segmented, verifiable logs, the asynchronous data processing system uses a Merkle tree structure to ensure segment integrity. For example, in the rearranged cross-chain remittance log sequence, a checkpoint is inserted every 50 log events. This checkpoint contains a hash digest of the previous 50 events, the root hash of the current global state tree, and a time range proof. Checkpoints for digital asset pledge logs additionally include a version snapshot of the smart contract storage tree. After each checkpoint marker is generated, the system writes its hash value to the blockchain's regulatory contract, achieving an unalterable anchoring effect. When log verification is required, abnormal segments can be quickly located by comparing the continuity of the checkpoint markers and the Merkle proof.

[0110] In a preferred embodiment, the step 1802 of performing causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events includes:

[0111] Step 18021: Parse each log event in the initial log sequence, extract the target resource identifier and operation type of the log event operation, and the operation type includes resource read operation and resource write operation.

[0112] In this embodiment, when parsing log events in the initial log sequence, the asynchronous data processing system uses a semantically enhanced parser to extract operational semantics. For example, the operation type of a cross-chain remittance log event is identified as a "resource write operation," and its target resource identifier contains a triplet of the source chain account address, the cross-chain bridge contract address, and the target chain account address. By parsing the log event's binary payload, the system accurately isolates the modified account balance field, the updated contract storage tree path, and the written cross-chain transaction hash value. For digital asset pledge log events, the system identifies the operation type as a composite operation, encompassing both a "resource write operation" for the collateral storage slot and a "resource read operation" for the loan contract parameters, and extracts the corresponding resource identifier set.

[0113] Step 18022: Generate a resource read set and a resource write set for each log event according to the operation type, wherein the resource read set includes all resource identifiers read by the log event, and the resource write set includes all resource identifiers written by the log event.

[0114] In this embodiment, when generating the resource read set and resource write set of the log event, the asynchronous data processing system implements multi-dimensional correlation analysis. For example, the resource write set of a log event triggered by a smart contract contains the three leaf node addresses of the contract storage tree, corresponding to the total amount of tokens, the liquidity pool ratio, and the fee parameters; its resource read set includes the balance query records of five external account addresses. The system establishes a complete mapping relationship for resource access by reversely tracing the input and output dependencies of the operation instructions. When processing the cross-chain bridge verification log, the system detects that the resource write set contains the cross-chain proof storage area of ​​the bridge contract, while the resource read set involves the source chain block header hash and the target chain light node verification key, forming a resource access pattern unique to cross-chain transactions.

[0115] Step 18023: Traverse all log event pairs. If the resource write set of the first log event and the resource read set of the second log event intersect, or the resource write set of the first log event and the resource write set of the second log event intersect, then create a direct causal edge between the first log event and the second log event.

[0116] In this embodiment, the asynchronous data processing system uses an efficient intersection detection algorithm to create direct causal edges when traversing log event pairs. For example, when analyzing a sequence of log events related to digital asset pledges, if the pledge rate storage slot written by the Nth log event is read by the N+1th log event, the system immediately creates a direct causal edge between the Nth and N+1th events. For cross-chain remittance scenarios, when it is detected that the source chain transaction hash written by a log event is read by a subsequent log event for target chain account verification, the system establishes a cross-chain causal dependency. In particular, when two log events are simultaneously written to the root node of the storage tree of the same smart contract, the system creates a mutually exclusive causal edge and marks it as a write-after-write conflict, triggering the subsequent circular dependency detection mechanism.

[0117] Step 18024: Construct an initial causal graph based on all direct causal edges, where the nodes of the initial causal graph are the log events and the edges are the direct causal edges.

[0118] In this embodiment, when constructing the initial causal graph, the asynchronous data processing system uses an adjacency list storage structure to optimize large-scale data processing. For example, when processing a cross-border payment log sequence containing hundreds of thousands of log events, the system assigns a unique node ID to each log event and uses a compressed sparse row format to store direct causal edge information. The edge weights of the initial causal graph are set to the inverse of the time interval, giving causal events with temporal proximity a higher weight. In the digital asset pledge scenario, the system annotates special edge types in the causal graph, such as the numerical dependency edge from the collateral assessment to the pledge rate calculation, and the formula dependency edge from the interest rate parameter reading to the interest calculation, providing semantic enhancement information for subsequent topological sorting.

[0119] Step 18025: Detect the circular dependency in the initial causal graph, identify the minimum timestamp log event in the circular dependency as the loop starting point, and remove the causal edges generated after the loop starting point and pointing to the loop starting point.

[0120] In this embodiment, the asynchronous data processing system implements a strategy combining depth-first search and timestamp backtracking to detect circular dependencies in the initial causal graph. For example, in a cross-chain atomic swap log, it is discovered that source chain lock log event A and target chain payment log event B point to each other, forming a circular dependency: the lock state written by A is read by B, and the payment state written by B is read by the compensation mechanism of A's transaction. The system traverses all log events in the circular dependency loop, identifies event A with the earliest timestamp as the starting point of the loop, and removes the reverse causal edge from event B pointing to event A, breaking the circular logic. After the removal operation, the system records the detailed information of the deleted edge in the metadata layer for subsequent analysis by the audit module.

[0121] Step 18026: Generate an updated causal graph based on the removed causal edges, and perform topological sorting on the updated causal graph. If the topological sorting is successful, output the updated causal graph as the directed acyclic graph.

[0122] In this embodiment, the asynchronous data processing system uses the Kahn algorithm to efficiently generate the updated causal graph and perform topological sorting. For example, when processing a causal graph for digital asset pledges, the system first identifies an initial node with no dependencies (such as a pledge ownership verification log event), sequentially removes its outgoing edges, and records the topological order. When encountering log events with multiple predecessor nodes (such as an interest calculation log event requiring both the pledge rate and the benchmark interest rate as input), the system dynamically adjusts the processing order based on timestamp gaps to ensure that all predecessor dependencies are met. After a successful topological sort, the system outputs a directed acyclic graph with a strict partial order, where the direction of each edge represents an irreversible causal relationship.

[0123] In a preferred embodiment, the step of inserting a checkpoint marker into the rearranged log sequence in step 1804 to generate a segment-verifiable asynchronous processing state log includes:

[0124] Step 180401: Based on the event order of the rearranged log sequence, determine the target event interval threshold between adjacent checkpoint marks.

[0125] In this embodiment, the asynchronous data processing system uses a dynamic load-aware algorithm to adaptively adjust the checkpoint mark interval threshold based on the order of the rearranged log sequence events. For example, when processing the rearranged log sequence of cross-border payment transactions, the system sets the target event interval threshold to 50 log events during high-load periods and extends it to 200 log events during low-load periods based on the CPU utilization and network throughput indicators of the current node group. For digital asset pledge transaction logs, the system additionally considers the complexity of smart contract execution. When it detects that a log event contains multi-stage state locks, it automatically reduces the interval threshold to 30 events to ensure that key state changes can be accurately anchored. The sliding window statistical mechanism is integrated into the threshold calculation process to analyze the average processing time of the last 100 log events in real time, and dynamically adjust the interval threshold to balance verification efficiency and storage overhead.

[0126] Step 180402: Divide the rearranged log sequence into a plurality of continuous log segments according to the target event interval threshold, wherein each log segment contains a number of events that does not exceed the target event interval threshold.

[0127] In this embodiment, the asynchronous data processing system implements a transaction-boundary-aware segmentation strategy when segmenting rearranged log sequences based on target event interval thresholds. For example, when processing causally ordered logs for cross-chain atomic swaps, the system immediately creates segment boundaries after completing the complete transaction chain of "source chain lock → bridge verification → target chain entry," even if the number of events does not reach the threshold. For digital asset pledge log sequences, the system identifies the logical continuity between pledge rate calculation and interest accrual, ensuring that a single log segment fully encompasses the entire process from collateral lock to interest settlement. A transaction atomicity verification mechanism is employed during the segmentation process. If a log event is detected as belonging to an unfinished multi-chain transaction, the segment boundary is automatically extended to the transaction completion point, preventing cross-segment causal chain breaks.

[0128] Step 180403: Generate corresponding segment verification information for each log segment, where the segment verification information includes the cryptographic hash value of the current log segment and the hash reference of the previous segment verification information.

[0129] In this embodiment, the asynchronous data processing system constructs a chained hash reference structure when generating segment verification information for each log segment. For example, the cryptographic hash value of a cross-border payment log segment is calculated using the SHA3-512 algorithm and contains the serialized byte stream digest of all log events within that segment. The hash reference of the previous segment verification information is implemented through a cascade operation, specifically concatenating the current segment hash value with the previous hash value and performing a secondary hash operation.

[0130] Taking the digital asset staking log as an example, the formula for generating verification information for the Nth segment is: Hash_N=SHA3(Hash_{N-1}||Events_N_Hash). The system also embeds metadata such as the segment timestamp range and the list of participating node signatures into this verification information to enhance the auditability of the segment.

[0131] Step 180404: Insert a checkpoint marker at the boundary between adjacent log segments. The checkpoint marker carries the start event identifier, end event identifier, and corresponding segment verification information of the current log segment.

[0132] In this embodiment, the asynchronous data processing system uses a binary tag encoding specification when inserting checkpoint markers carrying verification information. For example, a checkpoint marker for a cross-chain remittance log segment contains three core fields: the start event identifier is the globally unique transaction ID of the source chain's lock operation; the end event identifier is the block height hash value of the target chain's transaction confirmation; and the segment verification information stores the segment's cryptographic hash and predecessor hash pointer. The tag structure is encapsulated in TLV (Type-Length-Value) format. The type field indicates the log category (e.g., 0x01 for cross-border payment), the length field identifies the number of bytes in each data block, and the value field stores serialized verification data. In digital asset staking scenarios, checkpoint markers additionally include a smart contract version identifier field to ensure that state changes strictly correspond to contract logic.

[0133] Step 180405: Combine all log segments carrying checkpoint markers in order to generate an initial segmented log sequence.

[0134] In this embodiment, when combining log segments carrying checkpoint marks to form an initial segmented log sequence, the asynchronous data processing system implements cross-node consistency verification. For example, when the ten log segments of a cross-border payment transaction are spliced ​​in causal order, the checkpoint mark inserted at the end of each segment forms an overlapping verification area with the head mark of the next segment. The system records the physical storage location of each segment through a distributed hash table, stores hot data containing frequently accessed segments in the A region node, and stores historical cold data in the B region node. During the combination process, memory-mapped file technology is used to map logically continuous log segments into continuous blocks of physical storage, optimizing subsequent reading efficiency. For digital asset pledge logs, the system embeds a segment metadata index table in the initial sequence, supporting the rapid location of related log segments through the pledge contract address.

[0135] Step 180406: Extract the segment verification information of each checkpoint mark from the initial segment log sequence, and generate a global verification chain, which contains a hash value sequence of all segment verification information linked in chronological order.

[0136] In this embodiment, when extracting checkpoint marker information to generate a global verification chain, the asynchronous data processing system constructs a multi-level hash authentication structure. For example, segmented verification information extracted from a cross-border payment log sequence is arranged in chronological order and aggregated through a Merkle tree to form a compact verification chain. Each tree node stores the concatenated hash value of the hashes of its two child nodes, while leaf nodes contain the original hash of each segment's verification information. The global verification chain for digital asset pledge logs employs a modified star-shaped structure, with the central node storing the latest segment's verification information, and historical segments forming radial links via hash pointers. The system adds a digital signature ring to the verification chain, requiring more than two-thirds of the consensus nodes to jointly sign the verification chain's root hash to prevent the risk of single-point tampering.

[0137] Step 180407: associate and store the global verification chain with the initial segmented log sequence to generate an asynchronous processing status log containing the segmented verification chain.

[0138] In this embodiment, when the global verification chain is associated with the initial segmented log sequence for storage, the asynchronous data processing system implements a cross-reference index mechanism. For example, each segment of the cross-border payment log records the position offset of the corresponding verification chain node when it is stored, and the verification chain node saves the physical address pointer of the relevant segment. The system uses a B+ tree structure to maintain the mapping relationship between the segment ID and the verification chain node, supporting bidirectional queries with O(logn) complexity. For digital asset pledge logs, the associated storage process introduces versioned snapshot technology, generates an incremental snapshot each time the verification chain is updated, and establishes a time sequence correspondence with the checkpoint mark of the log segment. The storage layer implements an erasure code sharding strategy, encoding the verification chain data into multiple data blocks and distributing them in edge nodes to ensure that they can still be fully restored when some nodes fail.

[0139] Step 180408: According to the global verification chain in the asynchronous processing status log, recursive hash verification is performed on the segment verification information of each log segment. If all recursive hash verifications pass, the asynchronous processing status log is marked as a complete and verifiable state.

[0140] In this embodiment, when performing recursive hash verification on the asynchronous processing status log, the asynchronous data processing system adopts a reverse chain verification algorithm. For example, when verifying the integrity of the cross-border payment log, starting from the checkpoint mark of the latest segment, it verifies step by step whether Hash_N is equal to SHA3(Hash_{N-1}||Events_N_Hash). Each time a level of verification is passed, the system marks the segment as a trusted state in the verification chain until it is traced back to the initial hash value of the genesis segment. For digital asset pledge logs, the version continuity of the smart contract storage tree is synchronously checked during the recursive verification process to ensure that the pledge status changes of each segment comply with the version evolution rules. The system implements parallel verification optimization, splits the verification task into multiple subtasks and distributes them to different computing nodes, and uses the MapReduce framework to aggregate the verification results.

[0141] Step 180409: When a new log event is detected, locate the target log segment to which the new event belongs, update the segment verification information and associated checkpoint mark of the target log segment, and synchronously update the hash value sequence of the global verification chain.

[0142] In this embodiment, when processing new log events and updating target segments, the asynchronous data processing system implements an incremental update strategy to minimize the scope of impact. For example, when a new cross-chain remittance compensation transaction occurs, the system locates the cross-border payment log segment to which it belongs and marks that segment as editable. The update process includes: recalculating the hash chain of all events within that segment to generate new segment verification information; adjusting the hash reference relationships of all subsequent segments; and re-submitting distributed consensus verification to the affected segments. For new interest settlement events in the digital asset staking log, the system uses COW (Copy-on-Write) technology to create a replica of the segment for modification. Once verified, the old version is atomically replaced to ensure uninterrupted online service.

[0143] Step 180410: Recalculate the integrity identifier of the asynchronous processing status log according to the updated global verification chain. If the integrity identifier is consistent with the current storage state, confirm the verification consistency of the asynchronous processing status log.

[0144] In this embodiment, the asynchronous data processing system implements a multi-factor fusion algorithm when recalculating the integrity identifier of the asynchronous processing status log. For example, the global integrity identifier consists of three parts: the verification chain root hash, the latest segment timestamp hash, and the node signature set hash. A threshold signature mechanism is used to generate the composite hash value. When a cross-border payment log's integrity identifier is detected to be inconsistent with the stored state, the system triggers an automatic repair process: obtaining a copy of the verification chain from a majority of nodes, determining the correct version using a Byzantine fault-tolerant algorithm, reconstructing the checkpoint markers for the affected segments, and finally generating a new integrity identifier and broadcasting it to the entire network. For digital asset pledge logs, the integrity verification process additionally verifies the mathematical consistency of the pledge lock status and interest calculation, ensuring that the integrity of the business logic is not affected by changes to the storage structure.

[0145] As an optional but non-limiting embodiment, the step 122 of generating dependency constraints for state transition instructions based on the event dependency graph includes: parsing a node set and an edge set in the event dependency graph, wherein the node set represents independent transaction events in a transaction request set, and the edge set represents the execution order dependency between the independent transaction events; traversing each directed edge in the edge set, extracting edge attribute information of the directed edge, wherein the edge attribute information includes a timestamp interval, a resource lock identifier, and a transaction isolation level; identifying a sequence dependency type between the independent transaction events based on a timestamp interval overlap state in the edge attribute information, wherein the sequence dependency type includes a strong sequence dependency, a weak sequence dependency, and a parallel dependency; generating an initial sequence dependency based on the sequence dependency type. An initial dependency constraint set, wherein strong order dependency generates a mutual exclusion lock constraint, weak order dependency generates a shared lock constraint, and parallel dependency generates a lock-free asynchronous execution identifier; detecting a circular dependency chain in the initial dependency constraint set, traversing each node in the circular dependency chain, dynamically adjusting the lock allocation order according to the holding priority of the resource lock identifier, and generating a modified constraint set that eliminates the circular dependency; merging redundant constraints for the same resource lock identifier in the modified constraint set, retaining the constraints of the highest transaction isolation level, and generating a simplified dependency constraint set; verifying the topological consistency of the simplified dependency constraint set with the event dependency graph, and if there is an uncovered dependency edge, supplementing the timestamp interval forced alignment constraint to generate a final dependency constraint. The timestamp interval forced alignment constraint is generated in the following manner: calculating the timestamp difference between the starting transaction event and the ending transaction event corresponding to the uncovered dependency edge, and if the difference exceeds a preset threshold, inserting a timestamp synchronization instruction to limit the execution of the starting transaction event within the timestamp window of the ending transaction event.

[0146] In implementation, the event dependency graph is first parsed, mapping nodes to independent transactions (such as staking operations and cross-chain verification), with edges representing execution order dependencies. Each directed edge is traversed to extract the timestamp interval, resource lock identifier (such as account exclusive lock L1, contract shared lock L2), and isolation level (such as repeatable read). Three types of dependencies are categorized based on timestamp overlap: strong ordering dependencies (transaction B must execute after transaction A completes, e.g., collateral lock precedes interest calculation) generate mutual exclusion lock constraints; weak ordering dependencies (transaction B reads data written by A, e.g., exchange rate query depends on the source chain balance) generate shared locks; and parallel dependencies without timestamp overlap (such as cross-chain transfers and local liquidations) are marked as lock-free asynchronous execution. Circular dependency chains within the initial constraints are then detected (e.g., transaction A waits for B to release a lock, which in turn waits for A to release another lock). The order is dynamically adjusted based on resource lock priorities, assigning the highest priority to core system resources (such as the fee account) and forcing lower-priority transactions to relinquish lock resources. For example, if a cycle between the staking contract lock and the liquidation lock is detected, the staking lock is prioritized to break the cycle. When merging redundant constraints, the highest isolation level is retained for the same resource. For example, if a cross-chain channel lock has both read and write lock constraints, only the exclusive write lock constraint is retained. Finally, the constraints are verified to be consistent with the topological structure, and timestamp alignment is enabled for uncovered edges (such as implicit timing dependencies between asynchronous transactions): If the difference between two transaction timestamps exceeds a threshold (such as 500ms), a synchronization instruction is inserted to restrict the subsequent transaction to execute within the preceding time window. For example, if the time difference between a pledge operation and a risk assessment reaches 800ms, the risk assessment is forced to be triggered within a 100ms time window after the pledge is completed. This mechanism improves the throughput efficiency of the distributed network while ensuring transaction atomicity through dynamic lock allocation and timing coordination.

[0147] As an optional but non-limiting embodiment, a flow control strategy is set in the asynchronous pipeline to dynamically adjust the processing order of the sub-state machine instances, including: real-time collection of resource consumption indicators of each sub-state machine instance in the asynchronous pipeline, the resource consumption indicators including thread pool occupancy, memory buffer usage and network throughput; inputting the resource consumption indicators into the proportional-integral-differential controller to calculate the dynamic adjustment coefficient of the current pipeline load; generating a thread scheduling weight table based on the dynamic adjustment coefficient, the thread scheduling weight table including the priority score of each sub-state machine instance and the corresponding number of thread allocations; reordering the processing queues in the asynchronous pipeline according to the thread scheduling weight table, and adjusting the sub-state machine instances with high priority scores to the front of the queue; deploying a delay monitor at the entrance of the asynchronous pipeline to count the queue waiting time and processing time of each sub-state machine instance in real time; when it is detected that the sum of the queue waiting time and processing time of the target sub-state machine instance exceeds the preset delay threshold , triggering the instance migration mechanism; screening candidate nodes whose current load rate is lower than the average load level from the distributed node cluster, and generating a node migration candidate list; encapsulating the context state and the data packet to be processed of the target sub-state machine instance into a migration container, and attaching an integrity check code; routing the migration container to the target node with the lowest load rate according to the load sorting result of the node migration candidate list; after verifying the validity of the integrity check code on the target node, loading the migration container and resuming the execution of the target sub-state machine instance; updating the processing queue state of the asynchronous pipeline, removing the migrated target sub-state machine instance, and releasing the local resources occupied by it; asynchronously calling back the processing result returned by the target node to the output interface of the asynchronous pipeline, and merging it with the result of the non-migrated sub-state machine instance; periodically polling the health status of all migrated sub-state machine instances. If an abnormal termination instance is found, the state is rolled back according to the most recent checkpoint mark and rejoined to the processing queue.

[0148] For example, when screening candidate nodes, nodes A1 and A2, whose CPU utilization is currently below 40%, are selected from the node cluster in region A and added to the migration candidate list. The system encapsulates the cross-border payment instance's context state (including bridge verification progress and cross-chain proof cache) and pending data packets (unconfirmed target chain block headers) into an encrypted migration container, appending a Merkle tree-based integrity check. Based on the inter-node network quality score, node A2, with the lowest latency, is selected as the migration target. When resuming instance execution, upon receiving the migration container, node A2 first verifies the consistency of the checksum with the original hash tree, then loads the context snapshot of the bridge verification instance and resumes cross-chain proof verification from the point of interruption. The original node releases the 8GB of video memory resources and updates the pipeline queue status. The processing results are returned to the master node via an asynchronous callback interface and merged with the locally completed transaction verification results in timestamp-ordered order. The system maintains a global transaction ID mapping table to ensure the correct aggregation of migration instance results. During health status polling, the process status, resource consumption, and progress indicators of the cross-border payment instance migrated to node A2 are monitored every 5 seconds. If an instance is found to have terminated abnormally due to a target chain node failure, it will be rolled back to the verified cross-chain proof state based on the checkpoint marker written 10 seconds ago and rejoined the processing queue of the A1 node. The system maintains a versioned state snapshot chain for each migration instance, supporting on-demand rollback to any valid checkpoint.

[0149] See Figure 2 As shown, it is a structural diagram of a possible asynchronous data processing system provided in an embodiment of the present application. Figure 2 In the embodiment, the asynchronous data processing system 200 includes: a processor 210 and a memory 220. The memory 220 stores a computer program that can be executed by the processor 210. The processor 210 can execute the steps of the above-mentioned distributed ledger asynchronous data processing method based on the MEMO state machine by executing the instructions stored in the memory 220. Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program runs on the asynchronous data processing system, the computer program is used to enable the asynchronous data processing system to execute the steps of the above-mentioned distributed ledger asynchronous data processing method based on the MEMO state machine.

Claims

1. A distributed ledger asynchronous data processing method based on MEMO state machine, characterized in that: include: Obtaining a transaction request set in a distributed ledger network and extracting an asynchronous processing trigger event of the transaction request set, wherein the transaction request set includes K transaction data blocks, where K is a positive integer; Parsing the asynchronous processing trigger event to generate a state transition instruction sequence, wherein the state transition instruction sequence includes M state transition paths associated with the K transaction data blocks, where M is a positive integer not greater than K; The parallel prediction module based on the MEMO state machine performs asynchronous processing on the M state transition paths to generate N predicted state vectors and corresponding conflict detection flags: Calling the state transition probability model of the MEMO state machine to segment each of the M state transition paths to obtain L path segmentation units; Using an asynchronous thread pool to process the L path segmentation units in parallel to generate a state transition prediction value for each path segmentation unit; Performing time series aggregation on the state transition prediction values ​​of the path segment units belonging to the same state transition path to generate an initial prediction state vector of the state transition path; Conflict features are extracted from the initial predicted state vector to obtain a conflict type identifier and a conflict weight in the conflict detection mark: dimensional distribution features of the initial predicted state vector are extracted, and the dimensional offset between the dimensional distribution features and the historical state vector is calculated; the dimensional offset is input into a pre-trained conflict classification model, and the conflict type identifier is output; the corresponding weight calculation rule is called according to the conflict type identifier to generate a conflict weight that is positively correlated with the resource occupancy rate of the current transaction data block; wherein, the conflict classification model is trained in the following manner: state vector samples of historical conflict events are collected, conflict type labels are annotated on the state vector samples, local gradient features of the state vector samples are extracted using a multi-layer convolutional network, and a classification loss function is optimized through back propagation; Dynamically modifying the initial predicted state vector based on the conflict weight to generate a target predicted state vector and marking the target predicted state vector as an element of the N predicted state vectors, where N is a positive integer not greater than M; Perform feature fusion on the N predicted state vectors according to the conflict detection mark to generate a global state update matrix; The global state update matrix is ​​written into the consensus node set of the distributed ledger network, and an asynchronous processing state log matching the transaction request set is generated.

2. The method according to claim 1, wherein Writing the global state update matrix into the consensus node set of the distributed ledger network includes: Divide the global state update matrix into P data slices according to the write priority of the asynchronous processing state log; Assign a target node group in the consensus node set to each data shard and generate a data shard hash identifier with a timestamp; Broadcasting the data shard and the hash identifier of the data shard to the target node group, and receiving a verification pass signal returned by the target node group; When more than a preset ratio of verification pass signals are received, the data shards are written to the persistent storage chain of the target node group; The write priority is determined by counting the historical processing delays of the transaction data blocks associated with each data shard in the global state update matrix, and generating a priority score that is negatively correlated with the historical processing delay.

3. The method according to claim 1, wherein The step of parsing the asynchronous processing trigger event and generating a state transition instruction sequence includes: Extracting an event type code and an event dependency graph from the asynchronous processing trigger event; Generate dependency constraints for state transition instructions according to the event dependency graph; Calling an instruction generation model to decode the event type code and generate a candidate instruction set carrying dependency constraints; Performing instruction conflict detection on the candidate instruction set, filtering out invalid instructions with circular dependencies or resource contention conflicts, and obtaining a target instruction set; The target instruction set is sorted according to dependency constraints to generate the state transition instruction sequence.

4. The method according to claim 3, wherein The call instruction generation model decodes the event type code to generate a candidate instruction set carrying dependency constraints, including: Input the event type code into the encoder of the sequence generation sub-model of the instruction generation model, and output an event semantic feature vector; An attention mechanism is used to match the event semantic feature vector with the historical instruction template library to generate an attention weight distribution; Filtering Top-R candidate templates from the historical instruction template library according to the attention weight distribution; Logically combining the candidate template and the dependency constraint condition to generate the candidate instruction set; The instruction generation model is trained by using a masked sequence-to-sequence architecture to perform autoregressive prediction on historical event type encoding and corresponding target instructions, and optimizing the conflict avoidance reward value of the target instructions through reinforcement learning.

5. The method according to claim 1, wherein The method further comprises: When detecting that there is a pending state in the global state update matrix, triggering a sub-state machine splitting mechanism of the MEMO state machine; Extracting Q sub-transaction features from the transaction data block associated with the pending state and generating Q independent sub-state machine instances; wherein the sub-transaction features are extracted by generating a feature vector that matches the sub-state machine splitting condition based on the operation type, resource access mode, and transaction atomicity identifier of the transaction data block; An asynchronous pipeline is used to process Q sub-state machine instances in parallel. An independent resource isolation domain and processing thread are allocated to each sub-state machine instance. A flow control policy is set in the asynchronous pipeline to dynamically adjust the processing order of the sub-state machine instances. When the processing delay of a target sub-state machine instance exceeds a threshold, an instance migration mechanism is triggered to migrate the target sub-state machine instance to a low-load node, generating a sub-state machine processing result queue. The flow control strategy is implemented by: collecting resource consumption indicators of each sub-state machine instance in the pipeline in real time, and adjusting thread scheduling weights using a PID controller so that the resource consumption indicators are within a preset safety range; The completion status of the sub-state machine processing result queue is monitored, and when all sub-state machine instances are completed, the processing results are merged and the global state update matrix is ​​updated.

6. The method according to claim 1, wherein The method further comprises: When the generation cycle of the asynchronous processing status log reaches a preset threshold, a log compression optimization mechanism is triggered; Extracting frequent state transition patterns from the asynchronous processing state log and generating a state transition pattern index tree; Merging and encoding consecutive repeated state transition events in the asynchronous processing state log to generate a compressed log block; Associating and storing the compressed log block with the state transition pattern index tree, and deleting redundant entries in the asynchronous processing state log; The frequent state transition pattern is identified by using a sliding window to count the occurrence frequency of state transition events in the asynchronous processing state log, and classifying state transition patterns with a frequency higher than a set frequency as frequent patterns through a clustering algorithm.

7. The method according to claim 1, wherein The generating of the asynchronous processing status log matching the transaction request set includes: Extracting a state change record set from the global state update matrix and generating an initial log sequence in chronological order; Perform causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events: parse each log event in the initial log sequence, extract the target resource identifier and operation type of the log event operation, the operation type includes resource read operation and resource write operation; generate a resource read set and a resource write set for each log event according to the operation type, the resource read set includes all resource identifiers read by the log event, and the resource write set includes all resource identifiers written by the log event; traverse all log event pairs, if the resource write set of the first log event and the resource read set of the second log event have an intersection, or the resource write set of the first log event has an intersection, If there is an intersection between the resource write set and the resource write set of the second log event, a direct causal edge is created between the first log event and the second log event; an initial causal graph is constructed based on all direct causal edges, wherein the nodes of the initial causal graph are the log events and the edges are the direct causal edges; a circular dependency in the initial causal graph is detected, the minimum timestamp log event in the circular dependency is identified as the starting point of the loop, and the causal edges generated after the starting point of the loop and pointing to the starting point of the loop are removed; an updated causal graph is generated based on the removed causal edges, and a topological sort is performed on the updated causal graph. If the topological sort is successful, the updated causal graph is output as the directed acyclic graph; Rearranging the event sequence of the initial log sequence according to the topological sorting result of the directed acyclic graph; Insert checkpoint marks into the rearranged log sequence to generate a segmented verifiable asynchronous processing state log: determine the target event interval threshold between adjacent checkpoint marks based on the event sequence of the rearranged log sequence; divide the rearranged log sequence into multiple continuous log segments according to the target event interval threshold, and each log segment contains a number of events that does not exceed the target event interval threshold; generate corresponding segment verification information for each log segment, and the segment verification information contains the cryptographic hash value of the current log segment and the hash reference of the previous segment verification information; insert a checkpoint mark at the intersection of adjacent log segments, and the checkpoint mark carries the start event identifier, end event identifier and corresponding segment verification information of the current log segment; combine all log segments carrying checkpoint marks in sequence to generate an initial segmented log sequence; extract each checkpoint mark from the initial segmented log sequence The segmented verification information recorded is used to generate a global verification chain, which includes a hash value sequence of all segmented verification information linked in chronological order; the global verification chain is associated with the initial segmented log sequence and stored to generate an asynchronous processing status log including the segmented verification chain; according to the global verification chain in the asynchronous processing status log, the segmented verification information of each log segment is recursively hashed and verified, and if all recursive hash verifications pass, the asynchronous processing status log is marked as a complete and verifiable state; when a new log event is detected, the target log segment to which the new event belongs is located, the segmented verification information and the associated checkpoint mark of the target log segment are updated, and the hash value sequence of the global verification chain is synchronously updated; the integrity identifier of the asynchronous processing status log is recalculated according to the updated global verification chain, and if the integrity identifier is consistent with the current storage state, the verification consistency of the asynchronous processing status log is confirmed.

8. An asynchronous data processing system, characterized in that: The method comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor is enabled to perform the steps of any one of the methods of claims 1 to 7.

Images