A digital asset multi-chain cooperative transaction system and method based on a smart contract

Abstract

The application relates to the technical field of cross-chain transactions of blockchains, and discloses a digital asset multi-chain collaborative transaction system and method based on a smart contract. The method comprises the following steps: receiving a multi-chain transaction instruction of a user and performing analysis, generating a task description and registration; continuously detecting network connectivity and ledger synchronization height of related blockchains, and dynamically creating a candidate blockchain list according to the network connectivity and the ledger synchronization height; dynamically configuring an independent connection agent process suitable for a communication protocol of each chain in the candidate list, and initializing a memory work area of the independent connection agent process; listening to events of the corresponding chain through each agent process, triggering a to-be-executed task from a task list, generating a chain transaction request and submitting the chain transaction request to a target chain verification node; and finally updating a task state according to a response result. The method can automatically adapt to network dynamic changes, supports flexible access and reliable collaboration of heterogeneous blockchains, and improves the automation level and the execution success rate of cross-chain transactions.

Description

Technical Field

[0001] This invention relates to the field of blockchain cross-chain transaction technology, specifically to a digital asset multi-chain collaborative transaction system and method based on smart contracts. Background Technology

[0002] In the field of cross-chain digital asset transactions, existing technologies typically rely on predefined static node lists or fixed relay chain networks to execute asset transfers. The system initiates transactions based on preset paths and node information, assuming that this infrastructure is always available and the ledger state is consistent. This static configuration method cannot perceive real-time dynamic changes in the blockchain network. When preset nodes are interrupted due to network failures, congestion, or maintenance, or when there are significant delays in ledger synchronization, cross-chain transaction instructions will fail to execute smoothly, resulting in transaction failures or prolonged pauses.

[0003] Existing cross-chain systems often employ a unified protocol conversion gateway or centralized adaptation service to handle the heterogeneity of different blockchains. This architecture maps the communication protocols of multiple blockchains to a unified interface, and all chain interactions are processed through a shared public layer. This centralized processing mechanism requires modification and redeployment of core service code when faced with new blockchain types or upgrades to existing chain protocols, resulting in high system expansion and maintenance costs. Furthermore, the lack of isolation between transactions across multiple chains in a shared environment means that anomalies in one chain can affect the normal operation of other chains. Therefore, a cross-chain transaction method is needed that can automatically adapt to dynamic network changes and support flexible access and reliable collaboration of heterogeneous blockchains. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-chain collaborative trading system and method for digital assets based on smart contracts, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, this invention provides a method for multi-chain collaborative trading of digital assets based on smart contracts, the method comprising:

[0006] Receive a multi-chain transaction instruction initiated by a user terminal, which includes a digital asset identifier and a transfer path, wherein the transfer path includes at least one source blockchain and one target blockchain;

[0007] The multi-chain transaction instructions are parsed to generate cross-chain asset transfer task descriptions, which are then registered in the collaborative task list. The task status in the collaborative task list is initialized to pending execution.

[0008] Continuously probe the network connectivity and ledger synchronization height of each blockchain related to multi-chain transaction instructions, and create a list of candidate collaborative blockchains based on the probe results;

[0009] Based on the candidate collaborative blockchain list, a connection proxy process adapted to its communication protocol is dynamically configured for each candidate blockchain, and the memory working area of ​​the connection proxy process is initialized.

[0010] Each connection agent process listens to its corresponding blockchain network events, and when a preset smart contract event is detected, it extracts the description of the cross-chain asset transfer task with the status of pending execution from the collaborative task list, and generates an on-chain transaction call request carrying the digital asset identifier.

[0011] Submit the on-chain transaction call request to the verification node of the target blockchain, obtain the response result returned by the verification node, and update the status flag of the corresponding cross-chain asset transfer task description in the collaborative task list based on the response result.

[0012] Preferably, the step of parsing multi-chain transaction instructions, generating a cross-chain asset transfer task description, and registering the cross-chain asset transfer task description to the collaborative task list includes the following steps:

[0013] Extract the digital asset identifier from the multi-chain transaction instructions, and verify the legality and transferability of the digital asset identifier based on the pre-set asset registry. After verification, generate a unique task tracking code within the system.

[0014] The source blockchain network identifier and the target blockchain network identifier are separated from the flow path, and the source blockchain network identifier and the target blockchain network identifier are converted into internal communication endpoint addresses according to the preset mapping rules.

[0015] Combine task tracking codes, digital asset identifiers, internal communication endpoint addresses, and anonymous identity credentials of user terminals to generate a structured description of cross-chain asset transfer tasks.

[0016] The generated cross-chain asset transfer task description is persistently stored in a distributed collaborative task list database using the task tracking code as the primary key, and the initial execution status of the corresponding entry of the cross-chain asset transfer task description in the database is marked as pending execution.

[0017] Preferably, the continuous detection of network connectivity and ledger synchronization height of each blockchain related to multi-chain transaction instructions, and the creation of a candidate collaborative blockchain list based on the detection results, includes the following steps:

[0018] Read all internal communication endpoint addresses from the cross-chain asset transfer task description, and initiate a handshake probe request for each internal communication endpoint address, recording the response delay and the number of successful responses for the handshake probe request;

[0019] Upon receiving a successful response from the internal communication endpoint address, further query the latest block height and block generation time interval of the corresponding blockchain network, and calculate the ledger synchronization height difference of the blockchain network relative to the system reference time;

[0020] Blockchains represented by internal communication endpoint addresses that have response latency below the threshold, a number of successful responses meeting the standard, and a ledger synchronization height difference within the permitted range will be included in the temporary available list.

[0021] Based on the response latency and ledger synchronization height difference of each blockchain in the temporary availability list, a dynamic availability score is calculated. The blockchains in the temporary availability list are then sorted according to the dynamic availability scores to generate the final list of candidate collaborative blockchains.

[0022] Preferably, the step of dynamically configuring a connection proxy process adapted to its communication protocol for each candidate blockchain based on the candidate collaborative blockchain list, and initializing the memory workspace of the connection proxy process, includes the following steps:

[0023] Read the first blockchain information in the candidate collaborative blockchain list, and match the connection proxy process template corresponding to the network type and consensus mechanism of the candidate collaborative blockchain from the pre-set communication protocol library;

[0024] Based on the matched connection agent process template, instantiate a connection agent process instance with an independent process space and network stack, and allocate a logical port to the connection agent process instance.

[0025] In the memory workspace of the connection agent process instance, a message queue for caching blockchain network events is created, a buffer to be sent is created for temporarily storing on-chain transaction call requests, and a status record table for recording the running status of the connection agent process instance is created.

[0026] The blockchain information, allocated logical ports, and memory workspace structure information from the candidate collaborative blockchain list are recorded together in the global connection agent process registry.

[0027] Repeat the aforementioned matching, instantiation, logical port allocation, memory workspace initialization, and registration steps until all blockchains in the candidate collaborative blockchain list have completed the configuration of the connection agent process and the initialization of the memory workspace.

[0028] Preferably, the step of listening to the corresponding blockchain network events through each connection proxy process, and extracting the description of the cross-chain asset transfer task with the status of pending execution from the collaborative task list when a preset smart contract event is detected, and generating an on-chain transaction call request carrying the digital asset identifier, includes the following steps:

[0029] Each connection agent process establishes a long-term connection subscription channel with the public node or full node of its corresponding blockchain network through its allocated logical port, and receives new block events and log events broadcast by the corresponding blockchain network through the long-term connection subscription channel;

[0030] Within each connection proxy process, an event filter runs, which matches and filters all received block events and log events based on a preset smart contract event signature.

[0031] When the event filter captures a log event that exactly matches the preset smart contract event signature, the event processor is triggered. The event processor parses the associated task tracking code from the matched log event.

[0032] The event handler uses the parsed task tracking code as the query key to initiate a query to the collaborative task list database and obtain the description of the cross-chain asset transfer task with the status of pending execution corresponding to the task tracking code.

[0033] From the cross-chain asset transfer task description obtained from the query, extract the digital asset identifier and internal communication endpoint address, and combine them with the contract method name and parameters contained in the captured smart contract event to construct the original transaction data that conforms to the target blockchain transaction format.

[0034] The original transaction data is digitally signed using a private key paired with the target blockchain network to generate a final on-chain transaction call request that can be recognized by the target blockchain network's verification nodes.

[0035] Preferably, the step of submitting the on-chain transaction call request to the verification node of the target blockchain, obtaining the response result returned by the verification node, and updating the status flag of the corresponding cross-chain asset transfer task description in the collaborative task list based on the response result includes the following steps:

[0036] The generated on-chain transaction call request is pushed to the verification node that has established a long connection subscription channel with the connection proxy process through the pending send buffer of the connection proxy process of the corresponding target blockchain network.

[0037] Within a preset timeout period, continuously monitor responses from the verification node. These responses include one or more of the following: transaction hash, transaction receipt confirmation, transaction entry into the memory pool notification, transaction packaging into a block notification, and transaction execution failure receipt.

[0038] If a notification to package a transaction into a block is received within the timeout period, the on-chain transaction call request is deemed to have been executed successfully, and an execution result report containing the success status, block height, and transaction hash is generated.

[0039] If no response is received within the timeout period, or if a transaction execution failure receipt is received, the on-chain transaction call request is determined to have failed, and an execution result report containing the failure status and failure reason code is generated.

[0040] Based on the execution result report, an update operation is initiated to the collaborative task list database through the connection agent process, modifying the status flag of the cross-chain asset transfer task description under the corresponding task tracking code to the status recorded in the execution result report.

[0041] Preferably, calculating the ledger synchronization height difference of the blockchain network relative to the system reference time includes the following steps:

[0042] Obtain the system reference time, which is a high-precision authoritative timestamp maintained locally by the collaborative service node and synchronized through the network time protocol;

[0043] Initiate a query request to the blockchain network corresponding to the internal communication endpoint address, obtain the latest block header of the blockchain network corresponding to the internal communication endpoint address, and extract the generation timestamp and block height of the corresponding blockchain network from the latest block header;

[0044] The absolute time difference is calculated based on the generation timestamp of the latest block header and the system reference time.

[0045] Query the preset configuration information to obtain the average block time interval of the blockchain network type corresponding to the internal communication endpoint address under normal network conditions;

[0046] Divide the absolute time difference by the average block time interval to calculate a theoretical height difference in units of blocks;

[0047] Subtracting the theoretical height difference from the current latest block height of the blockchain network yields the ledger synchronization height difference of the blockchain network relative to the system reference time.

[0048] Preferably, the step of reading the first blockchain information in the candidate collaborative blockchain list and matching the connection proxy process template corresponding to the network type and consensus mechanism of the candidate collaborative blockchain from a pre-set communication protocol library includes the following steps:

[0049] Parse the first record in the candidate collaborative blockchain list and extract the blockchain network identifier encapsulated in the first record;

[0050] Based on the blockchain network identifier, a pre-set blockchain metadata registry is queried to obtain the network type description and consensus mechanism description of the blockchain. The network type description includes public chain, consortium chain or private chain, and the consensus mechanism description includes proof-of-work, proof-of-stake, proof-of-authority or variants thereof.

[0051] Using the combination of the network type description and consensus mechanism description as the query key, a search is performed in a pre-set communication protocol library. The communication protocol library stores a variety of connection proxy process templates, each template being associated with one or more combinations of network types and consensus mechanisms.

[0052] When a connection agent process template that perfectly matches the query key is retrieved, the definition file of the connection agent process template is loaded from the communication protocol library. The definition file contains the process initialization code, the list of supported message protocols, and preset configuration parameters.

[0053] If no perfectly matching connection proxy process template is found, the similarity of the combined features associated with each template in the communication protocol library is calculated based on the network type description and consensus mechanism description, and the connection proxy process template with the highest similarity is selected as the matching result for loading.

[0054] Preferably, before receiving a multi-chain transaction instruction initiated by a user terminal, the method further includes a preparatory stage, which comprises the following steps:

[0055] Configure a registry center containing information on multiple known blockchain networks. The registry center records the unique identifier, node access endpoint, native asset information, and supported smart contract standards for each known blockchain network.

[0056] Deploy a set of common smart contract templates to each known blockchain network recorded in the registry center. The smart contract templates include locking functions for locking digital assets, verification functions for verifying the eligibility of transfer rights, and execution functions for releasing or minting digital assets.

[0057] When the system starts up, it loads information about all known blockchain networks from the registry center and initializes a global blockchain network state manager based on the loaded information. The blockchain network state manager is used to periodically update the availability status of the blockchain network from the registry center.

[0058] Preferably, the present invention also includes a digital asset multi-chain collaborative trading system based on smart contracts. The system includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the digital asset multi-chain collaborative trading method based on smart contracts as described above.

[0059] Compared with the prior art, the beneficial effects of the present invention are:

[0060] By continuously monitoring the network connectivity and ledger synchronization height of each blockchain related to transaction instructions, and dynamically creating a list of candidate collaborative blockchains based on real-time monitoring results, the system eliminates reliance on statically configured nodes. Network connectivity monitoring effectively identifies unreachable chains due to network partitions, node failures, etc., while ledger synchronization height checks ensure the timeliness and consistency of node data, preventing invalid or conflicting transactions from being initiated on chains with outdated data. This allows the system to automatically select a set of currently available blockchain nodes with good data status as the basis for subsequent operations, proactively mitigating the risk of transaction failures due to reliance on unreliable nodes in a dynamically changing network environment, thus improving the automatic success rate and overall robustness of cross-chain transaction processes.

[0061] Based on a dynamically created candidate list, a connection proxy process adapted to its unique communication protocol is independently and dynamically configured for each blockchain, and an independent memory workspace for that process is initialized. Each proxy process is dedicated to communicating with a specific blockchain, and its protocol adaptation logic is customized for the interface specification of that chain, achieving seamless integration with heterogeneous blockchains. The initialization of the memory workspace provides an isolated runtime sandbox for the interaction operations of each chain, preventing resource contention and state interference between different chains. This architecture enables the system to concurrently and stably drive interactions with multiple heterogeneous blockchains through a unified management interface. When a new blockchain needs to be connected or the protocol of an existing chain needs to be upgraded, only the corresponding proxy module needs to be developed or updated, without affecting the core framework of the system, thus enhancing the scalability and maintainability of the system. Attached Figure Description

[0062] Figure 1 This is a schematic diagram illustrating the working principle of the smart contract-based multi-chain collaborative transaction method for digital assets described in this invention.

[0063] Figure 2 A flowchart describing the process of generating and registering cross-chain asset transfer tasks;

[0064] Figure 3 A flowchart for creating a list of candidate collaborative blockchains;

[0065] Figure 4 A dual-axis visualization of the performance of smart digital assets relative to the blockchain network.

[0066] Figure 5 A multi-dimensional bar chart displaying different blockchain connection agent process configuration metrics for smart digital assets. Detailed Implementation

[0067] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0068] Please see Figure 1 This invention provides a method for multi-chain collaborative transactions of digital assets based on smart contracts. The method includes: a collaborative service node receiving a multi-chain transaction instruction initiated by a user terminal. This instruction contains a unique identifier of the digital asset to be transferred and a preset transfer path, which explicitly indicates at least one source blockchain and one target blockchain involved in the asset transfer. The collaborative service node parses the multi-chain transaction instruction, converting it into an internally processable cross-chain asset transfer task description, and records this task description in a collaborative task list, while simultaneously initializing its status to pending execution. To ensure the basic communication environment for task execution, the collaborative service node continuously probes the network health status and ledger synchronization progress of each blockchain related to the multi-chain transaction instruction, and filters and creates a candidate collaborative blockchain list based on the probe results. Based on this list, the collaborative service node dynamically instantiates and configures a connection proxy process matching its communication protocol for each selected candidate blockchain, while simultaneously initializing the process's memory workspace. After each connection proxy process starts, it is responsible for listening to specific events on its corresponding blockchain network. When a preset smart contract event is triggered, the process extracts the corresponding cross-chain asset transfer task description with a pending status from the collaborative task list and generates an on-chain transaction call request carrying the digital asset identifier. The collaborative service node submits this on-chain transaction call request to the verification node of the target blockchain network. Based on the response returned by the verification node, the status flag of the corresponding cross-chain asset transfer task description in the collaborative task list is updated, thereby managing the entire cross-chain transaction process in a closed loop.

[0069] In one embodiment of the present invention, see [reference] Figure 2The collaborative service node extracts the digital asset identifier from the multi-chain transaction instructions and verifies its legality and transferability based on a pre-set asset registry. Upon successful verification, the system generates a globally unique task tracking code. The collaborative service node separates the source and target blockchain network identifiers from the transfer path information and converts these identifiers into internally identifiable communication endpoint addresses according to pre-defined mapping rules. The collaborative service node combines the generated task tracking code, digital asset identifier, converted internal communication endpoint addresses, and the user terminal's anonymous identity credentials to generate a structured cross-chain asset transfer task description. The collaborative service node persistently stores this cross-chain asset transfer task description, using the task tracking code as the primary key, in a distributed collaborative task list database and marks the initial execution status of the corresponding entry in the database as pending execution.

[0070] In practice, the collaborative service node persistently stores the generated cross-chain asset transfer task description, using the task tracking code "TASK-2023-08-001" as the primary key, in a distributed collaborative task list database. The collaborative task list database uses a key-value storage structure, storing the complete cross-chain asset transfer task description JSON object as the value. The collaborative service node marks the initial execution status of the corresponding entry in the database under the key "TASK-2023-08-001" as "PENDING," meaning pending execution. In essence, the pre-built asset registry is a centralized or decentralized service that maintains the metadata of all digital assets supported by the system. The information stored in the asset registry includes attributes such as asset identifier, asset type, original chain, contract address, and whether cross-chain transfer is supported. When the collaborative service node receives a digital asset identifier, it initiates a query request to the asset registry.

