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

Abstract

The invention relates to the technical field of computer communication, provides a distributed accounting asynchronous data processing method and system based on an MEMO state machine, and is used for improving the intelligent adaptability of a distributed accounting network to a dynamic service scene. The method comprises the following steps: acquiring a transaction request set in a distributed accounting network, extracting an asynchronous processing trigger event of the transaction request set, analyzing the asynchronous processing trigger event, generating a state transition instruction sequence containing M state transition paths associated with K transaction data blocks, a parallel prediction module based on an MEMO state machine performs asynchronous processing on the M state transition paths to generate N prediction state vectors and corresponding conflict detection marks; performing feature fusion on the N prediction state vectors according to the conflict detection mark to generate a global state updating matrix; and writing the global state updating matrix into a consensus node set of the distributed accounting network, and generating an asynchronous processing state log matched with 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 account 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] Although the current parallel processing framework has introduced a multi-threading mechanism, it still needs to rely on atomicity guarantees under strong synchronization constraints. For example, the batch processing solution based on optimistic locking triggers a full rollback when a state conflict is detected, causing resource utilization to fluctuate significantly as the conflict rate increases. In addition, traditional state machine replication technology is limited by deterministic instruction execution logic and lacks the ability to concurrently deduce potential state migration paths, resulting in rigid resource allocation problems when processing heterogeneous transactions.

[0004] Existing asynchronous processing mechanisms mostly focus on optimizing the load distribution of task queues, but fail to deeply deconstruct the inherent state transition semantics of transactions. Although the typical event-driven architecture decouples the transaction reception and execution stages, its triggering conditions still use fixed thresholds or periodic polling mechanisms, which cannot dynamically adapt to the fluctuation characteristics of network load.

[0005] At the conflict resolution level, mainstream technologies rely on post-verification mechanisms, such as identifying state divergences through version comparison during the ledger submission phase. This lagging processing mode significantly increases the risk of system uncertainty. In addition, traditional global state synchronization uses a multi-layer relay topology, and the complexity of inter-node communication surges with the expansion of the network scale. The transaction log only records the original data sequence and lacks multi-dimensional feature extraction of the state evolution process, resulting in the need to reconstruct the complete execution link during the audit, and low operation and maintenance efficiency. The above defects jointly restrict the application capabilities of distributed ledger networks in high-concurrency and strong real-time scenarios. Therefore, how to improve the intelligent adaptability of distributed ledger networks for dynamic business scenarios is a technical problem that needs to be solved at present. 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 a 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 a 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 executes 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 is run 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 account 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 an independently analyzable state migration path, 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 the 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 realizes the verifiability of the whole life cycle by generating an asynchronous processing state log. On the basis of ensuring the strong consistency of the account book, 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 account 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, and 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, a smart contract execution engine, or a cross-chain bridge module through a transaction entry node cluster of a distributed ledger network. Each transaction request is encapsulated as a transaction data block with an independent blockchain address identifier, and each transaction data block follows the transaction encoding specification defined by the distributed ledger network, including a transaction version number, input and output script hashes, multi-signature verification rules, and nested metadata payloads. For example, the asynchronous data processing system uses a hierarchical verification mechanism to process a set of transaction requests: 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 legal transactions according to a preset rule engine, such as marking operations involving high-concurrency accounts as high-priority transactions and marking batch clearing transactions as asynchronous processing candidate sets.

[0016] In the above process, the generation of asynchronous processing trigger events depends on the real-time monitoring probe of the distributed ledger network, which continuously collects indicators such as network throughput, node computing load, and memory pool queue depth. When it is detected that the processing delay of a single node exceeds the threshold or the number of backlog transactions in the memory pool exceeds the critical value, the asynchronous data processing system will automatically trigger the batch processing mode, and package the K transaction data blocks accumulated in the current memory pool as an asynchronous processing unit, and generate a trigger event tuple containing a time window identifier and a load balancing strategy. For another example, when a regional node of the distributed ledger network detects that there are more than a few hundred cross-regional remittance transactions in its memory pool, the asynchronous data processing system will start the cross-regional sharding processing mechanism, divide these transactions into multiple subsets according to the time zone of the target account, and attach a geographic routing label to each subset to optimize the subsequent processing path.

[0017] Step 120: Parse 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.

[0018] In this embodiment, the asynchronous data processing system can call a distributed state parser to perform deep semantic analysis on the trigger event. The parser is built based on an improved finite state transition model and can map the operational semantics of the transaction data block to the state migration path of the MEMO state machine. Each state migration path consists of a quaternary group of initial state node, migration condition predicate, target state node and migration constraint function, where the migration constraint function verifies the path feasibility by accessing the global state snapshot of the distributed ledger network.

[0019] For example, for a transaction data block involving digital asset pledge, the state parser will generate a migration path containing "operable state → pledge locked state" and embed the dynamic calculation rules of the pledge rate in the migration constraint function to ensure that the target state transition meets the requirements of the on-chain governance protocol. The asynchronous data processing system uses a dependency analysis algorithm based on event tracing to perform causal association 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 the matrix indicates whether there is a read-write conflict between two state migration paths for a shared account.

[0020] In the above process, the asynchronous data processing system introduces a priority weighting mechanism, which gives a higher execution weight to the state migration path involving key accounts of the system (such as the fee collection account), ensuring that it passes the verification process of the MEMO state machine first. For example, when it is detected that a transaction data block needs to update the benchmark interest rate parameters of the distributed ledger network, the asynchronous data processing system will automatically increase the priority of the path so that it can obtain a pre-processing position in 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 tags, where N is a positive integer not greater than M.

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

[0023] In the above process, the asynchronous data processing system uses improved snapshot isolation technology to create an independent versioned state view for each simulation thread to prevent state pollution between different prediction tasks. The conflict detector identifies cross-transaction data competition scenarios by comparing the intermediate states of multiple simulation threads in real time. For example, when it detects that two state migration paths attempt to modify the balance field of the same account at the same time, it will generate a conflict detection tag containing the conflicting account address and the type of competing operation. The vector generator encodes the final simulation results into a predicted state vector. Each vector not only contains basic state information such as account balance and contract storage tree root hash, but also embeds operation validity proof and state version watermark. For example, when processing the state migration path involving the token exchange protocol, the prediction engine will generate a composite vector containing the change in liquidity pool reserve, slippage verification results, and transaction price impact factors, providing a fine-grained decision-making basis for subsequent feature fusion. The asynchronous data processing system achieves elastic scaling of prediction tasks through dynamic thread pool management technology. When it is detected that a certain type of state migration path requires complex calculations (such as zero-knowledge proof verification), it automatically allocates dedicated computing units for accelerated processing.

