Multi-chain transaction concurrent processing system and method

Abstract

The invention discloses a concurrent processing system and method for multi-chain transactions. The system comprises one or more source chain intelligent contract modules deployed on a source chain, a relay node, a plurality of target chain intelligent contract modules deployed on a target chain and a sharing sorting module. Wherein the sharing sorting module is configured to allocate a serial number for each cross-chain operation in response to a received sorting request data packet of the cross-chain operation, generate a sorting proof and a corresponding timestamp, and make a global decision according to a preset decision strategy in combination with a collected attempt execution receipt. And each target chain smart contract module is configured to submit the final state according to the received decision message from the sharing sorting module instead of submitting the final state according to the operation result. According to the method and the device, an authoritative global time sequence relationship is established for a multi-chain transaction concurrent service scene, a centralized global decision-making capability is also provided, and a complex application scene needing multi-chain state collaboration is supported.

Description

Multi-chain transaction concurrent processing system and method Technical Field

[0001] This application relates to the field of blockchain technology, and specifically to systems and methods that support the interaction and coordination of multiple blockchains. Background Technology

[0002] The statements in this section are merely to provide background information in relation to this application to aid in understanding it, and such background information does not necessarily constitute prior art.

[0003] Blockchain, as a multi-replica state machine based on peer-to-peer distributed ledgers, provides traceability and immutability guarantees for data storage through a decentralized architecture, and has gained widespread attention globally. With technological iteration and the continuous expansion of application scenarios, single blockchain systems are gradually becoming insufficient to meet the growing demands for cross-industry and cross-domain collaboration. The blockchain ecosystem is evolving from a single-chain architecture to a multi-chain coexistence pattern, making cross-chain technology a key infrastructure supporting multi-chain interconnection.

[0004] Existing cross-chain protocols can be broadly categorized into two types based on their functional characteristics: cross-chain protocols that support asset transfer or exchange, and cross-chain protocols that support information transmission. Cross-chain protocols supporting asset transfer or exchange primarily focus on the flow of digital assets between different blockchains. By custodying, locking, or destroying assets on the source chain, equivalent mapped assets are generated on the destination chain, thereby achieving cross-chain value transfer. Cross-chain protocols supporting information transmission, on the other hand, place greater emphasis on information interaction and data synchronization between blockchains, allowing decentralized applications to perform efficient cross-chain calls and state coordination across different blockchains. As blockchain application scenarios have evolved from simple asset transfers to more complex business models, the demand for cross-chain technology has correspondingly expanded from simple value transfer to multi-dimensional interaction. Therefore, cross-chain protocols supporting information transmission have become a key direction in the evolution of cross-chain technology.

[0005] However, current cross-chain messaging protocols mainly focus on single-chain to single-chain peer-to-peer messaging. The protocols of different chains have significant differences in interface design, security models and implementation mechanisms. Therefore, when developing cross-chain contracts, it is necessary to write special adaptation code for different chains. This has led to the formation of new "protocol silos" in cross-chain networks built on different protocols, which restricts the interconnection and collaborative development of multiple chains on a larger scale. Summary of the Invention

[0006] Unlike the peer-to-peer dual-chain interaction mode of existing cross-chain information transmission protocols, this application aims to provide a solution that supports concurrent multi-chain interaction to adapt to more complex multi-chain application scenarios.

[0007] The purpose of this application is achieved through the following technical solution: According to the first aspect of this application, a concurrent processing system for multi-chain transactions is provided, including: one or more source chain smart contract modules deployed on the source chain, relay nodes, and multiple destination chain smart contract modules deployed on the destination chain, as well as a shared sorting module; wherein, the shared sorting module is configured to: in response to a received sorting request data packet from one or more source chain smart contract modules for their cross-chain operations, assign a sequence number to each cross-chain operation, generate a sorting proof and a corresponding timestamp, record information related to the cross-chain operation in an operation log, and, according to a preset... The decision-making strategy combines the collected attempt execution receipts from multiple destination chain smart contract modules to make a global decision, generating a decision message to confirm or cancel the cross-chain operation, and sending the decision message to the source chain and the destination chain. The attempt execution receipt is assembled by the destination chain smart contract module according to the sequence number, sorting proof, and corresponding timestamp, reserving resources and performing simulation calculations on the cross-chain operation in sequence, and then based on the calculation results. Each destination chain smart contract module is configured to submit the final state based on the decision message received from the shared sorting module, instead of submitting the final state based on the calculation results after performing the simulation calculation.

[0008] Preferably, each destination chain smart contract module is also configured to: if the decision message received from the shared sorting module confirms the cross-chain operation, then the reserved resources will be officially credited; if the decision message received from the shared sorting module cancels the cross-chain operation, then the reserved resources will be released.

[0009] Preferably, each source chain smart contract module is configured to: receive cross-chain operation requests from one or more users, wherein each cross-chain operation request includes at least the identifier of the destination chain, the smart contract address of the destination chain, business data, and decision strategy; for each cross-chain operation, assign a corresponding operation identifier, and determine the channel identifier of the cross-chain operation based on the identifier of the destination chain, the smart contract address of the destination chain, the source chain identifier, and the smart contract address on the source chain; construct a sorting request data packet for the cross-chain operation based on the operation identifier, channel identifier, business data, and decision strategy, and send the sorting request data packet to the shared sorting module; and execute the confirmation process or cancellation process of the cross-chain operation in response to the decision message received from the shared sorting module; and wherein the shared sorting module is further configured to, in response to receiving the sorting request data packet for each cross-chain operation, assign a sequence number to the cross-chain operation according to the following rules: 1) each sequence number is uniquely assigned globally, and there are no sequence number conflicts; 2) the sequence number is strictly monotonically increasing within the same channel identifier range; 3) the assigned sequence number cannot be modified or revoked afterward.

[0010] Preferably, the system includes one or more relay nodes, each relay node being configured to: respond to the shared sorting module writing information related to the cross-chain operation into the operation log; prepare corresponding proof materials according to the verification mechanism of the target chain corresponding to the cross-chain operation; assemble the information related to the cross-chain operation in the operation log and the proof materials into a general cross-chain information data packet; deliver the general cross-chain information data packet to the corresponding target chain; capture attempt execution receipts from each target chain and forward the attempt execution receipts to the shared sorting module; and capture decision messages from the shared sorting module and forward them to the target chain smart contract module.

[0011] Preferably, each destination chain smart contract module is further configured to: in response to receiving a general cross-chain information data packet, generate a message key corresponding to the general cross-chain information data packet based on the operation identifier, channel identifier, and sequence number of the cross-chain operation; query whether the message key already exists in a preset set of processed message keys; if the message key already exists in the set, the general cross-chain information data packet has been processed, and directly read the previously recorded attempt execution receipt corresponding to the general cross-chain information data packet from local storage; if the message key does not exist in the set, continue the subsequent execution process.

[0012] Preferably, each target chain smart contract module is further configured to: extract the expected version number of the target object associated with the cross-chain operation from the general cross-chain information data packet; read the current version number of the target object from the local state storage; compare whether the expected version number is equal to the current version number; if the version numbers are equal, generate a resource identifier for the cross-chain operation to identify the reserved resources, and mark the reserved state on the target object; if the version numbers are not equal, immediately return a version conflict error, without performing any resource reservation or state modification.

[0013] Preferably, each destination chain smart contract module is further configured to: extract effective block parameters and effective time parameters from the general cross-chain information data packet before assembling the attempt execution receipt; determine whether the activation conditions for the cross-chain operation to be visible to the outside world have been met based on the effective block parameters and effective time parameters; if the activation conditions are not met, add the cross-chain operation to the queue to be activated, wherein the queue to be activated stores all cross-chain operations that have completed the reservation of resources but have not yet been made visible to the outside world; if the activation conditions are met, the cross-chain operation is immediately made visible to the outside world, and the subsequent attempt execution receipt generation steps continue.