[0071] In some embodiments, the generation of a unique task tracking code within the system follows a specific algorithm. The task tracking code consists of a fixed prefix "TASK-", the current system date, and a daily incrementing sequence number. The cooperating service node maintains a global counter; each time a new code is generated, the date portion is taken from the system date, and the sequence number portion is taken from the daily increment of the counter. This encoding rule ensures the uniqueness and readability of the task tracking code in the time dimension. It can be understood that a pre-defined mapping rule defines the conversion logic from the blockchain network's public identifier to the routable communication endpoint address within the system. The mapping rule can be a pre-loaded configuration file or an online query service. The configuration file or query service stores a mapping relationship such as "ETH-Mainnet" to "chain: / / node.eth.internal:8545". The internal communication endpoint address is a Uniform Resource Identifier (URI), whose protocol header, host address, and port number indicate the specific location within the cooperating service node's internal network where the corresponding blockchain network node can be accessed.

[0072] In some embodiments, the anonymous identity credential is obtained by the user terminal from the authentication module of the collaborative service node before initiating a multi-chain transaction instruction. The authentication module uses zero-knowledge proof technology to verify the user's ownership of digital assets on the source chain. After successful verification, a one-time anonymous identity credential is issued that is not directly bound to the user's real on-chain address. Optionally, the collaborative task list database is implemented using distributed ledger technology, for example, maintaining an identical task list across multiple collaborative service node replicas using a consensus algorithm. When a collaborative service node needs to store a cross-chain asset transfer task description, it initiates a transaction to the distributed ledger network. The transaction content is a record written with "TASK-2023-08-001" as the key and a JSON object containing the cross-chain asset transfer task description as the value. This implementation gives the collaborative task list tamper-proof and highly available characteristics; even if some collaborative service node replicas fail, the task list data will not be lost.

[0073] Optionally, the structured cross-chain asset transfer task description includes a timeout timestamp field in addition to the basic fields. The timeout timestamp field is automatically calculated based on the system's preset maximum allowed execution time. The collaborative service node will periodically check the timeout timestamp in the subsequent process. If the current system time exceeds the timeout timestamp and the task status has not yet reached the final state, the collaborative service node will mark the task status as timed out and trigger the corresponding cleanup and notification process. The formula for calculating the timeout timestamp is:

[0074] T timeout =T submit +ΔT max

[0075] Wherein: T timeout T represents the timeout timestamp. submit The system timestamp representing the time the task was submitted, ΔT max The maximum allowed execution time for a task, which represents the system configuration, is a fixed time interval constant.

[0076] In one embodiment of the present invention, see [reference] Figure 3 The collaborative service node reads all internal communication endpoint addresses from the generated cross-chain asset transfer task description and initiates a handshake probe request to each address, recording the response latency and the number of successful responses for each request. The collaborative service node further queries those successfully responding internal communication endpoint addresses to obtain the latest block height and block generation time interval of their corresponding blockchain network. The collaborative service node obtains a high-precision authoritative timestamp synchronized via the network time protocol as the system reference time, and extracts the generation timestamp and block height from the latest block header obtained from the query. The collaborative service node calculates the absolute time difference between the generation timestamp of the latest block header and the system reference time, and queries the preset configuration to obtain the average block generation time interval for this blockchain network type under normal conditions. The collaborative service node divides the absolute time difference by the average block generation time interval to obtain a theoretical height difference in units of blocks. The theoretical height difference is then subtracted from the current latest block height of the blockchain network to obtain its ledger synchronization height difference relative to the system reference time. The collaborative service node includes blockchains represented by internal communication endpoint addresses with response latency below a preset threshold, a number of successful responses meeting a standard, and ledger synchronization height differences within a permitted range into a temporary available list. The collaborative service node calculates a dynamic availability score for each blockchain in the temporary available list based on its response latency and ledger synchronization height difference, and then sorts the blockchains in the list according to this score to generate the final candidate collaborative blockchain list.

[0077] The collaborative service node obtains the system reference time "2023-08-01T10:00:00Z" from a high-precision time source synchronized via the Network Time Protocol. For the Ethereum blockchain network corresponding to the internal communication endpoint address "chain: / / node.eth.internal:8545", the absolute time difference between the latest block header generation timestamp "2023-08-01T09:59:48Z" and the system reference time "2023-08-01T10:00:00Z" is calculated, and this difference is 12 seconds. Querying the pre-configured information, the average block interval of the Ethereum blockchain network as a proof-of-work network under normal network conditions is found to be 12 seconds. Dividing the absolute time difference of 12 seconds by the average block interval of 12 seconds yields a theoretical height difference of 1. Subtracting the theoretical height difference of 1 from the current latest block height of the Ethereum blockchain network (15000000) yields a ledger synchronization height difference of 14999999 relative to the system reference time. As is understandable, the calculation of the absolute time difference is based on Coordinated Universal Time (UTC). The system reference time and the block generation timestamp obtained from the blockchain network are both converted to the same time zone before a subtraction operation is performed. The absolute time difference is a positive value, representing the duration by which the latest block generation time on the blockchain network leads or lags behind the system reference time.

[0078] In some embodiments, the pre-configured configuration information exists in the form of configuration files or database tables, recording the standard average block time interval under different combinations of network types and consensus mechanisms. For example, the average block time interval for a record with a network type of "public chain" and a consensus mechanism of "proof-of-work" is "12 seconds"; the average block time interval for a record with a network type of "public chain" and a consensus mechanism of "proof-of-stake variant" is "2 seconds". The collaborative service node obtains the network type and consensus mechanism description from the blockchain metadata registry based on the queried blockchain network identifier, and then uses this as the key to query the pre-configured configuration information to obtain the corresponding average block time interval value. The collaborative service node sets a response latency threshold of 1000 milliseconds, a successful response count threshold of 3 times, and a permitted ledger synchronization height difference range of 100 blocks. The Ethereum blockchain network has been added to the temporary availability list because the average response latency of the internal communication endpoint address "chain: / / node.eth.internal:8545" is 122 milliseconds, which is below the 1000 millisecond threshold, and it has achieved 5 successful responses. The absolute difference of the ledger synchronization height difference of 14,999,999 is within the permitted range of 100. Similarly, the Polygon blockchain network has been added to the temporary availability list because the average response latency of the internal communication endpoint address "chain: / / node.polygon.internal:8545" is 50 milliseconds, which is below the 1000 millisecond threshold, and it has achieved 5 successful responses. The absolute difference of the ledger synchronization height difference of 40,000,000 is within the permitted range of 100.