[0024] Step 160: Perform feature fusion on the N predicted state vectors according to the conflict detection mark 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, which projects N predicted state vectors into a high-dimensional feature space for conflict resolution. In detail, the conflict detection tags are first hierarchically classified through a topological sorting algorithm, and the vectors involving the modification of the same account state are merged into conflict groups. A partial order relationship is established in each conflict group according to the transaction timestamp and block height. For conflict groups with write-after-read dependencies, the system adopts an optimistic concurrency control strategy to determine whether a state rollback is required by comparing the overlap of the operation time windows. For example, when two predicted state vectors perform +100 and -50 operations 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] In addition, the construction of the global state update matrix adopts a hierarchical accumulation mechanism: the base layer stores the absolute state value of the account (such as the balance amount), the incremental layer records the relative state changes (such as interest accumulation), and the metadata layer saves the smart contract execution context associated with the transaction. Each cell of the matrix is ​​attached with a version lock mechanism to ensure that dirty write problems are avoided during the consensus verification phase. The asynchronous data processing system introduces fuzzy hash verification technology at this stage to verify the state correlation across accounts in the matrix, such as checking whether the deduction by the initiator of the transfer transaction and the crediting by the recipient satisfy the law of numerical conservation, thereby intercepting the risk of account imbalance caused by prediction errors in advance.