[0014] Preferably, the system further includes an external verification module, which is an interface component deployed on the target chain. The external verification module is configured to: extract a verification type identifier from the proof materials of the general cross-chain information data packet; distribute the proof materials to the corresponding verification adapters according to the verification type identifier to verify the validity of the general cross-chain information data packet; and unify the external proof parameters returned by the verification adapters into standardized verification results according to a preset mapping strategy.

[0015] Preferably, the shared sorting module is implemented using a decentralized blockchain, or a centralized trusted cloud service, or a hybrid architecture combining decentralized blockchain and centralized trusted cloud services.

[0016] According to a second aspect of this application, a method for concurrent processing of multi-chain transactions is provided, comprising: one or more source chain smart contract modules deployed on the source chain responding to a user-initiated cross-chain operation by constructing a corresponding sorting request data packet and sending it to a shared sorting module; the shared sorting module, in response to receiving the sorting request data packet corresponding to the cross-chain operation request, assigning a sequence number to each cross-chain operation, generating a sorting proof and a corresponding timestamp, and recording information related to the cross-chain operation in an operation log; a relay node, in response to the shared sorting module writing information related to the cross-chain operation in the operation log, preparing corresponding proof materials according to the verification mechanism of the destination chain corresponding to the cross-chain operation, assembling the information related to the cross-chain operation and the proof materials in the operation log into a general cross-chain information data packet, and delivering the general cross-chain information data packet to the destination chain; and a destination chain smart contract module deployed on one or more destination chains responding to receiving the general cross-chain information data packet. The cross-chain operation is sequentially processed using its sequence number, sorting proof, and corresponding timestamp, with reserved resources and simulated computations performed accordingly. An attempt execution receipt is generated based on the computation results, but the final state is not submitted based on these results. Relay nodes capture attempt execution receipts from each destination chain and forward them to the shared sorting module. The shared sorting module makes a global decision based on a preset decision strategy and the collected attempt execution receipts from multiple destination chain smart contract modules, generating a decision message to confirm or cancel the cross-chain operation. This decision message is then sent to the source and destination chains via relay nodes. Each destination chain smart contract module deployed on the destination chain submits its final state in response to the decision message received from the shared sorting module. Each source chain smart contract module deployed on the source chain executes the confirmation or cancellation process for the cross-chain operation in response to the decision message received from the shared sorting module.