[0079] The collaborative service nodes calculate their dynamic availability score based on the average response latency and the absolute value of the ledger synchronization height difference for each blockchain in the temporary availability list. For the Ethereum blockchain network, the average response latency is 122 milliseconds, and the absolute value of the ledger synchronization height difference is 1. For the Polygon blockchain network, the average response latency is 50 milliseconds, and the absolute value of the ledger synchronization height difference is 1. The collaborative service nodes calculate the dynamic availability score using the following formula:

[0080]

[0081] Where: V represents the dynamic availability score calculated for a specific blockchain network; L represents the average response latency of the blockchain network, in milliseconds; L max The maximum allowed response latency threshold preset by the system is 1000 milliseconds; |ΔH| represents the absolute value of the ledger synchronization height difference of this blockchain network; H max This represents the system's preset maximum allowed ledger synchronization height difference threshold, which is 100; W L The weighting factor for response delay in the score is set to 0.6; W HThe weighting factor for the height difference in the score is set to 0.4. The dynamic availability score V of the Ethereum blockchain network is then calculated. eth The dynamic availability score V of the Polygon blockchain network is approximately 0.85. poly It is approximately 0.92.

[0082] In some embodiments, the weighting factor W L With W H The sum of the values ​​is 1, and the specific value can be adjusted according to the priority of network stability and data timeliness. The design of the dynamic availability scoring formula allows blockchain networks with lower response latency and smaller ledger synchronization height differences to obtain higher scores. The scoring results are normalized to the range of 0 to 1 for easy comparison and ranking. The collaborative service nodes sort the blockchains in the temporary availability list in descending order according to the dynamic availability score. The Polygon blockchain network score of 0.92 is higher than the Ethereum blockchain network score of 0.85. The collaborative service nodes generate the final candidate collaborative blockchain list, which is an ordered list. The first record is the Polygon blockchain network and its related information, and the second record is the Ethereum blockchain network and its related information.

[0083] In one embodiment of the present invention, the collaborative service node reads the first record in the candidate collaborative blockchain list and extracts the encapsulated blockchain network identifier. The collaborative service node queries a pre-set blockchain metadata registry based on this blockchain network identifier to obtain its network type description and consensus mechanism description. The collaborative service node uses the combination of the obtained network type description and consensus mechanism description as a query key to search a pre-set communication protocol library, which stores various connection proxy process templates and their associated network and consensus combination features. When a template that perfectly matches the query key is found, the collaborative service node loads the definition file of that connection proxy process template from the library; if no perfectly matching template is found, the similarity to the associated combination features of each template in the library is calculated, and the template with the highest similarity is selected as the matching result for loading. Based on the matched connection proxy process template, the collaborative service node instantiates a connection proxy process instance with an independent process space and network stack, and allocates a logical port to this instance. In the memory working area of ​​this connection proxy process instance, the collaborative service node creates a message queue for caching blockchain network events, a buffer for temporarily storing on-chain transaction call requests, and a status record table for recording the process's running status. The collaborative service node records the information of the current candidate blockchain, the allocated logical port, and the memory workspace structure information into the global connection agent process registry. The collaborative service node repeats the aforementioned reading, matching, instantiation, initialization, and registration steps until all blockchains in the candidate collaborative blockchain list have completed the configuration of the connection agent process and the initialization of the memory workspace.

[0084] In practice, if no connection proxy process template matching the query key is found in the communication protocol library, the collaborative service node calculates the similarity of the combined features associated with each template in the communication protocol library based on the network type description and consensus mechanism description. The collaborative service node treats the network type description and consensus mechanism description as a feature set composed of words. For each connection proxy process template in the communication protocol library, the collaborative service node also extracts its associated network type and consensus mechanism description and converts them into a feature set. The collaborative service node calculates the Jaccard similarity coefficient between the query feature set and the template feature set, and selects the connection proxy process template with the highest similarity as the matching result for loading. The formula for calculating the Jaccard similarity coefficient is:

[0085]

[0086] Where: S represents the similarity coefficient; A represents the feature set consisting of the network type and consensus mechanism description obtained from the first record in the candidate collaborative blockchain list; B represents the feature set consisting of the network type and consensus mechanism description associated with a connection proxy process template in the communication protocol library; |A∩B| represents the number of elements in the intersection of feature set A and feature set B; |A∪B| represents the number of elements in the union of feature set A and feature set B.

[0087] The collaborative service node reads the next record in the candidate collaborative blockchain list, namely the second record, which encapsulates the blockchain network identifier "ETH-Mainnet". Based on the blockchain network identifier "ETH-Mainnet", the collaborative service node queries the pre-built blockchain metadata registry to obtain the network type description of the "ETH-Mainnet" blockchain as "public chain" and the consensus mechanism description as "proof-of-work". Using the combination of "public chain" and "proof-of-work" as the query key, the collaborative service node retrieves and loads a fully matching connection proxy process template from the communication protocol library. Based on this template, the collaborative service node instantiates a second connection proxy process instance, assigns it a logical port "51002", and creates a message queue named "EventQueue_ETH", a pending-send buffer named "TxBuffer_ETH", and a status record table in the second connection proxy process instance's memory workspace. The collaborative service node registers the information about the Ethereum blockchain, the logical port "51002", and the memory workspace structure information of the second connection proxy process instance as another new record in the global connection proxy process registry.