[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 matching 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 through the atomic broadcast protocol. Among them, each consensus node runs the improved practical Byzantine fault-tolerant algorithm to perform multiple rounds of cross-validation on the matrix data: the first round of verification checks whether the digital signature chain of the matrix is ​​complete, the second round of verification verifies the correctness of the state change by re-executing the key transaction path, and the third round of verification performs an arithmetic consistency check on the final state of the account after the conflict is resolved. It can be understood that the matrix data that passes the consensus is encoded as a new block of the blockchain, and the block header is specially embedded with the periodic check code of the MEMO state machine, which is generated by the hash summary of all predicted state vectors through the Merkle tree structure aggregation.

[0029] Among them, 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 track 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 edge nodes through distributed hash tables. For example, the asynchronous data processing system performs log rolling operations every morning, compresses the MEMO flow records 48 hours ago in columns, and stores them in geographically distributed archive nodes according to account address shards, while only retaining the index pointer of the latest flow 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 evolution of system performance.

[0030] Based on the above, in the exemplary application scenario of the cross-border payment platform supported by the distributed ledger network, when a regional node encounters sudden high-concurrency transactions, the asynchronous processing mechanism demonstrates a strong capacity. A large number of users initiate cross-regional remittances, digital asset pledges and other requests through external payment gateways and pour into the asynchronous data processing system, forming a pending collection of thousands of standardized transaction data blocks. These data blocks are uniquely identified by blockchain addresses and strictly follow the coding rules including transaction versions, multi-signature verification and metadata nesting. For example, a cross-time zone transfer contains both capital flow path parameters and embedded dynamic business indicators such as exchange rate fluctuation tolerance thresholds. The asynchronous data processing system quickly removes transactions with invalid signatures or abnormal formats through an automated filtering layer. At the same time, based on preset rules, operations involving core accounts of the system are marked as high-priority transactions, and scenarios such as cross-time zone settlements are classified as asynchronous processing candidate sets. 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, facing a heterogeneous set of transactions, the asynchronous data processing system converts each transaction into a migration path that can be identified by the state machine through a semantic parsing engine. For example, when processing a digital asset pledge request, the asynchronous data processing system dynamically verifies the proportional relationship between the value of the pledge and the loan amount, obtains real-time price data through the on-chain oracle to evaluate the migration conditions, and generates a target instruction containing the smart contract state lock. In this process, the asynchronous data processing system accurately identifies that there is data competition in multiple transactions that concurrently modify the core accounts of the system, and at the same time finds that the effectiveness of remittances in a certain time zone depends on the periodic batch processing results of a specific node. By constructing a state dependency topology across transactions, the asynchronous data processing system dynamically assigns execution priorities to paths involving the core logic of the account, ensuring that key state changes are verified first. The above-mentioned mechanism combining timestamp sequence analysis and dynamic weight adjustment not only maintains the atomicity requirements of the account, but also provides flexible processing space for the timing coordination of cross-regional transactions.

[0032] In the parallel prediction phase, the asynchronous data processing system creates an isolated sandbox environment for each transaction to simulate state migration. For example, when processing a pledge contract, the asynchronous data processing system clones the storage state on the chain and deduces the precise relationship between asset lock and interest calculation, and simultaneously detects that another operation that modifies the liquidation parameters has a smart contract storage conflict. For cross-regional remittance scenarios, the asynchronous data processing system simulates the settlement verification process in different time zones respectively, and finds that a certain target area has caused compliance verification exceptions due to reaching the regulatory limit. Through versioned snapshot isolation technology, the asynchronous data processing system establishes an independent view for transactions that concurrently modify the state of the same account. For example, when processing concurrent operations on the income and expenditure of an account, a state copy with a timestamp watermark is generated to ensure data isolation in the pre-execution process. The above high-precision simulation not only outputs a prediction vector containing proof of operation validity, but also accurately locates account-level data competition and contract-level logic conflicts through a tagging system. In the feature fusion stage, a multi-dimensional conflict resolution strategy can be used to ensure account integrity. The asynchronous data processing system uses high-dimensional space projection technology to perform correlation analysis on prediction vectors. For example, it performs numerical merging on concurrent income and expenditure operations of an account, converting discrete transactions into net balance changes; automatically delaying transactions that reach the regulatory ceiling to the next processing cycle; and coordinating the update order of smart contract states 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 state value of the account, the incremental layer captures continuous changes such as interest calculation, and the metadata layer saves the transaction context relationship chain. Fuzzy hash verification technology is used to verify cross-account value conservation, such as checking whether the total expenditure of a batch of remittance transactions and the total account plus handling fees are precisely balanced, and intercepting account cracks caused by simulation errors in advance. The above-mentioned processing method that integrates mathematical induction and strategy scheduling significantly improves the throughput efficiency in high-concurrency scenarios while maintaining the strong consistency of distributed ledgers.

[0033] After multiple rounds of consensus verification, the state matrix eventually forms an unalterable account record, which is synchronized to the global node network through the atomic broadcast protocol. Specific regional nodes verify the integrity of the data signature chain, and some nodes ensure zero error in the calculation process through sampling re-execution. All nodes cooperate to verify the Merkle root consistency of the account data. The asynchronous processing log generated by the asynchronous data processing system implements a hierarchical storage strategy. Recent data is retained in a hot storage layer that can be quickly retrieved, and historical records are stored in distributed edge nodes after being compressed according to regional characteristics. Through the machine learning module to analyze the conflict pattern in the log, the asynchronous data processing system autonomously optimizes the processing strategy: dynamically expand the prediction resources during the peak trading period, and divert the complex cryptographic verification tasks to heterogeneous computing units. The above-mentioned closed-loop optimization system enables the platform to show significant advantages in handling burst traffic, not only achieving a significant increase in the error interception rate, but also shortening the average processing time of cross-regional remittances to seconds. Therefore, the technical robustness and stability of the above-mentioned asynchronous processing framework provided in the embodiment of the present application in dealing with high concurrency, multiple time zones, and heterogeneous transaction scenarios can be effectively guaranteed.

[0034] In an optional embodiment, the MEMO state machine-based parallel prediction module in step 140 performs asynchronous processing on the M state transition paths to generate N predicted state vectors and corresponding conflict detection marks, including: 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.

[0035] In this embodiment, when the state transition probability model of the MEMO state machine is called to perform path segmentation on each state transition path in the M state transition paths, the asynchronous data processing system identifies the nonlinear operation nodes within the path by analyzing the conditional predicates and migration constraint functions preset in the state transition path. For example, when processing the state transition path involving digital asset pledge transactions, the state transition probability model detects that the path contains two operation nodes, the pledge locking stage and the interest calculation stage. According to the segmentation threshold in the dynamic calculation rule of the pledge rate, the original path is segmented into two path segmentation units, the pledge locking unit and the interest calculation unit. Each path segmentation unit is composed of an independent initial state node, a migration condition predicate, a target state node, and a migration constraint function, and the segmentation process needs to ensure that the state dependency between each unit is verified through a global state snapshot. Specifically, the migration constraint function of the pledge locking unit verifies whether the amount of the pledge reaches the minimum limit specified by the smart contract, while the interest calculation unit generates the interest accumulation value according to the lock duration and the benchmark interest rate parameter.

[0036] 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.

[0037] 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 according to the computational complexity of the path segmentation unit. 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, which calls the global account state tree of the distributed account 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, which obtains real-time exchange rate data through the on-chain oracle and performs multi-currency conversion calculations. The state transfer prediction value generated by each thread includes an operation result code, a state change summary, and a resource consumption indicator, wherein 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 ensures that the intermediate states of different segmentation units do not interfere with each other through a thread isolation mechanism.

[0038] Step 143: Time-series aggregation is performed 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.

[0039] In this embodiment, when the state transfer prediction values ​​of the path segmentation units belonging to the same state migration path are aggregated in time series, the asynchronous data processing system establishes a timestamp dependency chain according to the execution order of each segmentation unit. For example, when processing the state migration path of the smart contract triggering transaction, the prediction value of the contract initialization unit includes the storage space allocation result, the prediction value of the contract parameter loading unit includes the input parameter parsing state, and the prediction value of the contract execution unit includes the function call return value. The system (asynchronous data processing system) hierarchically superimposes the prediction values ​​of the three segmentation units according to the timestamp sequence, and fuses the storage space address, parameter check mark and execution result through the weighted average algorithm to generate an initial prediction state vector including the contract storage tree root hash, execution context pointer and total gas consumption. In this process, the asynchronous data processing system uses version merging technology to resolve state version conflicts across segmentation units. For example, when the parameter loading unit and the execution unit perform write operations on the same storage slot, the system retains the final valid write value according to the overlap of the operation time window.

[0040] Step 144: extract conflict features from the initial prediction state vector to obtain the conflict type identifier and conflict weight in the conflict detection mark.

[0041] In this embodiment, when the conflict feature extraction is performed on the initial predicted state vector, the asynchronous data processing system identifies abnormal patterns within the vector through a multidimensional feature analysis engine. For example, a predicted state vector shows that a leaf node of the smart contract storage tree undergoes a nonlinear numerical transition during the interest calculation cycle. The system calculates the standard deviation offset of the current vector in the time dimension by comparing the interest accumulation curve of similar contracts in the historical state vector. When the offset exceeds the preset threshold, the conflict classification model determines it as a smart contract logic conflict type and generates a high-priority conflict type identifier. At the same time, the system calculates the conflict weight according to the linear proportional formula based on the peak memory and CPU time occupied by the vector during the simulation execution process, so that the conflict event with higher resource consumption has a higher correction priority in subsequent processing. In this process, the asynchronous data processing system maintains a dynamic mapping relationship between the conflict weight and the real-time load status of the distributed account network to ensure that the calculation of resource occupancy reflects the actual processing capacity of the current node.

[0042] 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.

[0043] In this embodiment, when the initial prediction state vector is dynamically corrected based on the conflict weight, the asynchronous data processing system implements a multi-stage correction strategy. For example, when a prediction vector is detected to have an account balance conflict and the conflict weight reaches 0.7, the system first queries the global account lock status of the distributed account network, confirms that the conflicting account is not locked by other transactions, and then uses the optimistic lock mechanism to perform secondary verification on the prediction value: the difference between the initial predicted balance change value and the latest on-chain state of the account is calculated. If the difference is within the reasonable fluctuation range within the transaction time window, the prediction value is smoothed and interpolated according to the conflict weight ratio. The corrected target prediction state vector not only contains the adjusted account final state value, but also adds a version compatibility identifier and a conflict resolution certificate. The system marks the corrected vector as a valid prediction element, and at the same time feeds back the resource occupancy index involved in the vector to the load balancing controller for optimizing the allocation strategy of subsequent transaction data blocks. In this process, the correction result of the high-weight conflict event will trigger a detailed record of the asynchronous processing status log, providing complete behavioral chain evidence for subsequent audit tracking.

[0044] In a preferred embodiment, the step 144 of extracting conflict features from the initial prediction state vector to obtain the conflict type identifier and conflict weight in the conflict detection mark includes: Step 1441: extract the dimensional distribution characteristics of the initial prediction state vector, and calculate the dimensional offset between the dimensional distribution characteristics and the historical state vector.

[0045] In this embodiment, when extracting the dimensional distribution characteristics of the initial predicted state vector, the asynchronous data processing system converts the dimensional data such as account balance, contract storage tree depth, operation timestamp, etc. in the vector 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 to form a three-dimensional feature distribution graph. 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, when it is detected that the growth rate of the target chain account balance is two standard deviations lower than the historical mean, the dimension is marked as potentially abnormal. The calculation of the dimensional offset adopts the Mahalanobis distance algorithm to eliminate the influence of the dimensional differences of different dimensions on conflict detection.

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

[0047] In this embodiment, when the dimension offset is input into the pre-trained conflict classification model, the asynchronous data processing system activates the 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 predicted state vector have reverse 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 that the conflict belongs to the inconsistency 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. The system synchronously updates the convolution kernel weights of the feature extraction layer during the real-time classification process to adapt to the new conflict mode brought about by the protocol upgrade of the distributed accounting network.

[0048] 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.

[0049] In this embodiment, when the corresponding weight calculation rule is called according to the conflict type identifier, the asynchronous data processing system configures differentiated calculation parameters for different types of conflicts. For example, for the account balance conflict type, the weight calculation rule weights and sums the memory usage of the transaction data block and the network bandwidth consumption in a ratio of 1:3; for the smart contract storage conflict type, the composite indicator of CPU computing time and storage IO operation times is considered. The system uses a sliding window mechanism to count the resource usage baseline of the current node, and uses the ratio of the actual resource usage rate of the transaction data block to the baseline value as the adjustment coefficient of the conflict weight. When processing a concurrent operation conflict of a high-frequency trading account, the system detects that the transaction occupies 70% of the node's memory resources, and then generates a conflict weight value of 0.85, which will directly affect the intervention intensity of subsequent state corrections.

[0050] In this embodiment, the conflict classification model is trained by step 14420. Step 14420: Collect state vector samples of historical conflict events, label the state vector samples with conflict type labels, use a multi-layer convolutional network to extract local gradient features of the state vector samples, and optimize the classification loss function through back propagation. In this embodiment, when training the conflict classification model, the asynchronous data processing system constructs a training data set containing millions of historical conflict event samples. Each sample contains complete predicted state vector metadata, conflict type labels and processing result feedback. The system uses a deep separable convolution structure to perform hierarchical extraction of the spatiotemporal features of the state vector: the first layer of convolution kernels captures the association pattern between account balances and timestamps, the second layer of convolution kernels identifies the topological change characteristics of the smart contract storage tree, and the third layer of convolution kernels analyzes the hash locking relationship of cross-chain transactions. During the training process, the cross entropy loss function is optimized by the back propagation algorithm, and the attention mechanism is introduced to enhance the ability to identify rare conflict types. For example, for the cross-chain atomic swap conflict type that only accounts 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.

[0051] In a preferred embodiment, writing the global state update matrix to the consensus node set of the distributed ledger network in step 180 includes: Step 181: According to the write priority of the asynchronous processing status log, the global state update matrix is ​​divided into P data shards; 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.

[0052] In this embodiment, the asynchronous data processing system dynamically determines the write priority according to the historical processing delay 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 retrieves the processing records of similar transactions in the historical log: digital asset pledge transactions involve smart contract state locking operations, and the historical average processing delay is 450 milliseconds; while cross-chain remittance transactions require multi-node collaborative verification, and the historical average processing delay is 1200 milliseconds. The system generates a priority score of 0.85 for the data shard corresponding to the digital asset pledge transaction and a priority score of 0.65 for the cross-chain remittance transaction shard, forming a negative correlation mapping relationship. During the segmentation process, the asynchronous data processing system uses a space filling curve algorithm to divide the matrix into P data shards to ensure that the high-priority shard contains continuously stored account status units. Taking the pledge transaction shard as an example, the shard centrally stores associated fields such as the pledge account address, the number of pledged objects, and the smart contract lock status, and optimizes the reading efficiency of subsequent nodes through physical storage continuity.

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

[0054] In this embodiment, the asynchronous data processing system implements a geo-aware strategy when assigning a target node group to each data shard. For example, because the cross-chain remittance transaction shard involves collaborative verification of nodes in Asia and Europe, the system selects consensus nodes located in Singapore and Frankfurt to form a target node group, which is pre-configured with a low-latency cross-border communication line. After the allocation is completed, the system generates a hash identifier with a nanosecond timestamp for each shard, specifically using a double-layer hash structure: the inner hash generates a SHA3-512 summary value based on the byte stream of the shard content, and the outer hash concatenates the summary value with the timestamp and hashes it again to form a shard identifier with strong anti-collision characteristics. Taking the digital asset pledge transaction shard as an example, its hash identifier not only contains a summary of core fields such as the number of pledged assets and lock time, but also embeds a distributed clock synchronization timestamp accurate to 100 nanoseconds to ensure that global nodes can verify the authenticity of the shard generation time.

[0055] 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.

[0056] In this embodiment, when the asynchronous data processing system sends the data shard and its hash identifier to the target node group through the atomic broadcast protocol, a hierarchical verification mechanism is implemented. For example, when broadcasting the 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 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, and 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 signal containing the node digital certificate signature.

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

[0058] 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 a cross-regional 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 the transaction logs of all nodes are synchronized and updated through a two-phase commit protocol; 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 proofs. After all write operations are completed, the participating nodes synchronously update the local state copies, and broadcast the write confirmation events to the entire network to form a closed-loop verification chain.

[0059] In a preferred embodiment, the step 120 of parsing the asynchronous processing trigger event to generate a state transition instruction sequence includes: Step 121: extracting the event type code and the event dependency graph from the asynchronous processing trigger event.

[0060] In this embodiment, when the asynchronous data processing system extracts the event type code and event dependency graph from the asynchronous processing trigger event, accurate classification is achieved by parsing the semantic structure of the trigger event tuple. For example, when a regional node of the distributed ledger network triggers a batch processing event due to a backlog in the memory pool, the system first identifies the "high-throughput cross-chain remittance" identifier in the event type code, which adopts a hierarchical bit field structure: the first 16 bits represent the transaction type (0x01 represents cross-chain operation), the middle 32 bits record the priority score (0x85 represents high priority), and the last 64 bits store the time window identifier (UTC timestamp and processing cycle number combination). The event dependency graph is constructed by analyzing the account interaction mode between transaction data blocks. For example, if five cross-chain remittance transactions are detected to involve asset transfers in the same liquidity pool, the system draws a topological graph containing five nodes and twelve directed edges, and the edge weight represents the dependence strength of the balance change between transactions. Specifically, a remittance transaction from chain A to chain B points to another relay remittance transaction from chain B to chain C in the event dependency graph, forming a cross-chain transaction dependency chain.

[0061] Step 122: Generate dependency constraints of the state transition instruction according to the event dependency graph.

[0062] In this embodiment, when the asynchronous data processing system generates dependency constraints for state transition instructions based on the event dependency graph, the graph theory algorithm is used to transform the transaction association rules. For example, when processing the dependency graph involving digital asset pledge and interest settlement, the system identifies the predecessor and successor relationship between the pledge transaction node and the interest calculation node, and generates a hard constraint condition of "prohibiting the start of interest calculation before the pledge lock status verification is completed". For dependencies with parallel paths, the system introduces a resource lock mechanism: when it is detected that two transactions need to modify the storage tree of a smart contract at the same time, a dynamic constraint condition of "access to the shared contract storage slot requires obtaining an exclusive lock" is generated. Taking the cross-chain remittance scenario as an example, a node in the dependency graph needs to wait for the inter-chain bridge contract to confirm the cross-chain asset freezing operation. For this purpose, the system generates a composite dependency constraint containing a timestamp threshold and an on-chain proof verification condition.

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

[0064] In step 123, when the asynchronous data processing system calls the instruction generation model to decode the event type code to generate a candidate instruction set, a multi-stage semantic conversion is implemented. For example, for the "high priority cross-chain remittance" event type code, the model first generates a basic instruction sequence of "locking the source chain account balance → verifying the cross-chain bridge contract status → creating the target chain entry transaction", and each instruction carries a dependency constraint. When processing a digital asset pledge event, the model outputs an instruction chain of "verifying the ownership of the pledge → calculating the dynamic pledge rate → updating the smart contract lock status", where the dynamic pledge rate calculation instruction is accompanied by the constraint of "needing to obtain the real-time data of the on-chain price oracle". In this process, the instruction generation model inserts preemptive resource allocation instructions for high-priority transactions by analyzing the priority identifier in the event type code, such as adding a constraint of "preferentially occupying the cross-chain channel bandwidth" for cross-chain operations involving the core accounts of the system.

[0065] 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.

[0066] In this embodiment, the asynchronous data processing system adopts a strategy combining 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 area, triggering the instruction filtering mechanism. For instructions involving smart contract state migration, the system simulates the execution path through the sandbox environment. When it is found that the "update pledge contract storage tree" instruction and the "clearing 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 occupation mode of each instruction on the distributed accounting 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.

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

[0068] In this embodiment, when the asynchronous data processing system sorts the target instruction set according to the dependency constraints to generate the state transition instruction sequence, topological sorting and dynamic scheduling are implemented. For example, the instruction set of the digital asset pledge scenario includes four instructions: "verify the ownership of the pledge → obtain the price data on the chain → calculate the dynamic pledge rate → update the contract lock status". The system constructs a directed acyclic graph based on the dependency constraints to generate a linear execution sequence. When encountering instructions with parallel constraints, such as "verify the source chain balance" and "obtain the target chain exchange rate" in cross-chain remittances, the system inserts a synchronization barrier instruction to form a "parallel execution instruction block → wait for all to be completed → continue the subsequent process" structure. The sorting algorithm monitors the resource load status of the distributed ledger network in real time and dynamically adjusts the order of instruction execution. For example, when the node computing resources are tight, the pledge rate calculation instruction with high memory usage is postponed, and lightweight verification instructions are processed first.

[0069] 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: 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: adopt a masked sequence-to-sequence architecture, perform autoregressive prediction on the historical event type codes and the corresponding target instructions, and optimize the conflict avoidance reward value of the target instructions through reinforcement learning.

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

[0071] 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.

[0072] In this embodiment, the asynchronous data processing system uses the attention mechanism to match the event semantic feature vector with the historical instruction template to achieve context-aware template retrieval. For example, when processing the feature vector of a digital asset pledge event, the attention layer activates the template entries related to "Pledge Verification", "Interest Rate Calculation", and "State Lock" in the historical template library, and generates the corresponding attention weight distribution. The weight calculation uses the scaled dot product attention algorithm, in which the feature vector of the pledge event and the pledge operation template vector in the historical template library calculate the similarity score, forming a high weight value of 0.78, while the similarity score with the cross-chain remittance template is only 0.12. The system limits the attention range through a sliding window mechanism to ensure that template matching focuses on the optimal historical solution for similar events.

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

[0074] In this embodiment, the asynchronous data processing system implements dynamic threshold control when screening Top-R candidate templates according to the attention weight distribution. For example, when processing cross-chain remittance events, the system selects the top 5 templates with the highest weight from the historical template library, including "fast channel cross-chain template", "multi-signature verification cross-chain template", "batch processing cross-chain template", etc. An adaptive threshold algorithm is used in the screening process: when it is detected that the semantic difference between high-weight templates is lower than the preset value, the number of candidates is automatically expanded to R+3 to avoid missing key variant templates. Taking digital asset pledge as an example, the system screens out three Top-R candidates: "standard pledge template", "excess pledge template", and "joint pledge template", each of which carries a differentiated set of constraints.

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

[0076] In this embodiment, when the asynchronous data processing system logically splices the candidate templates with the dependent constraints, formal verification is implemented to ensure consistency. For example, when splicing the "fast channel cross-chain template" with the constraint condition of "need to be executed after the target chain block height reaches the threshold", the system inserts a block height monitoring clause before the template's bridge contract call instruction to form a compound instruction of "wait for the target chain block height ≥ N → trigger cross-chain transfer". For templates involving multiple resource competition, the splicing process introduces a logical disjunction operation: when the "multi-signature verification cross-chain template" encounters the constraint of "need to complete consensus verification within 30 seconds", the system generates a branch instruction "switch to fast channel mode if multi-signature verification times out". All spliced ​​candidate instructions must be checked by the formal verification engine to ensure that the constraints and template operations are self-consistent in temporal logic.

[0077] In an optional embodiment, the method further comprises: 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.

[0078] 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 finds 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 locking state of the source chain and the account entry state of the target chain. At this time, the system analyzes the associated metadata of the pending state and identifies that the transaction contains three separable operation stages: source chain locking, 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.

[0079] 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.

[0080] In this embodiment, the asynchronous data processing system uses a multi-dimensional feature extraction engine when extracting Q sub-transaction features from the transaction data block associated with the pending state. For example, for the pending transaction data block of the above-mentioned cross-chain atomic exchange, the system parses its operation type field as "cross-chain asset transfer", analyzes the resource access mode 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: the source chain lock feature vector contains the account address, lock amount and timestamp; the bridge verification feature vector contains the bridge contract address and the cross-chain proof hash value; the target chain account entry feature vector contains the target account address and the exchange rate conversion parameters. Each feature vector is converted into a 128-bit feature code that matches the sub-state machine splitting condition through a hash mapping algorithm to ensure that the generation of the sub-state machine instance accurately corresponds to the semantic segmentation requirements of the original transaction.

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

[0082] 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; the target chain account entry 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 target chain account entry instance has a processing delay of more than 3 seconds due to excessive load on the target node, the instance migration mechanism encapsulates its complete context state into a migration package, which is transmitted to the standby node group through a low-latency network for re-mounting and execution.

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

[0084] 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 the completion signal, the system starts a two-stage merge operation: the first stage verifies the integrity of the digital signature chain of each instance and confirms that the processing result has not been tampered with; the second stage performs a logical merge, and the three results of source chain account unlocking, bridge proof cancellation and target chain account confirmation are combined into an atomic operation unit according to the transaction atomicity rules. The merged results are updated to the cross-chain transaction partition of the global state update matrix, and the original pending state is marked as resolved. The version superposition technology is used in the update process 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.

[0085] In an optional embodiment, the use of an asynchronous pipeline in step 204 to process Q sub-state machine instances in parallel includes: 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 the 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 in a preset safety interval. 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 times; for the bridge verification instance, the zero-knowledge proof verification duration and the cross-chain message queue depth are monitored. The PID controller normalizes each indicator into a resource consumption pressure value, and dynamically adjusts the weight distribution of the thread pool through the proportional-integral-differential algorithm: when the pressure value of the source chain lock instance exceeds the upper limit of the safety interval, the controller reduces its thread quota by 5% according to the negative feedback principle, and increases the quota compensation for the bridge verification instance by 3% to maintain the overall pipeline throughput stability. The system's preset safety interval is dynamically adjusted according to the historical load pattern. For example, during the peak period of cross-border payments, the GPU memory safety interval of the bridge verification instance is automatically expanded to 90%.

[0086] In an optional embodiment, the method further comprises: Step 300: When the generation period of the asynchronous processing status log reaches a preset threshold, a log compression optimization mechanism is triggered.

[0087] 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 operations on the snapshot copy. The compression trigger condition is linked to the load status of the distributed accounting network. When the network is in a low-load period, compression is automatically performed in advance to avoid resource competition during peak hours.

[0088] 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 classifying state transition patterns with a frequency higher than a set frequency as frequent patterns through a clustering algorithm.

[0089] In this embodiment, when extracting frequent state transition patterns from the asynchronous processing state log, the asynchronous data processing system adopts an analysis method combining sliding windows and density clustering. For example, when analyzing the digital asset pledge transaction log, the system sets a 30-minute sliding window, and statistically finds that the three-step conversion pattern of "collateral lock → interest rate calculation → status update" appears 1200 times in the window, exceeding the set threshold of 1000 times, and is classified as a frequent pattern. The clustering algorithm aggregates similar patterns into pattern clusters based on the time distribution characteristics and account relevance of the conversion events, for example, identifying two subclasses of "fast pledge mode" (average completion time of 8 seconds) and "excess pledge review mode" (average completion time of 25 seconds). The generated pattern index tree adopts 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.

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

[0091] In this embodiment, when merging and encoding the continuous 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 the smart contract status update log, 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.

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

[0093] In this embodiment, when the compressed log block is associated with the state transition pattern index tree for storage, the asynchronous data processing system builds a bidirectional reference relationship. For example, the cross-chain remittance compressed log block embeds the node ID of the corresponding pattern index tree when it is stored, and the index tree node expands the storage of the physical address pointer pointing to the compressed block. The associated storage adopts a sharding strategy, co-locating the high-frequency accessed compressed log block and the main body of the index tree in the storage node, and the low-frequency historical data is distributed and stored in the edge nodes. During the deletion of redundant entries, the system implements three levels of 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; 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 allocated to high-priority log write requests first.

[0094] In a preferred embodiment, the step of generating an asynchronous processing status log matching the transaction request set in step 180 includes: Step 1801: extract a state change record set from the global state update matrix, and generate an initial log sequence in chronological order.

[0095] In this embodiment, when the asynchronous data processing system extracts the state change record set from the global state update matrix, it captures the complete operation track by traversing the hierarchical storage structure of the matrix. For example, when processing the global state update matrix of a cross-chain remittance transaction, the system extracts the source chain account balance deduction record and the target chain account entry record from the base layer, obtains the difference accumulation value generated by the 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 according to the operation completion time to form an initial log sequence containing the operation type code, resource identifier, state change value and timestamp. Taking a transaction involving a digital asset pledge as an example, the initial log sequence records the pledge lock time, the pledge rate calculation process, and the smart contract state update operation in sequence. Each log entry carries the blockchain height and node location information to ensure traceability in the time and space dimensions.

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

[0097] In this embodiment, the asynchronous data processing system implements fine-grained resource dependency detection when performing causal analysis on the initial log sequence. For example, when analyzing the cross-border payment log sequence, the system finds that the balance write operation of a target account depends on the balance read operation of the source account, and detects 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 needs to read two resource items, the pledge value and the loan amount, at the same time, and these two resource items are written by the previous asset evaluation operation and loan approval operation, respectively, forming a multi-input dependency.

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

[0099] In this embodiment, when the initial log sequence is rearranged according to the topological sorting result of the directed acyclic graph, the asynchronous data processing system implements an event replay verification mechanism. For example, the events in the cross-border payment log that were originally sorted by the receiving time are rearranged into the causal order of source chain locking → cross-chain proof generation → target chain account verification. For the digital asset pledge log, the pledge rate calculation and risk assessment log events that are executed in parallel are adjusted to a serial order to meet the transaction atomicity requirements. During the rearrangement process, the system retains the original timestamp information as an auxiliary sorting key value to ensure that the temporal authenticity is retained to the maximum extent possible while maintaining the causal relationship.

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

[0101] In this embodiment, when inserting checkpoint marks 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, which contains the hash summary of the first 50 events, the root hash of the current global state tree, and the time range proof. The checkpoint of the digital asset pledge log additionally contains a version snapshot of the smart contract storage tree. After each checkpoint mark is generated, the system writes its hash value to the regulatory contract of the blockchain to achieve an unalterable anchoring effect. When log verification is required, the abnormal segment can be quickly located by comparing the continuity of the checkpoint mark and the Merkle proof.

[0102] In a preferred embodiment, the step of performing causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events in step 1802 includes: 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 a resource read operation and a resource write operation.

[0103] In this embodiment, when parsing log events in the initial log sequence, the asynchronous data processing system uses a semantic enhancement parser to extract the operation 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 triple of the source chain account address, the cross-chain bridge contract address, and the target chain account address. The system accurately separates the modified account balance field, the updated contract storage tree path, and the written cross-chain transaction hash value by parsing the binary payload of the log event. For digital asset pledge log events, the system identifies the operation type as a composite operation, which includes the "resource write operation" of the pledge storage slot and the "resource read operation" of the loan contract parameters, and extracts the corresponding resource identifier set.

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

[0105] 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 smart contract triggering a log event contains three leaf node addresses of the contract storage tree, corresponding to the total amount of tokens, the liquidity pool ratio, and the handling 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, and the resource read set involves the source chain block header hash and the target chain light node verification key, forming a resource access mode unique to cross-chain transactions.

[0106] 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.

[0107] In this embodiment, when traversing log events to create direct causal edges, the asynchronous data processing system adopts an efficient intersection detection algorithm. For example, when analyzing the log event sequence of digital asset pledge, it is found that the pledge rate storage slot written by the Nth log event is read by the N+1th log event, and 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 written to the storage tree root node of the same smart contract at the same time, the system creates a mutually exclusive causal edge and marks it as a write-after-write conflict, triggering the subsequent circular dependency detection mechanism.

[0108] 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.

[0109] 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, so that causal events that are close in time have higher weights. In the digital asset pledge scenario, the system marks 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, to provide semantic enhancement information for subsequent topological sorting.

[0110] 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.

[0111] In this embodiment, when detecting circular dependencies in the initial causal graph, the asynchronous data processing system implements a strategy that combines depth-first search with timestamp backtracking. For example, in the cross-chain atomic swap log, it is found that the source chain lock log event A and the target chain account log event B point to each other to form a circular dependency: the lock state written by A is read by B, and the account state written by B is read by the compensation mechanism of the transaction where A is located. The system traverses all log events in the circular dependency loop, identifies the earliest timestamp event A as the starting point of the loop, removes the reverse causal edge of event B pointing to A, and breaks 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.

[0112] 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.

[0113] In this embodiment, when generating an updated causal graph and performing topological sorting, the asynchronous data processing system uses the Kahn algorithm to achieve efficient sorting. For example, when processing the causal graph of digital asset pledge, the system first determines the initial node without dependency (such as the pledge ownership verification log event), removes its output edges in turn and records the topological order. When encountering log events with multiple predecessor nodes (such as interest calculation logs that require two inputs, the pledge rate and the benchmark interest rate), the system dynamically adjusts the processing order according to the timestamp gap to ensure that all predecessor dependency conditions are met. After the topological sort is successful, the system outputs a directed acyclic graph with a strict partial order relationship, in which the direction of each edge represents an irreversible causal relationship.

[0114] In a preferred embodiment, the step of inserting a checkpoint mark into the rearranged log sequence in step 1804 to generate a segment-verifiable asynchronous processing status log includes: Step 180401: Based on the event order of the rearranged log sequence, determine the target event interval threshold between adjacent checkpoint marks.

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

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

[0117] In this embodiment, when the rearranged log sequence is segmented according to the target event interval threshold, the asynchronous data processing system implements a transaction boundary-aware segmentation strategy. For example, when processing the causal sorting log of cross-chain atomic swaps, the system immediately creates a segmentation boundary after completing the complete transaction chain of "source chain locking → bridge verification → target chain accounting" even if the number of events does not reach the threshold. For the digital asset pledge log sequence, the system identifies the logical continuity of the pledge rate calculation and interest accumulation to ensure that a single log segment completely contains the full process events from pledge locking to interest settlement. The transaction atomicity verification mechanism is used in the segmentation process. When a log event is detected to belong to an unfinished multi-chain transaction, the segmentation boundary is automatically extended to the transaction completion point to avoid the causal chain break across segments.

[0118] 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.

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

[0120] Taking the digital asset pledge log as an example, the verification information generation formula 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 participating node signature list in the verification information to enhance the auditability of the segment.

[0121] Step 180404: insert a checkpoint mark at the boundary position of adjacent log segments, wherein the checkpoint mark carries the start event identifier, end event identifier and corresponding segment verification information of the current log segment.

[0122] In this embodiment, when inserting the checkpoint mark carrying verification information, the asynchronous data processing system adopts the binary mark encoding specification. For example, the checkpoint mark of the cross-chain remittance log segment contains three core fields: the start event identifier is the globally unique transaction ID of the source chain locking operation, the end event identifier is the block height hash value of the target chain account confirmation, and the segment verification information stores the cryptographic hash and predecessor hash pointer of the segment. The tag structure is encapsulated in TLV (type-length-value) format. The type field indicates the log classification (such as 0x01 represents cross-border payment), the length field identifies the number of bytes of each data block, and the value field stores the serialized verification data. In the digital asset pledge scenario, the checkpoint tag adds an additional smart contract version identification field to ensure that the state change strictly corresponds to the contract logic.

[0123] Step 180405: Combine all log segments carrying checkpoint marks in order to generate an initial segment log sequence.

[0124] In this embodiment, when the log segments carrying checkpoint marks are combined to form the 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 high-frequency access segments in the A region node, and stores historical cold data in the B region node. Memory-mapped file technology is used in the combination process to map logically continuous log segments into continuous blocks of physical storage to optimize subsequent reading efficiency. For digital asset pledge logs, the system embeds a segment metadata index table in the initial sequence to support rapid positioning of related log segments through the pledge contract address.

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

[0126] In this embodiment, when extracting checkpoint mark information to generate a global verification chain, the asynchronous data processing system constructs a multi-level hash authentication structure. For example, the segmented verification information extracted from the cross-border payment log sequence is arranged in chronological order, and a compact verification chain is generated through Merkle tree aggregation. Each tree node stores the concatenated hash value of the hashes of the two child nodes, and the leaf node is the original hash of each segmented verification information. The global verification chain of the digital asset pledge log adopts an improved star structure, the central node stores the verification information of the latest segment, and the historical segments form radial links through hash pointers. The system adds a digital signature ring to the verification chain, requiring more than 2 / 3 of the consensus nodes to jointly sign the root hash of the verification chain to prevent the risk of single-point tampering.

[0127] Step 180407: store the global verification chain in association with the initial segmented log sequence, and generate an asynchronous processing status log including the segmented verification chain.

[0128] 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, and supports two-way queries with O(logn) complexity. For digital asset pledge logs, the associated storage process introduces versioned snapshot technology, generates incremental snapshots 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, encodes the verification chain data into multiple data blocks and stores them in edge nodes to ensure that some nodes can be fully restored when they fail.

[0129] 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.

[0130] In this embodiment, when recursively hashing 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, verify 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.

[0131] 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 the associated checkpoint mark of the target log segment, and synchronously update the hash value sequence of the global verification chain.

[0132] In this embodiment, when processing new log events to update the target segment, the asynchronous data processing system implements an incremental update strategy that minimizes the scope of impact. For example, when a new cross-chain remittance compensation transaction is generated, the system locates the cross-border payment log segment to which it belongs and marks the segment as modifiable. The update process includes: recalculating the hash chain of all events in the segment to generate new segment verification information; adjusting the hash reference relationship of all subsequent segments; and re-verifying the segment set affected by the modification through distributed consensus. For new interest settlement events in the digital asset pledge log, the system uses COW (copy on write) technology to create a copy of the segment for modification, and then atomically replaces the old version after verification to ensure uninterrupted online services.

[0133] 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.

[0134] In this embodiment, when recalculating the integrity identifier of the asynchronous processing status log, the asynchronous data processing system implements a multi-factor fusion algorithm. 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, and a threshold signature mechanism is used to generate a composite hash value. When it is detected that the integrity identifier of the cross-border payment log is inconsistent with the storage status, the system triggers an automatic repair process: obtain a copy of the verification chain from the majority of nodes, determine the correct version through the Byzantine fault tolerance algorithm; rebuild the checkpoint mark of the affected segment; finally generate a new integrity identifier and broadcast 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 the interest calculation to ensure that the integrity of the business logic is not affected by changes in the storage structure.

[0135] As an optional but non-limiting embodiment, the dependency constraint condition for generating the state transition instruction according to the event dependency graph in step 122 includes: parsing the node set and edge set in the event dependency graph, the node set representing the independent transaction events in the transaction request set, and the edge set representing the execution order dependency between the independent transaction events; traversing each directed edge in the edge set, extracting the edge attribute information of the directed edge, the edge attribute information including the timestamp interval, the resource lock identifier and the transaction isolation level; identifying the sequence dependency type between the independent transaction events according to the timestamp interval overlap state in the edge attribute information, the sequence dependency type including strong sequence dependency, weak sequence dependency and parallel dependency; generating an initial The initial dependency constraint condition set is a set of dependencies, 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; the circular dependency chain in the initial dependency constraint condition set is detected, each node in the circular dependency chain is traversed, the lock allocation order is dynamically adjusted according to the holding priority of the resource lock identifier, and a modified constraint condition set that eliminates the circular dependency is generated; the redundant constraints for the same resource lock identifier in the modified constraint condition set are merged, the constraints of the highest transaction isolation level are retained, and a simplified dependency constraint condition set is generated; the topological structure consistency of the simplified dependency constraint condition set and the event dependency graph is verified, and if there is an uncovered dependency edge, a timestamp interval forced alignment constraint is supplemented to generate a final dependency constraint condition. The timestamp interval forced alignment constraint is generated in the following manner: the timestamp difference between the start transaction event and the end transaction event corresponding to the uncovered dependency edge is calculated, and if the difference exceeds a preset threshold, a timestamp synchronization instruction is inserted to limit the start transaction event to be executed within the timestamp window of the end transaction event.

[0136] In the specific implementation, first parse the event dependency graph, map the nodes to independent transactions (such as pledge operations, cross-chain verification), and the edges represent the execution order dependency. Traverse each directed edge 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). According to the timestamp overlap, three types of dependencies are divided: strong order dependency (transaction B must be executed after transaction A is completed, such as the pledge lock before the interest calculation) generates a mutex constraint; weak order dependency (transaction B reads the data written by A, such as the exchange rate query depends on the source chain balance) generates a shared lock; parallel dependencies without timestamp overlap (such as cross-chain transfers and local settlements) are marked as lock-free asynchronous execution. Then detect the circular dependency chain in the initial constraint (such as transaction A waits for B to release a lock, and B waits for A to release another lock), and dynamically adjust the order according to the resource lock priority: give the system core resources (such as the fee account) the highest priority, and force low-priority transactions to give up the lock resources. For example, when a cycle of pledge contract lock and liquidation lock is detected, the pledge lock is allocated first to interrupt the circular chain. When merging redundant constraints, retain the highest isolation level for the same resource. For example, when a cross-chain channel lock has read lock and write lock constraints, only the exclusive write lock constraint is retained. Finally, verify the consistency of the constraints and the topological structure, and enable timestamp alignment for uncovered edges (such as implicit timing dependencies between asynchronous transactions): If the difference between the timestamps of two transactions exceeds the threshold (such as 500ms), insert a synchronization instruction to restrict the subsequent transaction to be executed within the leading time window. For example, when the time difference between a pledge operation and a risk assessment reaches 800ms, the mandatory risk assessment is triggered within a 100ms time window after the pledge is completed. This mechanism improves the throughput efficiency of the distributed network while ensuring the atomicity of transactions through dynamic lock allocation and timing coordination.