[0017] Compared with existing technologies, the main advantages of this application are: by introducing a shared sorting module, the traditional three-party peer-to-peer architecture of "source chain-relay-destination chain" is upgraded to a multi-party multi-chain coordination architecture of "source chain-shared sorting module-relay-multiple destination chains". The shared sorting module not only establishes an authoritative global time sequence relationship for business scenarios with concurrent multi-chain transactions, but also provides centralized global decision-making capabilities, thereby supporting complex application scenarios that require multi-chain state coordination, such as price aggregation and cross-chain clearing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 is a schematic diagram of the communication mode between the source chain and the destination chain of an existing cross-chain information transmission protocol; Figure 2 is a schematic diagram of the structure of a multi-chain transaction concurrent processing system according to an embodiment of this application; Figure 3 is a flowchart of stage one and stage two of the execution process of a multi-chain transaction concurrent processing system according to an embodiment of this application; Figure 4 is a flowchart of stage three and stage four of the execution process of a multi-chain transaction concurrent processing system according to an embodiment of this application; Figure 5 is a flowchart of stage five and stage six of the execution process of a multi-chain transaction concurrent processing system according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided through specific embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0020] In research on cross-chain messaging protocols, the integration of heterogeneous blockchains is a crucial issue. Heterogeneous blockchains refer to blockchains that exhibit significant differences in their technical architecture, including consensus mechanisms (such as Proof-of-Work (PoW), Proof-of-Stake (PoS), and Byzantine Fault Tolerance (BFT), virtual machine types (such as EVM, WebAssembly WASM, and MoveVM), account models (such as UTXO versus account models), and state finality (such as probabilistic finality in Bitcoin versus deterministic finality in Tendermint). These heterogeneities lead to a series of integration problems, such as inconsistent message formats requiring custom serialization methods, incompatible verification mechanisms resulting in different proof types, and difficulties in state synchronization stemming from inconsistencies in block confirmation times and finality guarantees.

[0021] Existing cross-chain messaging protocols address the access problem of heterogeneous chains to some extent through peer-to-peer communication between the source and destination chains. As shown in Figure 1, a typical workflow includes: a user initiates a cross-chain request and triggers a corresponding event (i.e., generates a cross-chain message) in the source chain's smart contract; a relay node continuously listens to the source chain's event log, captures the cross-chain message, and prepares corresponding proof materials according to the destination chain's verification requirements (such as block headers and Merkel path proofs for light clients, aggregated signatures for multi-signature verification, etc.), then delivers the cross-chain message along with the proof materials to the destination chain; the destination chain's smart contract verifies the validity of the proof materials, confirms the authenticity of the cross-chain message source, and executes the corresponding business logic. However, considering the significant differences in interface design, security models, and implementation mechanisms among different blockchain protocols, this framework requires writing specialized adaptation code for different blockchain protocols when developing cross-chain contracts. This leads to the formation of new protocol silos in cross-chain networks built on different protocols, hindering wider multi-chain interconnection and collaborative development.

[0022] The inventors discovered in practice that existing cross-chain information transmission protocols employ a peer-to-peer bridging architecture, establishing independent channels between the source and destination chains. Each cross-chain operation is executed independently, lacking multi-chain state coordination and global decision-making capabilities, leading to technical bottlenecks in complex multi-chain scenarios. Complex multi-chain scenarios refer to business scenarios with concurrent multi-chain transactions, specifically multiple cross-chain operations occurring concurrently between multiple source and destination chains within the same business context. For example, in price feed and data aggregation scenarios, decentralized oracles need to collect and aggregate price data from multiple chains before distributing it. However, data collection from each chain is an independent cross-chain operation, lacking global timing guarantees. When price data from different chains arrives at inconsistent times, the fairness and accuracy of the aggregation results cannot be guaranteed. In cross-chain liquidation scenarios, risk position liquidation in decentralized finance protocols requires simultaneous bidding auctions across multiple chains. However, existing protocol architectures cannot provide a unified bidding mechanism; bids on different chains lack priority ranking, making it difficult to guarantee liquidation fairness and optimal execution prices. Furthermore, when some chains succeed in liquidation while others fail, global atomic rollback cannot be achieved. Furthermore, existing cross-chain messaging protocols are primarily designed based on a single relay node and do not consider multi-relay concurrent scenarios, thus limiting the system's scalability and fault tolerance. When scaling to a multi-relay node architecture to improve overall system reliability and throughput, existing protocol architectures lack secure and effective multi-relay coordination mechanisms.

[0023] In the process of in-depth research and analysis of existing technologies, the inventors realized that the key to fundamentally solving the problem of multi-chain transaction concurrency lies in breaking through the architectural limitations of existing cross-chain protocols and building a general transaction coordination framework to support multi-chain interactions. This framework provides global consistency and multi-node (multi-source chain, multi-destination chain) collaboration capabilities from the perspective of distributed systems, and provides ACID (Atomicity, Consistency, Isolation, Durability) semantic guarantees from the perspective of database transactions.

[0024] In multi-chain transaction concurrent applications, users can call one or more source chains to initiate cross-chain operations under the same business scenario. Each source chain can transmit cross-chain messages to multiple chains respectively. The inventors found that to truly realize the concurrent processing of multi-chain transactions, the following technical challenges need to be addressed: (1) Global order consistency problem. In a distributed multi-chain environment, different blockchains have their own independent timestamps and block heights. How to establish an authoritative and globally consistent order relationship for cross-chain operations? This order must not only prevent replay attacks (attackers intercept and repeatedly send legally executed cross-chain messages, causing the same operation to be executed multiple times) and double-spending problems (the same asset is reused or transferred on different chains), but also support performance scaling in high-concurrency scenarios.

[0025] (2) Atomicity guarantee problem. Cross-chain operations involve multiple independent blockchains, each with its own consensus mechanism and state machine. In this heterogeneous environment, how to achieve atomicity (i.e., the transaction characteristic of all successes or all failures, ensuring that cross-chain operations across multiple chains either all take effect or all are rolled back, with no intermediate state of partial success) guarantee? (3) Idempotency guarantee problem. In multi-relay concurrent delivery scenarios, the same cross-chain message may be delivered repeatedly by multiple relay nodes. How to avoid race conditions (i.e., unpredictable results caused by the uncertain execution order when multiple relay nodes operate on the same resource concurrently) and state conflicts caused by concurrent operations, and ensure the idempotency of cross-chain messages (meaning that no matter how many times the same cross-chain message is delivered and executed, the effect is exactly the same as executing it once, and there will be no state error due to repeated execution)? (4) Heterogeneous chain finality unification problem. Different external verification mechanisms have different security assumptions and finality characteristics. How to unify these heterogeneous finality characteristics into consistent read and write semantics? The embodiments of this application provide a multi-chain transaction concurrent processing system and method for supporting information interaction and state coordination among multiple blockchains in multi-chain transaction concurrent scenarios.

[0026] Figure 2 illustrates a schematic diagram of the architecture of a multi-chain transaction concurrent processing system according to an embodiment of this application. The system includes a source chain, a shared sorting module, one or more relay nodes, and a destination chain. The source chain, as the initiator of cross-chain operations, can be a single blockchain or multiple blockchains S1…S n It is responsible for receiving user requests, submitting sorting requests to the shared sorting module, receiving execution receipts, and updating the final state. The destination chain, as the executor of cross-chain operations, is typically one of multiple blockchains (at least one) D1…D n It is responsible for receiving cross-chain messages, executing the verification stack, reserving resources, and performing final confirmation or cancellation operations. Different destination chains can use different consensus mechanisms and virtual machine types.

[0027] The shared sorting module, as an independent sorting service, is responsible for assigning globally unique and monotonically increasing sequence numbers for cross-chain operations, generating verifiable sorting proofs, collecting execution receipts from each destination chain, and making global confirmation or cancellation decisions based on preset strategies. This shared sorting module can be implemented using a decentralized blockchain (ensuring trustlessness of sorting through a consensus protocol), a centralized trusted cloud service (utilizing high-performance infrastructure to provide low-latency services), or a hybrid architecture that seeks a balance between performance and decentralization.

[0028] Relay nodes are responsible for message forwarding and preparing supporting documentation. Multiple relay nodes (R1…R) are typically deployed. n To improve system reliability and throughput, and support concurrent delivery of the same message to the destination chain, relay nodes subscribe to operation logs from the shared sorting module, prepare corresponding supporting documentation according to the destination chain's verification mechanism, and then deliver the message and documentation to the destination chain. This multi-relay concurrency mechanism enhances the system's scalability and fault tolerance.

[0029] Furthermore, the system can flexibly select multiple external verification schemes V1…V based on the technical characteristics and security requirements of the target chain. n For example, various verification methods can be employed, such as lightweight client verification (inheriting the security of the source chain consensus), zero-knowledge proof verification (providing cryptographic finality), and threshold signature verification (based on a multi-signature mechanism of a validator network). Different target chains can adopt different verification schemes according to their own characteristics. These verification schemes can achieve unified compatibility through the standardized external verification interface designed in the embodiments of this application.

[0030] The key difference between this multi-chain transaction concurrency processing and existing technologies lies in the introduction of a shared sorting module. This upgrades the traditional "source chain-relay-destination chain" three-party peer-to-peer architecture to a "source chain-shared sorting module-relay-multiple destination chains" multi-party coordination architecture. The shared sorting module not only establishes authoritative global time-series relationships for the distributed multi-chain environment but also provides centralized decision-making and coordination capabilities. This supports complex application scenarios requiring multi-chain state coordination, such as price aggregation and cross-chain clearing, and enhances the system's scalability and fault tolerance through a multi-relay concurrency mechanism.

[0031] The execution flow of the multi-chain-based cross-chain operation processing system is described in detail below with reference to Figures 3 to 5. The execution flow mainly includes the following six stages: Stage 1: Source Chain Operation Initiation Stage As shown in Figure 3, the participating roles in this stage include the user (the initiator of the cross-chain operation), the source chain smart contract module (i.e., the source chain in Figure 3, which is responsible for receiving user requests and performing preliminary processing on-chain programs), and the shared sorting module (i.e., the shared sorting layer in Figure 3, which is an independent service component that assigns global sequence numbers to cross-chain operations).

[0032] First, the user initiates a cross-chain operation request by calling the cross-chain interface function of the source chain smart contract module and submits request parameters containing complete information. The request parameters include user identifier, destination chain identifier (i.e., the unique identifier of the destination blockchain), destination (chain) contract address (i.e., the smart contract address on the destination chain that receives cross-chain messages), business parameters, configured decision strategy (i.e., specifying the execution strategy adopted for this cross-chain operation), and timeout limit (i.e., the maximum execution time limit of the operation). Among them, business parameters can be understood as the business data required for specific cross-chain operations. Their specific content and format are determined by the application scenario. For example, in the token transfer scenario, it includes the transfer amount and token type, and in the cross-chain function call scenario, it includes the function signature and call parameters. In some embodiments, the corresponding decision strategy can be flexibly configured for cross-chain operations according to the characteristics of multi-chain application scenarios, including but not limited to: (1) Unique winner strategy: realizes competitive execution semantics, suitable for price competition applications. Typical scenarios include on-chain liquidation, which is the mechanism in decentralized finance protocols where collateral assets are liquidated through auction liquidators when the collateral ratio of a loan position is insufficient; and decentralized trading matching, which is the process by which a decentralized exchange automatically matches orders from buyers and sellers and executes transactions through smart contracts; (2) All-to-one agreement strategy: to achieve atomic execution semantics, requiring all target chains to succeed before submitting the transaction, which is suitable for strong consistency scenarios such as cross-chain governance and multi-chain asset synchronization. Specifically, "success" means that the target chain completes the resource reservation in the trial phase without conflict; "submitting the transaction" is also called submitting the final state, which means that the shared sorting module sends a decision message to confirm the cross-chain operation, and each target chain will officially enter the reserved resources; (3) Threshold agreement strategy: to achieve partial success semantics, confirming the operation of the corresponding subset when the number of successful chains reaches a preset threshold. The so-called subset refers to the part of the target chain that is successfully executed. For example, when the threshold is set to 3 / 5, the operation on the 3 chains can be confirmed if at least 3 of the 5 chains are successful. (4) Time window strategy: Dynamically collect the execution receipts returned by each target chain during the trial phase within a limited time and make a decision.

[0033] After receiving a cross-chain operation request from a user, the source chain smart contract module performs initial parameter verification. This verification process mainly includes: checking if the user is authorized to initiate the cross-chain operation; checking if the format, type, and value range of the business parameters meet the requirements; checking if the destination chain identifier is in the supported chain list (maintained by the source chain smart contract module); and checking if the destination chain contract address format is correct. Only after all verifications pass will the next step be initiated; otherwise, the request is rejected and a corresponding error message is returned.

[0034] Upon successful verification, the source chain smart contract module generates a globally unique operation identifier for this cross-chain operation. This identifier is derived through a combined hash calculation of multiple elements, including the hash value of the source chain transaction containing this cross-chain operation request, the block height of the transaction, the log sequence number of the transaction within the block, the block timestamp when the transaction was packaged, and a random value used to prevent hash collisions. The purpose of the operation identifier is to uniquely identify and track the entire lifecycle of this cross-chain operation within the entire multi-chain concurrent processing system.

[0035] Next, the channel identifier to which the cross-chain operation belongs is determined based on the source chain information and the destination chain information. In the embodiments of this application, the logical communication channel from a specific contract on the source chain to a specific contract on the destination chain is defined as a quadruple <source chain ID, source contract address, destination chain ID, destination contract address>. This logical communication channel defines the smallest scope of the sequential dependency relationship of cross-chain operation requests in multi-chain interaction scenarios. Operations within the same channel (i.e., a complete cross-chain call, including a series of steps such as request initiation from the source chain, sequence number allocation by the shared sorting module, message reception and execution on the destination chain) must be strictly serialized according to the sequence number allocated by the subsequent shared sorting module to maintain the causal consistency of state transitions. If there is no shared state dependency between different channels, their operations can be executed concurrently without violating consistency constraints. Shared state dependency refers to the possibility of read-write conflicts arising from operations on different channels accessing or modifying the same on-chain resources, such as the same account balance or the same contract state variable.

[0036] The source chain smart contract module constructs a sorting request data packet based on key fields such as operation identifier, channel identifier, business data, decision strategy, timeout time, and source chain signature. The decision strategy specifies not only the execution strategy type but also relevant parameters; for example, a threshold strategy requires specifying a specific threshold value, and a time window strategy requires specifying the window duration. The source chain signature is the digital signature of the aforementioned data by the source chain smart contract, used to prove the authenticity and integrity of the request.

[0037] Then, the source chain sends the constructed sorting request data packet to the shared sorting module through an off-chain communication mechanism. This off-chain communication mechanism refers to a method of transmitting data directly over the network without relying on blockchain transactions; it can be an oracle network, relay nodes, or other messaging services.

[0038] After receiving a sorting request data packet from one or more source chain smart contracts, the shared sorting module first verifies the source chain signature in the sorting request data packet using the public key of the corresponding source chain smart contract to confirm that the request has not been tampered with. Then, it checks whether the source chain sending the request is in the shared sorting module's authorized chain list and whether the source contract address is in the chain's whitelist. Next, it verifies whether the source chain, destination chain, and contract address are all valid, and whether the channel has been registered with the shared sorting module.

[0039] After the above verification, the shared sorting module assigns a strictly monotonically increasing sequence number to the cross-chain operation within the channel to which the sorting request packet belongs, based on the channel identifier. For example, the current maximum sequence number of the channel can be read, and 1 can be added to obtain the new sequence number. The sequence number assigned by the shared sorting module must meet the following three security properties: (1) Uniqueness: Each sequence number is uniquely assigned globally, and there are no sequence number conflicts; (2) Monotonicity: The sequence number is strictly monotonically increasing to ensure the transitivity of the partial order relationship; (3) Immutability: The assigned sequence number and its sorting proof cannot be modified or revoked afterward.

[0040] Subsequently, the shared ordering module, based on its consensus mechanism or digital signature technology, generates a publicly verifiable ordering proof for the triple of operation identifier, channel identifier, and sequence number. This ordering proof enables the source chain, destination chain, relay nodes, and third-party audit observers to independently verify the legitimacy of the sequence number allocation. If the shared ordering module is implemented as a blockchain, the ordering proof is a block header containing this information and a Merkle proof; if it is a multi-signature implementation, it is an aggregated signature of the validator set.

[0041] After generating the ordering proof, the shared ordering module records the ordering proof of the cross-chain operation, along with its generated timestamp, operation identifier, channel identifier, sequence number, decision strategy, and other information, into its persistent log. This persistent log is stored in the shared ordering module's own storage system, ensuring data integrity and availability for subsequent queries. The shared ordering module uses a hybrid logical clock, combining physical clocks and logical counters, to generate the timestamp. This timestamp can also be understood as a hybrid logical timestamp corresponding to each cross-chain operation, providing a consistent time reference for the distributed environment and facilitating timing coordination of cross-chain operations.

[0042] Finally, the shared sorting module returns a sorting confirmation message to the source chain, containing the operation identifier, sequence number, sorting proof, and timestamp. Upon receiving the sorting confirmation, the source chain smart contract records the operation's status as "pending" in its local storage, stores the sequence number, sorting proof, and timestamp for use in subsequent stages, and triggers a "sorting complete" event to notify the off-chain listening service. At this point, the source chain operation initiation phase is complete, and the cross-chain operation has obtained a globally unique sequence number and entered the delivery-pending state.

[0043] Referring to Figure 3, Phase Two: Cross-Chain Message Distribution and Delivery Phase. The participating roles in this phase include relay nodes (responsible for listening to the shared sorting module logs, preparing proof materials, and delivering cross-chain messages to the destination chain), the shared sorting module (i.e., the shared sorting layer in Figure 3, which provides operation logs for relay nodes to subscribe to), and the destination chain smart contract module (i.e., the destination chain in Figure 3, which receives cross-chain messages).

[0044] Multiple relay nodes independently subscribe to the operation log from the shared sorting module. The operation log is the persistent log recorded by the shared sorting module in Phase 1, and its content includes operation identifiers, channel identifiers, sequence numbers, sorting proofs, timestamps, decision strategies, and business data. Relay nodes obtain the operation log through the query interface or event subscription mechanism provided by the shared sorting module.

[0045] Each relay node independently prepares the corresponding external proof material according to the verification mechanism of the destination chain. For destination chains using threshold signature verification, the relay node requests signatures for the ordering proof from the validator network, collects signatures from multiple validators, and aggregates them to generate an aggregate signature as the external proof material. Here, aggregation refers to merging the individual signatures of multiple validators into a compact aggregate signature using a cryptographic algorithm, which can verify the approval of all signers at once. For destination chains using zero-knowledge proof verification, the relay node calls the prover component, inputs the ordering proof and related state data, and the prover generates a zero-knowledge proof as the external proof material, which can prove the correctness of the ordering without exposing the underlying data. For destination chains using light client verification, the relay node synchronizes the block header containing the cross-chain operation from the source chain, prepares the Merkle path proof of the operation in the source chain block, and the block header and Merkle path proof together serve as the external proof material.

[0046] Each relay node independently assembles operational information and supporting documentation into a standardized, universal cross-chain information data packet (i.e., a cross-chain message). This data packet employs a unified data structure, including sorting, control, proof, business, and metadata fields. The sorting field group contains the operation identifier, channel identifier, sequence number, and sorting proof. The control field group contains the decision strategy configuration, timeout time, and timestamp. The proof field group contains the verification type identifier, external proof data, finality level, and reorganization tolerance boundary. The verification type identifier indicates the verification method used, the external proof data is the specific supporting documentation, the finality level indicates the security level of the verification method, and the reorganization tolerance boundary indicates the maximum chain reorganization depth that the verification method can tolerate. The business field group contains business data and execution parameters. The metadata field group contains the relay node identifier, delivery timestamp, and message hash.

[0047] Multiple relay nodes concurrently deliver their respective constructed generic cross-chain information data packets to the destination chain. Each relay node independently assembles the data packet; although the packet content is largely the same, metadata fields such as the relay node identifier and delivery timestamp differ. Each relay node independently calls the receive function of the destination chain's smart contract module, submitting the data packet as a transaction parameter. The delivery operations of multiple relay nodes may overlap in time, causing the destination chain to receive multiple cross-chain messages with the same operation almost simultaneously. This multi-relay concurrent delivery design aims to improve system reliability and throughput; even if one relay node fails, other nodes can still complete the delivery.

[0048] At this point, the cross-chain message distribution and delivery phase is complete. The general cross-chain information data packet has been delivered to the destination chain and is awaiting verification and execution.

[0049] As shown in Figure 4, Phase 3: Target Chain Attempt to Execute Phase. The participating roles in this phase include the target chain smart contract module (i.e., the target chain in Figure 4, which receives and processes cross-chain messages) and the external verification module (deployed on the target chain to adapt to different verification mechanisms).

[0050] After receiving the general cross-chain information data packet, the destination chain smart contract module executes a five-layer verification mechanism in sequence. If any layer of verification fails, the message will be rejected immediately and an error will be returned.

[0051] The first layer is source verification. To address the security model issues of cross-chain verification mechanisms used by different blockchains in a multi-chain environment and achieve unified compatibility with heterogeneous external verification mechanisms, this application's embodiments design a standardized external verification interface (i.e., an external verification module), enabling upper-layer applications to flexibly select verification strategies based on security requirements. The destination chain smart contract module calls the external verification module to verify the authenticity of the cross-chain message's source. The external verification module is a unified interface component deployed on the destination chain. Its function is to distribute verification requests to the corresponding verification adapters based on the verification type identifier in the proof field group. For threshold signature verification, the adapter extracts the aggregate signature from the proof field group, verifies whether the set of verifiers corresponding to the aggregate signature is an authorized verifier of the shared sorting module, uses the public key to verify the correctness of the aggregate signature, and confirms that the data covered by the signature contains the correct operation identifier, channel identifier, and sequence number. For zero-knowledge proof verification, the adapter extracts the zero-knowledge proof from the proof field group, calls the zero-knowledge proof verifier to verify the validity of the proof, and confirms that the public input corresponding to the proof is consistent with the message content. For light client verification, the adapter extracts the source chain block header and Merkle path proof from the proof field group. It verifies the consensus proof in the block header, such as the Proof of Work (PoW) difficulty or Proof of Stake (PoS) signature, verifies the Merkle path proof confirming the operation is indeed included in the block, and checks if the block depth meets the security confirmation requirements. Then, the external verification module unifies the external proof parameters returned by the verification adapter into a normalized verification result according to a preset mapping strategy. The external verification module returns a normalized verification result, including four standardized fields: source identifier, verification type, finality level, and reorganization tolerance boundary. The source identifier field confirms the source chain and source contract address of the cross-chain message; the verification type field identifies the specific verification method used; the finality level field classifies the security characteristics of the verification method into three levels: instant, fast, or secure; and the reorganization tolerance boundary field defines the maximum chain reorganization depth that the verification method can tolerate. If verification fails, the destination chain smart contract immediately rejects the cross-chain message and logs an error. Corresponding to the verification adapter, the mapping strategies include: for cryptographically final zero-knowledge proofs, since their verification results are deterministic and require no waiting time, setting the effective time to zero achieves instant confirmation; for probabilistically final threshold signatures, due to potential fraud risks, a challenge window needs to be reserved for supervisor verification, therefore, an appropriate waiting time is set according to security requirements; for light client verification inheriting the source chain consensus, due to the need to address the potential chain reorganization risk of the source chain, the security confirmation block depth is set based on the historical data of the source chain. The light client verification mechanism and the challenges it faces require special explanation.This verification method only requires downloading and verifying the block header without synchronizing the complete block data. It confirms the authenticity of cross-chain messages by verifying the correctness of the source chain's block header and the Merkel path proof of the message, thus inheriting the security guarantees provided by the source chain's consensus mechanism. However, chain reorganization can affect the reliability of verification. Chain reorganization refers to the phenomenon where, after a temporary fork occurs due to network partitioning or consensus conflicts, the longest or highest-weighted chain is ultimately chosen as the main chain, leading to the revocation and reorganization of some confirmed blocks. To address this risk, the system sets a safe confirmation block depth, waiting for the source chain to generate several new blocks after the block containing the cross-chain message, ensuring that the probability of the block being overturned by chain reorganization is reduced to an acceptable safety threshold.

[0052] The second layer is sequence verification. To ensure the serial processing of general cross-chain information data packets according to sequence numbers, the destination chain smart contract needs to check the validity of the ordering proof and the monotonicity of the sequence numbers. If the shared ordering module is a blockchain implementation, it verifies the consensus proof containing the block header with ordering information; if the shared ordering module is a multi-signature implementation, it verifies the aggregate signature in the ordering proof. It also confirms that the signer of the ordering proof belongs to the validator set of the shared ordering module. This validator set is pre-configured by the shared ordering module, and the destination chain smart contract needs to maintain information about this set. It also needs to confirm that the data covered by the ordering proof signature contains the correct operation identifier, channel identifier, and sequence number to prevent attackers from forging the ordering proof with irrelevant valid signatures. The destination chain smart contract module maintains a state variable for each channel, specifying the "maximum processed sequence number," and checks whether the sequence number of the current cross-chain message is strictly greater than the maximum processed sequence number of that channel. If the sequence number is less than or equal to the maximum processed sequence number, it indicates that the cross-chain message is out of order or has been delivered repeatedly. The destination chain smart contract rejects the cross-chain message and records an error in the log.

[0053] The third layer is idempotency checking. To address the issue of duplicate execution that might occur when multiple relays concurrently deliver the same cross-chain operation's general cross-chain information data packet, the destination chain smart contract uses a message key mechanism to handle potential duplicate messages and ensure idempotency. The message key is a unique identifier for whether the cross-chain operation has been processed. Its function is to identify on the destination chain whether the cross-chain operation has been processed. Message keys are generated by hashing the operation identifier, channel identifier, and sequence number. The destination chain smart contract maintains a state variable called a "processed message key set," storing all message keys that have been processed. It checks if the current message key exists in this set. If the message key already exists in the processed message key set, it means that the message has been delivered and processed by a previous relay node. The destination chain smart contract directly returns the original execution result of the message, reading the previously recorded execution receipt from storage, without repeating any business logic and avoiding duplicate state modifications. If the message key does not exist in the processed message key set, it means that this is the first time the message has been processed, and the subsequent verification and execution process continues. The embodiments of this application ensure the idempotency of the operation, that is, no matter how many times the message is delivered, the execution effect is exactly the same as executing it once.

[0054] The fourth layer is the optimistic concurrency control version check. The destination chain smart contract performs version matching checks to ensure the correctness of concurrent operations. In some embodiments, each modifiable target object in a cross-chain operation maintains a monotonically increasing version number. The modifiable target object refers to the on-chain state entity that the cross-chain operation will read or modify, including data that needs to remain consistent during the operation, such as account balances, token holdings, and contract state variables. The version number acts as an incrementing counter, automatically incrementing by 1 each time the target object is successfully modified. The version number mechanism serves to detect concurrency conflicts. When multiple cross-chain operations simultaneously attempt to modify the same target object, only operations carrying the correct current version number can successfully reserve resources; other operations fail quickly due to version number mismatches. The destination chain smart contract module extracts the expected version number from the business field group. This expected version number is the version number of the target object read by the source chain when initiating the operation, indicating that the operation is based on that version. Then, it reads the current version number of the target object from the state storage and compares the expected version number with the current version number. If the version numbers are equal, it means that the target object has not been modified by other operations since the source chain read the version, and there is no concurrency conflict. At this point, a resource identifier is generated to identify the reserved resources for this operation. The resource identifier is calculated by hashing the triple of the operation identifier, target object identifier, and expected version number. Then, resource reservation information is recorded, including the operation identifier, target object identifier, expected version number, reservation timestamp, and expected modification content. A reservation status is marked on the target object to prevent other operations from modifying it before confirmation. If the version numbers are not equal, it indicates that the target object has been modified by another operation, resulting in a concurrency conflict. The target chain smart contract immediately returns a "version conflict" error and does not perform any resource reservation or state modification. This embodiment avoids the deadlock problem and performance overhead of traditional locking mechanisms.

[0055] To ensure the atomicity of cross-chain operations and address the issue of independent operation and difficulty in transaction reversal within a multi-chain heterogeneous environment, the target chain smart contract, after version checking and conflict-free execution, adopts a three-phase transaction model (Try-Confirm-Cancel, TCC) to execute cross-chain operations. This means a compensation mechanism is used at the smart contract application logic level, coordinating transactions through the TCC three-phase operation, rather than relying on underlying blockchain distributed locks or cross-chain atomic commit protocols. Specifically, after version checking and conflict-free execution, the target chain smart contract module enters the trial execution phase. In this phase (Phase Three, the trial execution phase), simulated calculations of the business logic are performed to verify whether the cross-chain operation can be successfully executed on the target chain. However, the final state is not submitted (i.e., resources are reserved, but not officially recorded or cancelled), and a trial execution receipt is assembled based on the simulation results. Subsequently (Phase Five, to be introduced later), upon receiving a decision message, if the decision message confirms the cross-chain operation, the confirmation phase begins, and the reserved resources are officially recorded; if the decision message cancels the cross-chain operation, the cancellation phase begins, and the reserved resources are released.

[0056] The fifth layer is the activation condition check. To address the fundamental differences in the definition of finality between different blockchains in a multi-chain environment due to their varying verification methods, this application proposes decoupling state changes from external visibility, combining the previously mentioned standardized external verification interface. An activation condition mechanism maps different verification methods to consistent external semantics; that is, the target chain smart contract module determines when the cross-chain operation becomes externally visible. Effective block parameters and effective time parameters are extracted from the control field group. The effective block parameters are compared with the current block height of the target chain, and the effective time parameters are compared with the current block timestamp of the target chain. Only when both conditions are met simultaneously is the activation condition considered satisfied. Here, "effective" (i.e., activation) refers to the moment when a state change changes from internal reservation to external visibility and can be read by other operations. Before assembling the execution receipt, an activation condition check is performed. During the activation condition check phase, the state exists in two forms: internal state refers to the temporary storage area within the smart contract, recording the state changes to be confirmed; external state refers to the public data seen by other contracts or users when querying through the standard interface. If the activation conditions are not met, although the cross-chain message has completed internal state reservation, it remains invisible to external reads. In this case, the operation enters the activation queue. The activation queue is a data structure maintained internally by the smart contract, storing all operations that have completed resource reservation but have not yet been activated. The destination chain smart contract returns an "activation pending" receipt to the shared sorting module and initiates a background monitoring mechanism to periodically check the operations in the activation queue. Once the activation conditions are met, activation is executed immediately. The process of switching the state to visibility is completed atomically, meaning the switch is completed once within a single block transaction. There are no partially visible intermediate states, ensuring that all subsequent reads can observe the complete state change, meaning the operation is immediately visible externally, and the subsequent receipt generation steps continue.

[0057] After the target chain smart contract module completes five layers of verification, it assembles an execution attempt receipt. This receipt includes an operation identifier, channel identifier, sequence number, resource identifier, execution result, version information, execution data, gas consumption, timestamp, and error information in case of execution failure. The execution result indicates whether the attempt was successful; possible states include success, failure, or pending activation.

[0058] The destination chain smart contract module triggers an on-chain event containing receipt information. The relay node listening for destination chain events captures this event and forwards the receipt to the shared sorting module. The shared sorting module receives and records the execution attempt receipt for that destination chain. If there are multiple destination chains, each chain executes the above process independently, generating and sending its own receipt to the shared sorting module.

[0059] At this point, the target chain's execution phase is complete. The target chain has completed resource reservation and verification, but has not yet submitted the final state modification, awaiting the global decision of the shared sorting module.

[0060] Referring to Figure 4, Phase 4: Receipt Processing and Confirmation Phase. The participating roles in this phase include the shared sorting module (i.e., the shared sorting layer in Figure 4, which collects the attempt execution receipts from each destination chain and makes a global decision), the source chain smart contract (i.e., the source chain in Figure 4, which receives the decision message and updates its local state), and the relay node (which forwards the decision message to the destination chain).

[0061] The shared sorting module receives execution acknowledgments from each destination link, and these acknowledgments are delivered via the relay node forwarding mechanism in Phase 3. The shared sorting module maintains an acknowledgment aggregation table, recording the execution status of each operation on each destination chain.

[0062] The shared sorting module makes a global decision based on the decision strategy configured in Phase 1 and the collected execution receipts from each target chain. For the unique winner strategy, the shared sorting module filters all receipts for target chains that have successfully executed and have valid resource reservations. It selects a unique winning target chain based on predefined priority rules such as highest price or earliest timestamp, and the decision is to confirm the winning target chain and cancel all other target chains. For the overall achievement strategy, the shared sorting module checks if all target chain receipts indicate successful execution. If all are successful, the decision is to confirm all target chains; if any chain fails or times out, the decision is to cancel all target chains. For the threshold achievement strategy, the shared sorting module counts the number of successfully executed target chains. If the number of successful chains reaches or exceeds a preset threshold, the decision is to confirm these successful target chains and cancel other target chains; if the number of successful chains does not reach the threshold, the decision is to cancel all target chains. For the time window strategy, the shared sorting module continuously collects receipts within the preset time window. When the time window ends, it makes a decision based on the receipts collected. It can be used in conjunction with other strategies. The destination chain that does not return a receipt within the time window is considered to have timed out and is marked as canceled.

[0063] The shared sorting module generates a decision message, which includes a decision identifier, an operation identifier, a decision type, a confirmation chain list, a cancellation chain list, a decision timestamp, and a decision signature. The decision identifier is a unique identifier for the decision, calculated by hashing the operation identifier and the decision timestamp. The decision type is either confirmation or cancellation. The confirmation chain list contains the destination chain identifiers for the cross-chain confirmation operation, and the cancellation chain list contains the destination chain identifiers for the cross-chain cancellation operation. The decision signature is the digital signature of the decision message by the shared sorting module.

[0064] The shared sorting module sends decision messages to the source chain smart contract via an off-chain communication mechanism. Upon receiving the decision message, the source chain smart contract verifies the validity of the decision signature, updates the operation's status on the source chain to "decided," and records the decision result—either confirmation or cancellation. If the decision is cancellation, the source chain also needs to release the resources reserved for this operation, such as unlocking locked tokens.

[0065] The shared sorting module sends the decision message to the relay node, which then forwards the decision message to each destination chain. At this point, the receipt processing and confirmation phase is complete, and the shared sorting module has completed the global decision and notified the source chain and each destination chain.

[0066] As shown in Figure 5, Phase 5: Final Execution Phase of the Destination Chain. The participating roles in this phase include relay nodes (forwarding decision messages to the destination chain), the destination chain smart contract module (i.e., the destination chain in Figure 5, which executes the final confirmation or cancellation of the cross-chain operation), and an optional shared sorting module (i.e., the shared sorting layer in Figure 5, which receives the final execution receipt).

[0067] After receiving the decision message from the shared sorting module, the relay node delivers the decision message to the smart contracts of each destination chain. The delivery method is similar to that in Phase Two, and multiple relay nodes may concurrently deliver the same decision message.

[0068] Upon receiving a decision message, the destination chain smart contract first verifies the decision signature in the message to confirm that the signer is an authorized verifier of the shared sorting module. Although the decision message does not involve a sequence number, the validity of the decision identifier must be verified. Next, it checks whether the decision identifier is already in the processed decision set (maintained by the destination chain smart contract module). If it has been processed, the previous execution result is returned directly to avoid duplicate execution. Then, it verifies whether the operation identifier in the decision message is consistent with the operation processed in Phase 3. Finally, it checks whether the resource identifier involved in the decision message exists in the destination chain's resource reservation record to ensure that the operation corresponding to the decision has indeed completed the resource reservation in the trial phase. If any verification fails, the destination chain smart contract rejects the decision message.

[0069] If the decision message type is confirmation and the current destination chain is in the confirmation chain list, the destination chain smart contract module executes the confirmation process. Based on the resource identifier, it searches the resource reservation record for the operation, confirming that the target object identifier, expected version number, and other information of the reserved resources match the decision message. Then, it formally applies the expected modifications recorded in the reservation to the target object's state; for example, in a token transfer scenario, it deducts the reserved transfer amount from the source account and adds the transfer amount to the target account. Next, it increments the target object's version number by 1 to indicate that the target object has been successfully modified. Advancing the version number means incrementing the version number from its current value by 1, for example, from 5 to 6, ensuring that subsequent operations are based on the new version. It clears the reservation status marker on the target object to allow other operations to access it, updates the resource reservation record's status to "confirmed," or deletes the reservation record to free up storage space. It executes the business logic associated with the state change, such as triggering a callback function or updating related states, generating a receipt containing the operation identifier, execution result (success), and final state, and triggering a "cross-chain operation completed" event for off-chain applications to subscribe to.

[0070] If the decision message type is cancellation or the current destination chain is in the cancellation chain list, the destination chain smart contract executes the cancellation process. Based on the resource identifier, it retrieves the resource information reserved for this operation from the resource reservation record and clears the reservation status marker on the target object. The version number of the target object is not modified because the target object's state has not actually changed; the version number remains the value read during the trial phase, for example, still 5 and not changing to 6. The status of the resource reservation record is updated to "cancelled" or the reservation record is deleted to release storage space. A receipt containing the operation identifier and execution result (cancellation) is generated, triggering the "Cross-chain Operation Cancellation" event.

[0071] Regardless of whether confirmation or cancellation is performed, the destination chain smart contract module must ensure the idempotency of the operation. A decision identifier is added to the state variable of the processed decision set, and the generated final execution receipt is stored in the contract storage and associated with the decision identifier. When a decision message with the same decision identifier is received again, it is delivered by another relay node, which directly reads the previously saved final receipt from storage and returns it, without repeating the confirmation or cancellation logic.

[0072] In some embodiments, the destination chain smart contract module can send the final execution receipt back to the shared sorting module for auditing and monitoring. The sending method is similar to Phase Three, achieved through triggering events and relay node forwarding.

[0073] At this point, the final execution phase of the target chain is complete, the target chain has completed the final confirmation or cancellation of the operation, and the cross-chain operation's processing flow on the target chain ends.

[0074] Referring to Figure 5, Phase Six: Source Chain Settlement and Visibility Phase. The participating roles in this phase include the source chain smart contract module (i.e., the source chain in Figure 5) that updates the final state and processes resource settlement, the shared sorting module (i.e., the shared sorting layer in Figure 5) that provides decision logs for the source chain to query, and the optional relay node that forwards the final execution receipt.

[0075] The source chain smart contract module collects final execution receipts from each destination chain through various methods, including: relay nodes monitoring events on each destination chain and forwarding the final execution receipts to the source chain; the source chain periodically querying the decision logs of the shared sorting module to obtain the final decision result of the operation; and the source chain subscribing to decision events from the shared sorting module to receive decision notifications in real time. The source chain smart contract module performs integrity and consistency verification on the collected final execution receipts. The integrity check confirms whether final execution receipts from all expected destination chains have been received. The list of expected destination chains comes from the destination chains specified by the user in Phase 1. The consistency check verifies whether the decision result in the receipt, i.e., whether the cross-chain operation or cancellation of the cross-chain operation, is consistent with the decision logs of the shared sorting module. This is achieved by querying the decision record of the operation from the shared sorting module and comparing the decision type in the receipt. The execution confirmation check verifies whether the receipts from the destination chains in the chain list indicate successful operation execution. If there are chains that should have been confirmed but failed, an anomaly is recorded.

[0076] If the shared sorting module confirms the decision, the source chain smart contract module executes the confirmation process. If there are also related target objects on the source chain that need to update their version numbers, their version numbers are incremented by 1. The relevant business status on the source chain is updated according to the business logic (business data) of the cross-chain operation; for example, in a cross-chain asset locking scenario, the asset is marked as "locked." The operation's status on the source chain is updated to "confirmed," and a receipt containing the operation identifier and final status is generated for user query. A "cross-chain operation confirmation" event is triggered to notify the user and off-chain applications.

[0077] If the shared sorting module decides to cancel, the source chain smart contract module executes the cancellation process. This involves releasing resources reserved for the operation on the source chain, such as unlocking locked tokens, updating the operation's status on the source chain to "cancelled," generating a receipt containing the operation identifier and cancellation reason, and triggering a "cross-chain operation cancellation" event.

[0078] For operations with an effective time parameter set in Phase 1, the source chain smart contract module performs delayed effective processing. Before the effective time arrives, when external read requests (other readers) query the state of the relevant target object, the source chain smart contract module returns the old state value before the operation execution. This ensures that the state change remains invisible to the outside until the activation condition is met. When the block timestamp of the target chain reaches or exceeds the set effective time, the state transition is activated. The source chain smart contract module completes the state transition atomically, that is, updating the state visibility flag once within a single block transaction. Atomicity means that the transition from invisible to visible is completed in an indivisible operation, with no partially visible intermediate states. This ensures that all subsequent read operations can immediately observe the complete state change. After the effective time arrives, all external read requests can see the new state value after the operation execution.

[0079] In some embodiments, the source chain smart contract module periodically generates system state checkpoints for fault recovery and auditing. Checkpoint content includes a checkpoint identifier (a unique identifier for the checkpoint), a hybrid logical timestamp (the global logical time at which the checkpoint was generated), a block number (the source chain block height corresponding to the checkpoint), a state tree root hash (the root hash value of the current state tree of the source chain), a version mapping (a version number mapping table for all target objects), a completed operations list (a list of all confirmed or cancelled operation identifiers), and a pending operations list (a list of all uncompleted operation identifiers). Checkpoint data is serialized and stored in an on-chain or off-chain persistent storage system. The uses of checkpoints include fault recovery (restoring the state from the most recent checkpoint when a system failure occurs), state replay (replaying operations between historical checkpoints to verify the correctness of state transitions), and audit trails (providing auditors with verifiable historical state snapshots).

[0080] In some embodiments, the source chain smart contract module can provide a snapshot read interface based on hybrid logical timestamps. Users can specify any historical timestamp to query the state of a target object at that moment. During the query, the system finds the checkpoint corresponding to the timestamp, replays the state changes after that timestamp based on the checkpoint state, and returns the consistent state at the time of the query. This interface supports historical data auditing and analysis and querying based on historical states.

[0081] At this point, the source chain settlement and visibility phase is complete, and the entire six-phase multi-chain transaction lifecycle ends. Cross-chain operations have completed final processing on the source chain and all destination chains, state changes have taken effect or been canceled, and the system is now in a state where new cross-chain operations are acceptable.

[0082] References to "various embodiments," "some embodiments," "one embodiment," or "embodiment," etc., in this specification refer to a specific feature, structure, or property described in connection with an embodiment that is included in at least one embodiment. Therefore, the appearance of the phrases "in various embodiments," "in some embodiments," "in one embodiment," or "in an embodiment," etc., throughout this specification does not necessarily refer to the same embodiment. Furthermore, specific features, structures, or properties can be combined in any suitable manner in one or more embodiments. Therefore, a specific feature, structure, or property shown or described in connection with one embodiment can be combined, in whole or in part, with features, structures, or properties of one or more other embodiments without limitation, provided that such combination is not illogical or inoperable.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments or implementation methods. Similar or identical parts between the various embodiments of this application can be referred to mutually. The implementation principles and technical effects of the inventive concept can be mutually referenced, and will not be repeated here. Where there is no conflict, the various embodiments or implementation methods in this application can be combined with each other.

[0084] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0085] This application may be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this application.