[0088] The communication protocol library is essentially a repository storing various adaptable components. Each connection broker process template defines the minimum set of protocols, encoding / decoding methods, and connection management logic required to communicate with a specific type of blockchain network. The template definition file can be a script file, an executable program snippet, or a configuration descriptor. Loading the definition file means that the coordinating service node reads the template's code or configuration into memory, ready for subsequent process instantiation. In some embodiments, the allocated logical port is a virtual port number valid only within the namespace of the coordinating service node's internal network or container network, not a physical port on the host. Logical ports are used for network isolation and addressing between different connection broker process instances within the coordinating service node, ensuring that each connection broker process instance listens to an independent network endpoint and avoids port conflicts. The allocation strategy for logical ports can be sequential incrementing or selection from a predefined, unoccupied port pool.

[0089] In one embodiment of the present invention, each initialized connection proxy process establishes a long-term connection subscription channel with the public or full node of the corresponding blockchain network through its assigned logical port, and receives new block events and log events broadcast by the blockchain network through this channel. An event filter runs within each connection proxy process, which matches and filters all received block events and log events based on a preset smart contract event signature. When the event filter identifies a log event that perfectly matches the preset smart contract event signature, it triggers an internal event processor. The event processor parses the associated task tracking code from the matching log event. Using the parsed task tracking code as a query key, the event processor queries the collaborative task list database to obtain the description of the cross-chain asset transfer task corresponding to the code and whose status is pending execution. The event processor extracts the digital asset identifier and internal communication endpoint address from the obtained cross-chain asset transfer task description, and combines this with the contract method name and parameters contained in the captured smart contract event to construct raw transaction data conforming to the target blockchain transaction format. The event handler uses a private key paired with the target blockchain network to digitally sign the original transaction data, generating a final on-chain transaction call request that can be recognized by the target blockchain network's verification nodes.

[0090] In implementation, the connection proxy process corresponding to the Polygon blockchain network establishes a long-lived subscription channel with a public node of the Polygon blockchain network through its assigned logical port "51001". The connection proxy process receives new block events and log events broadcast by the Polygon blockchain network through this long-lived subscription channel. Similarly, the connection proxy process corresponding to the Ethereum blockchain network establishes a long-lived subscription channel with a full node of the Ethereum blockchain network through its assigned logical port "51002". The connection proxy process also receives new block events and log events broadcast by the Ethereum blockchain network through this long-lived subscription channel. See Table 1.

[0091] Table 1: Smart Contract Event Signature and Listening Topic Mapping Table

[0092] Event Name Event signature Subscribe to topics Asset Lock-in AssetLocked(bytes32,address,uint256) 0x8bea... Verification complete VerificationDone(bytes32,bytes) 0xa1b2... Casting completed MintCompleted(bytes32,address,uint256) 0xc3d4...

[0093] As is understandable, long-connection subscription channels are typically implemented based on the WebSocket protocol or persistent remote procedure call connections on a specific blockchain network. The connection broker process declares its interest in specific types of events, such as new block events or log events for specific contract addresses, by sending subscription requests to blockchain nodes. Once the subscription is established, the blockchain node will proactively push event data to the connection broker process through this long connection when the corresponding event occurs, avoiding the inefficient behavior of the connection broker process constantly polling.

[0094] The event processor digitally signs the original transaction data using a private key paired with the Polygon blockchain network. The digital signing process involves calculating a hash of the original transaction data and then signing the hash value using an elliptic curve digital signature algorithm and the private key. The event processor generates a final on-chain transaction invocation request that can be recognized by the Polygon blockchain network's validator nodes. This on-chain transaction invocation request is a complete signed transaction object containing the original transaction data fields and the digital signature result.

[0095] In some embodiments, contract method calls need to be encoded when constructing raw transaction data. The encoding process follows the application binary interface specification of the target blockchain network, concatenating and hexadecimal encoding the method selector "mintCrossChainAsset" and its parameters. The encoded data serves as the data field value of the transaction object. The formula for application binary interface encoding can be expressed as:

[0096] D=S‖P1‖P2‖…‖P n

[0097] Where: D represents the final generated encoded data; S represents the 4-byte function selector hash value calculated from the target function prototype; || represents the concatenation operator; P1, P2, ..., Pn This represents the values ​​of each parameter after they have been formatted according to the application's binary interface encoding rules.

[0098] See Figure 4 This is a dual-axis visualization of blockchain network performance for smart digital assets. Latency and availability scores show a negative correlation: blockchains with lower latency have higher availability scores. BSC performs best overall, while Ethereum and Solana have higher latency and relatively lower availability scores. This type of chart is commonly used in blockchain network candidate selection scenarios, helping engineers quickly assess the connection stability and availability of different chains, providing data support for network selection in cross-chain transactions. Long-term tracking of the chart's metrics can assess chain performance fluctuations, providing a basis for subsequent blockchain network integration or phase-out.

[0099] In one embodiment of the invention, during the preparatory phase before the system receives user instructions, a registry center containing information on multiple known blockchain networks is configured. This registry center records the unique identifier, node access endpoint, native asset information, and supported smart contract standards for each blockchain network. During the preparatory phase, a set of generic smart contract templates is deployed on each known blockchain network recorded in the registry center. These templates include locking functions for locking digital assets, verification functions for verifying transfer eligibility, and execution functions for releasing or minting digital assets. Upon system startup, information on all known blockchain networks is loaded from the registry center, and a global blockchain network state manager is initialized based on this information. This manager is used to periodically update the availability status of the blockchain networks from the registry center.

[0100] The collaborative service node pushes the generated on-chain transaction call request to the verification node that has established a long-term connection subscription channel with the corresponding target blockchain network's connection proxy process through the pending send buffer. Within a preset timeout period, the collaborative service node continuously listens for responses from the verification node. If a transaction is packaged into a block notification within the timeout period, the on-chain transaction call request is considered successful, and the collaborative service node generates an execution result report containing the success status, block height, and transaction hash. If no response is received within the timeout period, or a transaction execution failure receipt is received, the on-chain transaction call request is considered to have failed, and the collaborative service node generates an execution result report containing the failure status and failure reason code. Based on the execution result report, the collaborative service node initiates an update operation to the collaborative task list database through the corresponding connection proxy process, modifying the status flag of the cross-chain asset transfer task description under the corresponding task tracking code to the status recorded in the execution result report.