[0137] As an optional but non-limiting embodiment, the 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 a proportional-integral-differential controller to calculate the dynamic adjustment coefficient of the current pipeline load; generating a thread scheduling weight table according to 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 of the target sub-state machine instance and the data packet to be processed 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 sub-state machine instance that has not been migrated; periodically polling the health status of all migrated sub-state machine instances, if an abnormal termination instance is found, rolling back the state according to the most recent checkpoint mark and rejoining the processing queue.

[0138] For example, when screening candidate nodes, select A1 and A2 nodes with current CPU utilization rates below 40% from the node cluster in region A and add them to the migration candidate list. The system encapsulates the context state of the cross-border payment instance (including bridge verification progress, cross-chain proof cache) and pending data packets (unconfirmed target chain block headers) into an encrypted migration container, and attaches an integrity check code based on the Merkle tree. According to the network quality score between nodes, select the A2 node with the lowest latency as the migration target. When resuming instance execution, after receiving the migration container, the A2 node first verifies the consistency of the check code with the original hash tree, then loads the context snapshot of the bridge verification instance, and continues to execute the cross-chain proof verification from the breakpoint. The original node releases the occupied 8GB video memory resources and updates the pipeline queue status. The processing results are returned to the master node through the asynchronous callback interface, and are sorted and merged with the local completed account verification results by timestamp. The system maintains a global transaction ID mapping table to ensure that the results of the migration instance can be correctly aggregated. When polling the health status, the cross-border payment instance migrated to the A2 node is checked every 5 seconds for its process status, resource consumption, and progress indicators. When it is found that the instance is abnormally terminated due to a target chain node failure, it will roll back to the verified cross-chain proof state based on the checkpoint mark written 10 seconds ago and rejoin 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.