[0086] Computer-readable storage media can be tangible devices that hold and store instructions for use by an instruction execution device. Computer-readable storage media can include, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0087] The embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used in the embodiments of this application is chosen to best explain the principles, practical applications, or technological improvements in the market, or to enable other those skilled in the art to understand the embodiments disclosed in this application.

Claims

1. A concurrent processing system for multi-chain transactions, comprising: The system comprises one or more source chain smart contract modules and relay nodes deployed on the source chain, and multiple destination chain smart contract modules deployed on the destination chain, along with a shared sorting module. The shared sorting module is configured to: in response to received sorting request data packets from one or more source chain smart contract modules for their cross-chain operations, assign a sequence number to each cross-chain operation, generate a sorting proof and a corresponding timestamp, record information related to the cross-chain operation in an operation log, and make a global decision based on a preset decision strategy and collected attempt execution receipts from multiple destination chain smart contract modules to generate a decision message confirming or canceling the cross-chain operation, and send the decision message to both the source and destination chains. The attempt execution receipts are assembled from the cross-chain operations performed by the destination chain smart contract modules according to the sequence number, sorting proof, and corresponding timestamp, reserving resources and performing simulation calculations based on the calculation results. Each destination chain smart contract module is configured to: after performing the simulation calculation, not submit the final state based on the calculation results, but submit the final state based on the decision message received from the shared sorting module.