[0101] In practice, the collaborative service node pushes the generated on-chain transaction call request through the pending-send buffer of the connection proxy process of the corresponding target blockchain network to the validator node that has established a long-term connection subscription channel with the connection proxy process. The target validator node address for the on-chain transaction call request is "https: / / polygon-validator.example.com". The collaborative service node continuously listens for responses from the validator node within a preset timeout period, which is set to 90 seconds. If a transaction is packaged into a block notification within the timeout period, the collaborative service node determines that the on-chain transaction call request has been successfully executed and generates an execution result report containing the success status, block height, and transaction hash. The execution result report is represented as a structured data object. If no response is received within the timeout period, or a transaction execution failure receipt is received, the collaborative service node determines that the on-chain transaction call request has failed and generates an execution result report containing the failure status and failure reason code.

[0102] In some embodiments, the preset timeout period is dynamically calculated based on the historical average block time of the target blockchain network, and the calculation formula involves the real-time network congestion coefficient. Timeout Period The calculation formula is:

[0103]

[0104] in: This represents the total timeout threshold set for monitoring this response; B avg N represents the average block time interval of the target blockchain network over the most recent 100 blocks, obtained from the blockchain network state manager; confirm This represents the required number of transaction confirmation blocks for the system configuration, typically set to 1; C congestion This represents the network congestion coefficient obtained in real time from the target blockchain network; its value is the ratio of the current number of pending transactions to the basic capacity. For example, calculating B... avg =2 seconds, N confirm =1, C congestion =0.5, then Second.

[0105] See Figure 5This is a multi-dimensional bar chart showcasing the configuration metrics of proxy processes for different blockchains in smart digital assets. For Ethereum, more system resources need to be allocated; for Solana, resource consumption can be appropriately reduced to improve overall system resource utilization. Ethereum's large queues make it more suitable for high-concurrency cross-chain event scenarios, while Solana's small queues may require optimized buffering strategies to avoid event overflow. The differences in proxy process configurations across different chains can serve as a reference for subsequent process template optimization and chain compatibility assessment. This chart primarily serves the deployment and resource scheduling of proxy processes in multi-chain collaborative transaction systems, helping technical personnel accurately match system resources with blockchain characteristics to improve process efficiency and stability.

[0106] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0107] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for multi-chain collaborative trading of digital assets based on smart contracts, characterized in that, The method includes: Receive a multi-chain transaction instruction initiated by a user terminal, which includes a digital asset identifier and a transfer path, wherein the transfer path includes at least one source blockchain and one target blockchain; The multi-chain transaction instructions are parsed to generate cross-chain asset transfer task descriptions, which are then registered in the collaborative task list. The task status in the collaborative task list is initialized to pending execution. Continuously probe the network connectivity and ledger synchronization height of each blockchain related to multi-chain transaction instructions, and create a list of candidate collaborative blockchains based on the probe results; Based on the list of candidate collaborative blockchains, a connection proxy process adapted to its communication protocol is dynamically configured for each candidate collaborative blockchain, and the memory working area of ​​the connection proxy process is initialized. Each connection agent process listens to its corresponding blockchain network events, and when a preset smart contract event is detected, it extracts the description of the cross-chain asset transfer task with the status of pending execution from the collaborative task list, and generates an on-chain transaction call request carrying the digital asset identifier. Submit the on-chain transaction call request to the verification node of the target blockchain, obtain the response result returned by the verification node, and update the status flag of the corresponding cross-chain asset transfer task description in the collaborative task list based on the response result.

2. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 1, characterized in that, The process of parsing multi-chain transaction instructions, generating cross-chain asset transfer task descriptions, and registering these descriptions in the collaborative task list includes the following steps: Extract the digital asset identifier from the multi-chain transaction instructions, and verify the legality and transferability of the digital asset identifier based on the pre-set asset registry. After verification, generate a unique task tracking code within the system. The source blockchain network identifier and the target blockchain network identifier are separated from the flow path, and the source blockchain network identifier and the target blockchain network identifier are converted into internal communication endpoint addresses according to the preset mapping rules. Combine task tracking codes, digital asset identifiers, internal communication endpoint addresses, and anonymous identity credentials of user terminals to generate a structured description of cross-chain asset transfer tasks. The generated cross-chain asset transfer task description is persistently stored in a distributed collaborative task list database using the task tracking code as the primary key, and the initial execution status of the corresponding entry of the cross-chain asset transfer task description in the database is marked as pending execution.

3. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 1, characterized in that, The continuous detection of network connectivity and ledger synchronization height of each blockchain related to multi-chain transaction instructions, and the creation of a candidate collaborative blockchain list based on the detection results, includes the following steps: Read all internal communication endpoint addresses from the cross-chain asset transfer task description, and initiate a handshake probe request for each internal communication endpoint address, recording the response delay and the number of successful responses for the handshake probe request; Upon receiving a successful response from the internal communication endpoint address, further query the latest block height and block generation time interval of the corresponding blockchain network, and calculate the ledger synchronization height difference of the blockchain network relative to the system reference time; Blockchains represented by internal communication endpoint addresses that have response latency below the threshold, a number of successful responses meeting the standard, and a ledger synchronization height difference within the permitted range will be included in the temporary available list. Based on the response latency and ledger synchronization height difference of each blockchain in the temporary availability list, a dynamic availability score is calculated. The blockchains in the temporary availability list are then sorted according to the dynamic availability scores to generate the final list of candidate collaborative blockchains.

4. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 3, characterized in that, The step of dynamically configuring a connection proxy process adapted to its communication protocol for each candidate collaborative blockchain based on the candidate collaborative blockchain list, and initializing the memory workspace of the connection proxy process, includes the following steps: Read the first blockchain information in the candidate collaborative blockchain list, and match the connection proxy process template corresponding to the network type and consensus mechanism of the candidate collaborative blockchain from the pre-set communication protocol library; Based on the matched connection agent process template, instantiate a connection agent process instance with an independent process space and network stack, and allocate a logical port to the connection agent process instance. In the memory workspace of the connection agent process instance, a message queue for caching blockchain network events is created, a buffer to be sent is created for temporarily storing on-chain transaction call requests, and a status record table for recording the running status of the connection agent process instance is created. The blockchain information, allocated logical ports, and memory workspace structure information from the candidate collaborative blockchain list are recorded together in the global connection agent process registry. Repeat the aforementioned matching, instantiation, logical port allocation, memory workspace initialization, and registration steps until all blockchains in the candidate collaborative blockchain list have completed the configuration of the connection agent process and the initialization of the memory workspace.

5. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 4, characterized in that, The process of listening to the corresponding blockchain network events through each connection proxy process, and extracting the description of cross-chain asset transfer tasks with a pending status from the collaborative task list when a preset smart contract event is detected, and generating an on-chain transaction call request carrying the digital asset identifier, includes the following steps: Each connection agent process establishes a long-term connection subscription channel with the public node or full node of its corresponding blockchain network through its allocated logical port, and receives new block events and log events broadcast by the corresponding blockchain network through the long-term connection subscription channel; Within each connection proxy process, an event filter runs, which matches and filters all received block events and log events based on a preset smart contract event signature. When the event filter captures a log event that exactly matches the preset smart contract event signature, the event processor is triggered. The event processor parses the associated task tracking code from the matched log event. The event handler uses the parsed task tracking code as the query key to initiate a query to the collaborative task list database and obtain the description of the cross-chain asset transfer task with the status of pending execution corresponding to the task tracking code. From the cross-chain asset transfer task description obtained from the query, extract the digital asset identifier and internal communication endpoint address, and combine them with the contract method name and parameters contained in the captured smart contract event to construct the original transaction data that conforms to the target blockchain transaction format. The original transaction data is digitally signed using a private key paired with the target blockchain network to generate a final on-chain transaction call request that can be recognized by the target blockchain network's verification nodes.

6. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 5, characterized in that, The process of submitting an on-chain transaction call request to a verification node of the target blockchain, obtaining the response returned by the verification node, and updating the status flag of the corresponding cross-chain asset transfer task description in the collaborative task list based on the response result includes the following steps: The generated on-chain transaction call request is pushed to the verification node that has established a long connection subscription channel with the connection proxy process through the pending send buffer of the connection proxy process of the corresponding target blockchain network. Within a preset timeout period, continuously monitor the response results from the verification node. The response results include one or more of the following: transaction hash, transaction receipt confirmation, transaction entering the memory pool notification, transaction being packaged into a block notification, and transaction execution failure receipt. If a notification to package a transaction into a block is received within the timeout period, the on-chain transaction call request is deemed to have been executed successfully, and an execution result report containing the success status, block height, and transaction hash is generated. If no response is received within the timeout period, or if a transaction execution failure receipt is received, the on-chain transaction call request is deemed to have failed, and an execution result report containing the failure status and failure reason code is generated. Based on the execution result report, an update operation is initiated to the collaborative task list database through the connection agent process, modifying the status flag of the cross-chain asset transfer task description under the corresponding task tracking code to the status recorded in the execution result report.

7. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 3, characterized in that, The calculation of the ledger synchronization height difference of the blockchain network relative to the system reference time includes the following steps: Obtain the system reference time, which is a high-precision authoritative timestamp maintained locally by the collaborative service node and synchronized through the network time protocol; Initiate a query request to the blockchain network corresponding to the internal communication endpoint address, obtain the latest block header of the blockchain network corresponding to the internal communication endpoint address, and extract the generation timestamp and block height of the corresponding blockchain network from the latest block header; The absolute time difference is calculated based on the generation timestamp of the latest block header and the system reference time. Query the preset configuration information to obtain the average block time interval of the blockchain network type corresponding to the internal communication endpoint address under normal network conditions; Divide the absolute time difference by the average block time interval to calculate a theoretical height difference in units of blocks; Subtracting the theoretical height difference from the current latest block height of the blockchain network yields the ledger synchronization height difference of the blockchain network relative to the system reference time.

8. The method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 4, characterized in that, The step of reading the first blockchain information in the candidate collaborative blockchain list and matching the connection proxy process template corresponding to the network type and consensus mechanism of the candidate collaborative blockchain from a pre-set communication protocol library includes the following steps: Parse the first record in the candidate collaborative blockchain list and extract the blockchain network identifier encapsulated in the first record; Based on the blockchain network identifier, a pre-set blockchain metadata registry is queried to obtain the network type description and consensus mechanism description of the blockchain. The network type description includes public chain, consortium chain or private chain, and the consensus mechanism description includes proof-of-work, proof-of-stake, proof-of-authority or variants thereof. Using the combination of the network type description and consensus mechanism description as the query key, a search is performed in a pre-set communication protocol library. The communication protocol library stores a variety of connection proxy process templates, each template being associated with one or more combinations of network types and consensus mechanisms. When a connection agent process template that perfectly matches the query key is retrieved, the definition file of the connection agent process template is loaded from the communication protocol library. The definition file contains the process initialization code, the list of supported message protocols, and preset configuration parameters. If no perfectly matching connection proxy process template is found, the similarity of the combined features associated with each template in the communication protocol library is calculated based on the network type description and consensus mechanism description, and the connection proxy process template with the highest similarity is selected as the matching result for loading.

9. A method for multi-chain collaborative trading of digital assets based on smart contracts according to claim 1, characterized in that, Before receiving multi-chain transaction instructions initiated by the user terminal, the method also includes a preparatory stage, which comprises the following steps: Configure a registry center containing information on multiple known blockchain networks. The registry center records the unique identifier, node access endpoint, native asset information, and supported smart contract standards for each known blockchain network. Deploy a set of common smart contract templates to each known blockchain network recorded in the registry center. The smart contract templates include locking functions for locking digital assets, verification functions for verifying the eligibility of transfer rights, and execution functions for releasing or minting digital assets. When the system starts up, it loads information about all known blockchain networks from the registry center and initializes a global blockchain network state manager based on the loaded information. The blockchain network state manager is used to periodically update the availability status of the blockchain network from the registry center.

10. A multi-chain collaborative trading system for digital assets based on smart contracts, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for multi-chain collaborative trading of digital assets based on smart contracts as described in any one of claims 1 to 9.

Images