[0139] See also 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 executable by the processor 210, and the processor 210 can execute the steps of the above-mentioned distributed account 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 account asynchronous data processing method based on the MEMO state machine.

Claims

1. A distributed account asynchronous data processing method based on MEMO state machine, characterized in that: include: 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; 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; A 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 marks, 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 a consensus node set of a distributed ledger network, and an asynchronous processing state log matching the transaction request set is generated.

2. The method according to claim 1, characterized in that 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 marks, including: 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; 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; Extracting conflict features from the initial prediction state vector to obtain a conflict type identifier and a conflict weight in the conflict detection mark; The initial prediction state vector is dynamically modified based on the conflict weight, a target prediction state vector is generated, and the target prediction state vector is marked as an element of the N prediction state vectors.

3. The method according to claim 2, characterized in that The extracting conflict features from the initial prediction state vector to obtain the conflict type identifier and the conflict weight in the conflict detection mark includes: Extracting the dimensional distribution features of the initial predicted state vector, and calculating the dimensional offset between the dimensional distribution features and the historical state vector; Inputting the dimension offset into a pre-trained conflict classification model, and outputting the conflict type identifier; Calling a 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; The conflict classification model is trained in the following way: collecting state vector samples of historical conflict events, labeling the state vector samples with conflict type labels, extracting local gradient features of the state vector samples using a multi-layer convolutional network, and optimizing the classification loss function through back propagation.