2. The system according to claim 1, wherein, Each destination chain smart contract module is also configured to: if the decision message received from the shared sorting module confirms the cross-chain operation, then the reserved resources will be officially credited; if the decision message received from the shared sorting module cancels the cross-chain operation, then the reserved resources will be released.

3. The system according to claim 1, wherein, Each source chain smart contract module is configured to receive cross-chain operation requests from one or more users, wherein each cross-chain operation request includes at least the identifier of the destination chain, the smart contract address of the destination chain, business data, and decision-making strategy; For each cross-chain operation, a corresponding operation identifier is assigned, and the channel identifier of the cross-chain operation is determined based on the identifier of the destination chain, the smart contract address of the destination chain, the identifier of the source chain, and the smart contract address on the source chain. Based on the operation identifier, channel identifier, business data, and decision strategy of the cross-chain operation, a sorting request data packet for the cross-chain operation is constructed and sent to the shared sorting module. The shared sorting module also executes a confirmation or cancellation process for the cross-chain operation in response to a decision message received from the shared sorting module. Furthermore, the shared sorting module is configured to assign a sequence number to each cross-chain operation in response to receiving a sorting request data packet, according to the following rules: 1) Each sequence number is uniquely assigned globally, with no sequence number conflicts; 2) The sequence number is strictly monotonically increasing within the same channel identifier; 3) The assigned sequence number cannot be modified or revoked afterward.