4. The method according to claim 1, characterized in that The step of writing the global state update matrix into a consensus node set of a distributed ledger network includes: According to the writing priority of the asynchronous processing status log, the global state update matrix is ​​divided into P data slices; 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 proportion of verification pass signals are received, the data shards are written into the persistent storage chain of the target node group; The write priority is determined in the following manner: historical processing delays of transaction data blocks associated with each data shard in the global state update matrix are counted, and a priority score is generated that is negatively correlated with the historical processing delay.

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

6. The method according to claim 5, characterized in that 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 splicing the candidate template with the dependency constraint condition to generate the candidate instruction set; The instruction generation model is trained in the following way: a masked sequence-to-sequence architecture is used to perform autoregressive prediction on the historical event type encoding and the corresponding target instructions, and the conflict avoidance reward value of the target instructions is optimized through reinforcement learning.

7. The method according to claim 1, characterized in that The method further comprises: 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; Extracting Q sub-transaction features from the transaction data block associated with the pending state, and generating Q independent sub-state machine instances; An asynchronous pipeline is used to process Q sub-state machine instances in parallel to generate a sub-state machine processing result queue; Monitor the completion status of the sub-state machine processing result queue, and when all sub-state machine instances are completed, merge the processing results and update the global state update matrix; The sub-transaction feature is extracted in the following manner: based on the operation type, resource access mode and transaction atomicity identifier of the transaction data block, a feature vector matching the sub-state machine splitting condition is generated; The method of using an asynchronous pipeline to process Q sub-state machine instances in parallel includes: Allocate 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, an instance migration mechanism is triggered to migrate the target sub-state machine instance to a low-load node; The flow control strategy is implemented in the following way: collecting resource consumption indicators of each sub-state machine instance in the pipeline in real time, and using a PID controller to adjust the thread scheduling weight so that the resource consumption indicator is in a preset safety range.