4. The system according to claim 1, wherein, The system includes one or more relay nodes, each relay node being configured to: respond to the shared sorting module writing information related to cross-chain operations into the operation log; prepare corresponding supporting materials according to the verification mechanism of the destination chain corresponding to the cross-chain operation; assemble the information related to the cross-chain operation in the operation log and the supporting materials into a general cross-chain information data packet; deliver the general cross-chain information data packet to the corresponding destination chain; capture attempt execution receipts from each destination chain and forward the attempt execution receipts to the shared sorting module; And capture decision messages from the shared sorting module and forward them to the destination chain smart contract module.

5. The system according to claim 4, wherein, Each destination chain smart contract module is also configured to: in response to receiving a general cross-chain information data packet, generate a message key corresponding to the general cross-chain information data packet based on the operation identifier, channel identifier, and sequence number of the cross-chain operation; Check whether the message key already exists in the preset set of processed message keys; If the message key already exists in the set, the general cross-chain information data packet has been processed, and the previously recorded attempt execution receipt corresponding to the general cross-chain information data packet is directly read from local storage; if the message key does not exist in the set, the subsequent execution process continues.

6. The system according to claim 5, wherein, Each target chain smart contract module is also configured to: extract the expected version number of the target object associated with the cross-chain operation from the general cross-chain information data packet; read the current version number of the target object from the local state storage; and compare whether the expected version number is equal to the current version number. If the version numbers are equal, a resource identifier is generated for the cross-chain operation to identify the reserved resource, and the reserved status is marked on the target object; If the version numbers are not equal, a version conflict error will be returned immediately without any resource reservation or status modification.