8. The method according to claim 1, characterized in that 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 the continuous repeated state transition events in the asynchronous processing state log to generate a compressed log block; The compressed log block is stored in association with the state transition mode index tree, and redundant entries in the asynchronous processing state log are deleted; 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 the state transition pattern with a frequency higher than a set frequency as a frequent pattern through a clustering algorithm.

9. The method according to claim 1, characterized in that 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; Performing causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events; Rearranging the event sequence of the initial log sequence according to the topological sorting result of the directed acyclic graph; Insert checkpoint markers into the rearranged log sequence to generate a segment-verifiable asynchronous processing state log; The performing causal relationship analysis on the initial log sequence to generate a directed acyclic graph of log events includes: Parsing each log event in the initial log sequence, extracting a target resource identifier and an operation type of the log event operation, wherein the operation type includes a resource read operation and a resource write operation; 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; Traversing 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 and the resource write set of the second log event have an intersection, then creating a direct causal edge between the first log event and the second log event; Construct an initial causal graph according to all direct causal edges, wherein the nodes of the initial causal graph are the log events, and the edges are the direct causal edges; Detecting a circular dependency in the initial causal graph, identifying a minimum timestamp log event in the circular dependency as a loop starting point, and removing causal edges generated after the loop starting point and pointing to the loop starting point; Generate an updated causal graph based on the removed causal edges, and perform topological sorting on the updated causal graph, and output the updated causal graph as the directed acyclic graph if the topological sorting is successful; The inserting of a checkpoint mark into the rearranged log sequence to generate a segmented verifiable asynchronous processing state log includes: Based on the event order of the rearranged log sequence, a target event interval threshold between adjacent checkpoint marks is determined; dividing the rearranged log sequence into a plurality of continuous log segments according to the target event interval threshold, each log segment containing a number of events not exceeding the target event interval threshold; Generate corresponding segment verification information for each log segment, wherein the segment verification information includes a cryptographic hash value of the current log segment and a hash reference of the previous segment verification information; Insert a checkpoint mark at the boundary of adjacent log segments, wherein the checkpoint mark carries a start event identifier, an end event identifier, and corresponding segment verification information of the current log segment; Combine all log segments carrying checkpoint marks in order to generate an initial segment log sequence; Extract the segment verification information of each checkpoint mark from the initial segment log sequence, and generate a global verification chain, wherein the global verification chain contains a hash value sequence of all segment verification information linked in chronological order; The global verification chain is associated with the initial segment log sequence for storage, and an asynchronous processing status log including the segment verification chain is generated; 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, 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, locate the target log segment to which the new event belongs, update the segment verification information and the associated checkpoint mark of the target log segment, and synchronously update the hash value sequence of the global verification chain; 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.

10. An asynchronous data processing system, characterized in that: It 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 executes the steps of any one of the methods of claims 1 to 9.

Images