7. The system according to claim 6, wherein, Each destination chain smart contract module is also configured to: extract effective block parameters and effective time parameters from the general cross-chain information data packet before assembling the execution receipt; determine whether the activation conditions for the cross-chain operation to be visible to the outside world have been met based on the effective block parameters and effective time parameters; if the activation conditions are not met, add the cross-chain operation to the queue to be activated, wherein the queue to be activated stores all cross-chain operations that have completed the reservation of resources but have not yet been made visible to the outside world; if the activation conditions are met, the cross-chain operation is immediately made visible to the outside world, and the subsequent execution receipt generation steps continue.

8. The system according to claim 4, wherein, The system also includes an external verification module, which is an interface component deployed on the target chain. It is configured to: extract a verification type identifier from the proof materials of the general cross-chain information data packet; distribute the proof materials to the corresponding verification adapters according to the verification type identifier to verify the validity of the general cross-chain information data packet; and unify the external proof parameters returned by the verification adapters into standardized verification results according to a preset mapping strategy.

9. The system according to any one of claims 1-8, wherein, The shared sorting module can be implemented using a decentralized blockchain, a centralized trusted cloud service, or a hybrid architecture combining decentralized blockchain and centralized trusted cloud services.

10. A method for concurrent processing of multi-chain transactions, comprising: One or more source chain smart contract modules deployed on the source chain respond to the cross-chain operation initiated by the user by constructing a corresponding sorting request data packet and sending it to the shared sorting module; the shared sorting module responds to the receipt of the sorting request data packet corresponding to the cross-chain operation request by assigning a sequence number to each cross-chain operation, generating a sorting proof and a corresponding timestamp, and recording the information related to the cross-chain operation in the operation log; The relay node responds to the shared sorting module by writing information related to the cross-chain operation into the operation log, preparing corresponding proof materials according to the verification mechanism of the destination chain corresponding to the cross-chain operation, assembling the information related to the cross-chain operation and the proof materials in the operation log into a general cross-chain information data packet, and delivering the general cross-chain information data packet to the destination chain. In response to the receipt of the general cross-chain information data packet, the smart contract modules of the target chains deployed on one or more target chains perform reserved resources and simulated calculations on the cross-chain operation according to the sequence number, sorting proof, and corresponding timestamp of the cross-chain operation. Based on the calculation results, they assemble and generate an attempt execution receipt, but do not submit the final state based on the calculation results. The relay nodes capture the attempt execution receipts from each target chain and forward them to the shared sorting module. The shared sorting module makes a global decision based on a preset decision strategy and the collected attempt execution receipts from multiple target chain smart contract modules to generate a decision message to confirm or cancel the cross-chain operation, and sends the decision message to the source chain and the target chain via the relay nodes. Each destination chain smart contract module deployed on the destination chain submits the final state in response to the decision message received from the shared sorting module; each source chain smart contract module deployed on the source chain executes the confirmation or cancellation process of the cross-chain operation in response to the decision message received from the shared sorting module.

Images