Cross-chain transaction method, device, equipment, medium and product

Abstract

The invention discloses a cross-chain transaction method, device and equipment, a medium and a product, and relates to the technical field of block chains. The method comprises the following steps: detecting and obtaining a revocation instruction sent by an initiator on a target chain; the revocation instruction comprises session identification information of a transaction session of the cross-chain transaction, a revocation random number and a revocation signature; calling a target hash time lock contract of the target chain to verify the revocation instruction to obtain a verification result; and if the verification result is successful, calling a target Hash time lock contract, updating the session state of the transaction session to a revocation state, and setting the transaction state of the first transaction object to an unlocking state. According to the technical scheme, the compliance of cross-chain transactions, the business flexibility and the applicability in the aspect of exception handling capability can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a cross-chain transaction method, device, equipment, medium and product. BACKGROUND

[0002] The existing cross-chain transaction usually relies on third-party relay, hosting service or cross-chain bridge protocol to realize asset mapping and exchange, but these schemes generally have the following shortcomings: first, the cross-chain process lacks atomicity, once the transaction is interrupted or one-party default occurs, it may cause one-way release or permanent freezing of assets, thereby threatening transaction security; second, most schemes still rely on third-party trust mechanism, which requires relay nodes or hosting parties to control asset accounts, which goes against the core concept of decentralization of blockchain. The traditional hash time lock contract requires the recipient to reveal an original image within a specified time to unlock the funds, otherwise the funds will be returned to the sender. Although this mechanism is secure, it lacks flexibility because the funds cannot be unlocked in advance before the time expires. SUMMARY

[0003] The present application provides a cross-chain transaction method, device, equipment, medium and product to solve the problems of insufficient flexibility and low transaction efficiency of cross-chain transaction.

[0004] According to one aspect of the present application, a cross-chain transaction method is provided, applied to a recipient, the method comprising:

[0005] detecting and acquiring a revocation instruction sent by an initiator on a target chain; the revocation instruction comprising session identification information of a transaction session of a cross-chain transaction, a revocation random number and a revocation signature;

[0006] calling a target hash time lock contract of the target chain to verify the revocation instruction, obtaining a verification result;

[0007] if the verification result is passed, calling the target hash time lock contract to update the session state of the transaction session to a revocation state, and setting the transaction state of the first transaction object to an unlocked state.

[0008] According to another aspect of the present application, a cross-chain transaction method is provided, applied to an initiator, the method comprising:

[0009] generating a first original image and a revocation random number of a cross-chain transaction;

[0010] when the first original image is not detected in a blockchain network, and the transaction session of the cross-chain transaction is in a locked state, initiating a revocation transaction request for the cross-chain transaction on a source chain;

[0011] determining a third revocation digest based on the session identification information of the transaction session and the revocation random number;

[0012] sign the third revocation digest using a private key to generate a revocation signature;

[0013] generate a revocation instruction based on the revocation signature, the session identification information, and the revocation random number;

[0014] send the revocation instruction to a target chain through a cross-chain gateway to enable a receiver to execute a revocation process for the cross-chain transaction on the target chain.

[0015] According to another aspect of the present application, a cross-chain transaction device configured at a receiver is provided, and the device comprises:

[0016] an instruction acquisition module configured to detect and acquire a revocation instruction sent by an initiator on a target chain; the revocation instruction comprising session identification information of a transaction session of a cross-chain transaction, a revocation random number, and a revocation signature;

[0017] an instruction verification module configured to call a target hash time lock contract of the target chain to verify the revocation instruction and obtain a verification result;

[0018] a revocation execution module configured to, if the verification result is passed, call the target hash time lock contract to update a session state of the transaction session to a revoked state and set a transaction state of a first transaction object to an unlocked state.

[0019] According to another aspect of the present application, a cross-chain transaction device configured at an initiator is provided, and the device comprises:

[0020] a data generation module configured to generate a first original image of a cross-chain transaction and a revocation random number;

[0021] a request initiation module configured to initiate a revocation transaction request for the cross-chain transaction on a source chain when the first original image is not detected in a blockchain network and a session state of a transaction session of the cross-chain transaction is a locked state;

[0022] an abstract determination module configured to determine a third revocation abstract based on session identification information of the transaction session and the revocation random number;

[0023] a signature generation module configured to sign the third revocation abstract using a private key to generate a revocation signature;

[0024] an instruction generation module configured to generate a revocation instruction based on the revocation signature, the session identification information, and the revocation random number;

[0025] an instruction sending module configured to send the revocation instruction to a target chain through a cross-chain gateway to enable a receiver to execute a revocation process for the cross-chain transaction on the target chain.

[0026] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0027] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cross-chain transaction method according to any embodiment of the present invention.

[0028] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the cross-chain transaction method described in any embodiment of the present invention.

[0029] According to another aspect of the present invention, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the cross-chain transaction method as described in any embodiment of the present invention.

[0030] In this embodiment of the invention, the revocation instruction includes session identifier information, a revocation random number, and a revocation signature. The recipient needs to call the target hash time lock contract of the target chain to complete the verification. The verification logic based on the contract ensures the authenticity and legality of the revocation instruction, improving the security and reliability of the cross-chain transaction revocation process. When the initiator initiates revocation due to changes in transaction conditions, on-chain failures, or other reasons, the recipient can respond quickly and complete subsequent processing, avoiding liquidity loss caused by long-term asset locking, and improving the fault tolerance and scenario adaptability of cross-chain transactions. The steps of revocation instruction verification, session state update, and asset unlocking are all completed by calling the target hash time lock contract, without any manual intervention. By utilizing the automation and programmability of smart contracts, human error in the cross-chain transaction revocation process is reduced, and the overall execution efficiency of cross-chain transactions is improved.

[0031] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1This is a flowchart of a cross-chain transaction method provided in an embodiment of the present invention;

[0034] Figure 2 This is a flowchart of another cross-chain transaction method provided by an embodiment of the present invention;

[0035] Figure 3 This is a flowchart of another cross-chain transaction method provided by an embodiment of the present invention;

[0036] Figure 4 This is a schematic diagram of the structure of a cross-chain transaction device provided in an embodiment of the present invention;

[0037] Figure 5 This is a schematic diagram of another cross-chain transaction device provided in an embodiment of the present invention;

[0038] Figure 6 This is a schematic diagram of the structure of an electronic device that implements the cross-chain transaction method of this invention. Detailed Implementation

[0039] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0040] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0041] Furthermore, it should be noted that the information collected in the technical solution of this invention is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of related data all comply with the relevant laws, regulations and standards of relevant countries and regions, necessary confidentiality measures have been taken, and public order and good morals are not violated. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0042] Figure 1 This is a flowchart of a cross-chain transaction method provided by an embodiment of the present invention. This embodiment is applicable to cross-chain transactions, especially object transactions between different blockchains. The method is applied to the receiving party and can be executed by a cross-chain transaction device. This device can be implemented in hardware and / or software and can be configured in an electronic device with corresponding data processing capabilities, such as a server. Figure 1 As shown, the method includes:

[0043] S110. Detect and obtain the revocation instruction sent by the initiator on the target chain; the revocation instruction includes the session identifier information of the cross-chain transaction session, the revocation random number, and the revocation signature.

[0044] In this context, the target chain is the blockchain network where the recipient resides. The recipient is responsible for detecting, acquiring, and verifying the revocation instruction; the recipient is the executing entity for the session revocation operation. The target chain can be used to receive and process revocation instructions. The initiator is the entity that generates the revocation instruction. The revocation instruction refers to the data instruction actively submitted by the initiator on the source chain to terminate the cross-chain transaction. The source chain is the blockchain network where the initiator resides. A cross-chain transaction refers to the interaction of assets or data involving different blockchain networks; in a cross-chain transaction, the two parties (the recipient and the initiator) belong to different blockchain networks. A transaction session is a logical interaction link established to complete a cross-chain transaction and spans the entire transaction process. Session identification information is data used to uniquely identify the transaction session. The revocation random number is a random value generated by the initiator for revoking the transaction. The revocation signature is data obtained by digitally signing the associated data of the revocation transaction.

[0045] Specifically, the receiver listens for on-chain instructions related to itself on the target chain and initiates a revocation instruction detection mechanism. The receiver detects and obtains the revocation instruction sent to the target chain by the initiator, parses the revocation instruction, and obtains three core fields in the revocation instruction: session identifier information, revocation random number, and revocation signature.

[0046] S120. Call the target hash time lock contract of the target chain to verify the revocation instruction and obtain the verification result.

[0047] The target hash timelock contract is a smart contract deployed on the target blockchain. The hash timelock contract (HTLC) includes hash locking and time locking mechanisms. Hash locking ensures that only those providing the original password can retrieve the locked transaction item from the contract, allowing for multiple trustless intermediaries; time locking ensures that the transaction item is safely returned to the original owner in the event of a default by one party. The target hash timelock contract can be used to verify revocation instructions submitted by the recipient and output the verification result. The verification result is the feedback data output by the target hash timelock contract after verifying the revocation instruction.

[0048] Specifically, the target hash time lock contract of the target chain is invoked to verify the revocation instruction, confirming its legality and generating a verification result based on the verification status. The verification result includes pass or fail. Thus, the revocation instruction is verified through the target hash time lock contract. The verification process requires no third-party intervention, and the result is tamper-proof, enhancing the credibility of the revocation operation and improving the security and efficiency of the verification process.

[0049] S130. If the verification result is successful, the target hash time lock contract is invoked to update the session state of the transaction session to the revoked state and set the transaction state of the first transaction object to the unlocked state.

[0050] In this context, the revocation state is the state in which a transaction session is marked as terminated. The first transaction object is the asset held by the recipient in the cross-chain transaction. Transaction state refers to the state of the transaction object. Transaction states include unlocked and locked states. The unlocked state is the state in which the locked transaction object is released from its locking restrictions.

[0051] Specifically, if the verification result is successful, the target hash time lock contract is invoked to update the session state of the cross-chain transaction from locked to revoked, and the transaction state of the first transaction object is changed from locked to unlocked, so that the first transaction object can be rolled back to the recipient. This achieves synchronized updates between the session state of the transaction and the transaction state of the first transaction object through the target hash time lock contract, avoiding the logical vulnerability of session revocation while assets remain locked, and ensuring the integrity of the cross-chain transaction process. The unlocking operation is triggered only after the revocation instruction is verified, preventing malicious entities from tampering with the transaction object's state and ensuring the security and controllability of the first transaction object (such as assets). Complete records of session state changes and transaction object state updates are stored on the blockchain, providing an immutable chain of evidence for cross-chain transaction auditing and dispute resolution.

[0052] Optionally, it also includes: if the verification result is unsuccessful, generating a failure notification message and sending the failure notification message to the source chain through a cross-chain gateway so that the initiator can obtain the failure notification message on the source chain.

[0053] The failure notification message is feedback data generated by the recipient when the revocation instruction verification fails. A cross-chain gateway is a blockchain interaction middleware connecting the target chain and the source chain. A cross-chain gateway can enable cross-chain message forwarding.

[0054] Specifically, if the verification result is unsuccessful, a failure notification is generated, and the cross-chain gateway is invoked. The cross-chain gateway then sends the failure notification to the source chain so that the initiator can obtain the failure notification on the source chain. This achieves result synchronization between the target chain and the source chain through the cross-chain gateway, ensuring that the reason for the revocation instruction verification failure can be obtained by the source chain in a timely manner. This allows the initiator to quickly locate the problem in the revocation instruction (such as signature error or duplicate random number), improving the efficiency of cross-chain transaction problem investigation. While ensuring the execution of legitimate revocation instructions, it also provides feedback on the results of illegitimate instructions, forming a complete closed loop for cross-chain transaction session revocation.

[0055] In this embodiment of the invention, the revocation instruction includes session identifier information, a revocation random number, and a revocation signature. The recipient needs to call the target hash time lock contract of the target chain to complete the verification. The verification logic based on the contract ensures the authenticity and legality of the revocation instruction, improving the security and reliability of the cross-chain transaction revocation process. When the initiator initiates revocation due to changes in transaction conditions, on-chain failures, or other reasons, the recipient can respond quickly and complete subsequent processing, avoiding liquidity loss caused by long-term asset locking, and improving the fault tolerance and scenario adaptability of cross-chain transactions. The steps of revocation instruction verification, session state update, and asset unlocking are all completed by calling the target hash time lock contract, without any manual intervention. By utilizing the automation and programmability of smart contracts, human error in the cross-chain transaction revocation process is reduced, and the overall execution efficiency of cross-chain transactions is improved.

[0056] Figure 2 This is a flowchart of another cross-chain transaction method provided by an embodiment of the present invention. Based on the above embodiments, this embodiment optimizes the step of "calling the target hash time lock contract of the target chain to verify the revocation instruction and obtain the verification result," providing an optional implementation scheme. For example... Figure 2 As shown, this method is applied to the receiver, and the method includes:

[0057] S210. Detect and obtain the revocation instruction sent by the initiator on the target chain; the revocation instruction includes the session identifier information of the cross-chain transaction session, the revocation random number, and the revocation signature.

[0058] S220: Call the target hash time lock contract of the target chain to verify the revocation instruction and obtain the verification result.

[0059] S230. If the verification result is successful, the target hash time lock contract is invoked to update the session state of the transaction session to the revoked state and set the transaction state of the first transaction object to the unlocked state.

[0060] Optionally, the target hash time lock contract of the target chain is invoked to verify the revocation instruction and obtain the verification result, including: invoking the target hash time lock contract of the target chain to locate the transaction session based on the session identifier information; checking whether the session state of the transaction session is in an unexecuted state or an incomplete state; if so, checking whether the revocation random number is not used; if not used, hashing the session identifier information and the revocation random number to obtain a first revocation digest; using the initiator's public key to verify the revocation signature to obtain a second revocation digest; if the first revocation digest and the second revocation digest are consistent, the verification result is determined to be successful.

[0061] The "Unexecuted" state refers to the initial state where a cross-chain transaction session has been created but core business processes (such as locking transaction objects and data transfer) have not yet started. The "Incomplete" state refers to the intermediate state where a cross-chain transaction session has started core business processes (such as locking transaction objects) but final settlement (such as cross-chain transfer of transaction objects and state synchronization) has not yet been completed. The first revocation digest is the data obtained by the recipient calling the target hash timelock contract to hash the session identifier information and the revocation random number. The public key is the initiator's public key; the public key is pre-stored in the target hash timelock contract. The second revocation digest is the data obtained by the target hash timelock contract using the initiator's public key to decrypt and verify the revocation signature, and then restoring the original data.

[0062] Specifically, the target hash time lock contract is invoked to locate the corresponding transaction session in the on-chain session registry based on the session identifier information. It checks whether the session state is in an unexecuted or incomplete state. If so, it searches the on-chain random number blacklist to determine if the revocation random number has been used. If not, it performs a hash calculation on the session identifier information and the revocation random number to obtain the first revocation digest. The revocation signature is verified using the initiator's public key to obtain the second revocation digest. If the first and second revocation digests match, the verification result is considered successful. This process avoids invalid revocation operations on terminated sessions by verifying whether the session state is in an unexecuted or incomplete state, reducing on-chain resource consumption and improving the efficiency of the verification process. The consistency comparison between the first and second revocation digests ensures that the revocation signature has not been tampered with and was indeed legally generated by the initiator, significantly improving the security and accuracy of the revocation instruction verification. The layered and progressive verification logic (session state verification, revocation random number verification, and revocation signature verification) accurately pinpoints the specific steps where verification failed, facilitating rapid problem identification by the initiator.

[0063] This embodiment also provides a cross-chain transaction process, optionally further including: setting the transaction state of the first transaction object to a locked state through a target hash time-lock contract on the target chain, so that when the initiator detects that the transaction state of the first transaction object is locked, it calls the target hash time-lock contract on the target chain to submit the first preimage to the receiver; calling the target hash time-lock contract to determine the first locking information recorded in the target hash time-lock contract; the first locking information includes a first locking start time, a target hash value, and a first timeout time; the target hash value is the source hash value published by the initiator obtained by the receiver on the source chain; the source hash value is obtained by the initiator through hash calculation of the first preimage of the cross-chain transaction and is sent... The initiator stores and publishes the first preimage on the source chain; based on the first lock start time and the first timeout time, a first tradable time range is determined; if the first preimage submitted by the initiator is obtained within the first tradable time range, the first preimage is hashed to obtain the first hash value of the first preimage; the first hash value is compared with the target hash value, and if they match, the first transaction object is released to the initiator; when the transaction status of the second transaction object is detected to be locked, the source hash time lock contract of the source chain is called to submit the second preimage to the initiator, so that the initiator hashes the second preimage to obtain the second hash value of the second preimage, and compares the second hash value with the source hash value. If they match, the second transaction object is released to the receiver.

[0064] In this context, "locked state" refers to the state in which the transaction object is under lock restrictions. "First preimage" refers to the preimage of the cross-chain transaction generated and held by the initiator. "First lock information" refers to the data recorded by the target hash time-lock contract related to the locking operation of the first transaction object. "First lock start time" refers to the timestamp when the target hash time-lock contract sets the first transaction object to a locked state. "Target hash value" is the source hash value published by the initiator and obtained by the recipient on the source chain; the source hash value is obtained by the initiator through hash calculation of the first preimage of the cross-chain transaction and is stored and published by the initiator on the source chain. "First timeout" refers to the effective duration of the first transaction object's locked state preset by the target hash time-lock contract. "First tradable time range" is a time window calculated based on the first lock start time and the first timeout. "First hash value" refers to the hash value obtained by the target hash time-lock contract after hashing the first preimage submitted by the initiator. "Second transaction object" refers to the transaction item held by the initiator in the cross-chain transaction. "Second preimage" is the preimage related to unlocking the second transaction object. "Second preimage" is the first preimage published by the initiator and obtained by the recipient on the target chain. The second hash value is the hash value obtained by the initiator calling the source hash time lock contract to perform a hash operation on the second preimage submitted by the receiver.

[0065] Specifically, the target hash time lock contract sets the first transaction object to a locked state and records the first lock information, including the first lock start time, target hash value, and first timeout period. The target hash value is generated by the initiator hashing the first preimage of the cross-chain transaction and is stored and publicly available on the source chain. Upon detecting a locked state, the initiator submits the first preimage. The contract first determines the first tradable time range based on the lock information. If the first preimage is submitted within this range, it is hashed to obtain the first hash value. If the hash value matches the target hash value, the first transaction object is released to the initiator. When a second transaction object is detected to be locked on the source chain, the recipient calls the source hash time lock contract to submit the second preimage so that the initiator can hash the second preimage to obtain the second hash value. If the hash value matches the source hash value, the source hash time lock contract releases the second transaction object to the recipient. Based on the first tradable time range set by the first locking information, the effective duration of the preimage submission is precisely constrained, preventing cross-chain transactions from being suspended for a long time due to delays by one party, thus improving the timeliness and certainty of the transaction process. The hash value of the cross-chain transaction is used as the sole benchmark for cross-chain verification and is stored synchronously on the source chain and the target chain, ensuring that the verification logic of the two heterogeneous chains is completely unified and eliminating the risk of transaction failure caused by differences in data between chains. The entire locking, verification, and release operation is automatically executed by calling the hash time lock contract without the intervention of a third-party intermediary, realizing decentralized autonomy of cross-chain transactions and reducing trust costs and operational risks.

[0066] This invention, through session state verification, avoids invalid revocation operations on terminated sessions, reduces on-chain resource consumption, and improves the execution efficiency of the verification process. Based on the consistency comparison of the first and second revocation digests, it ensures that the revocation signature has not been tampered with and was indeed legally generated by the initiator, significantly improving the security and accuracy of revocation instruction verification. Employing a layered and progressive verification logic (session state verification, revocation random number verification, and revocation signature verification), it can accurately pinpoint the specific stage of verification failure, facilitating rapid problem identification by the initiator. Using the hash value of the cross-chain transaction as the benchmark for cross-chain verification, it is synchronously stored on both the source and target chains, ensuring complete consistency in the verification logic of the two blockchains and eliminating the risk of transaction failure due to data differences between chains. The entire locking, verification, and release operation is automatically executed by calling the hash time lock contract. Utilizing the automation and programmability of smart contracts, it reduces human error in the cross-chain transaction revocation process. The contract execution result is directly written to the target chain block, possessing immutability, providing a reliable basis for auditing and tracing cross-chain transactions, and improving the overall execution efficiency of cross-chain transactions.

[0067] Figure 3This is a flowchart of another cross-chain transaction method provided by an embodiment of the present invention. This embodiment is applicable to cross-chain transactions, especially object transactions between different blockchains. The method is applied to the initiator and can be executed by a cross-chain transaction device. This device can be implemented in hardware and / or software and can be configured in an electronic device with corresponding data processing capabilities, such as a server. Figure 3 As shown, the method includes:

[0068] S310, Generate the first preimage and reversal random number for cross-chain transactions.

[0069] The first preimage refers to the data generated by the initiator for cross-chain transaction verification.

[0070] Specifically, a random number is generated using a random algorithm. This random number is used as the first preimage, and another random number is generated simultaneously as the undo random number. The random number is unique and unpredictable.

[0071] S320. When the first preimage is not detected in the blockchain network and the session state of the cross-chain transaction is locked, initiate a request to revoke the cross-chain transaction on the source chain.

[0072] The blockchain network is a cluster of blockchains encompassing both the source and target chains. A transaction reversal request refers to a request actively submitted by the initiator on the source chain to reverse a transaction.

[0073] Specifically, when the first preimage has not yet been publicly disclosed on any blockchain and the transaction session state is still locked, the initiator can proactively trigger a reversal operation based on business needs, that is, proactively initiate a reversal transaction request for the cross-chain transaction on the source chain. This ensures that reversal is only initiated when both the first preimage and session locking conditions are not simultaneously met, avoiding accidental triggering and improving the accuracy of the reversal process. Furthermore, proactively triggering a reversal request based on the preimage detection result and session state prevents the transaction from being locked indefinitely due to the recipient's failure to submit the preimage, thus protecting the initiator's own rights.

[0074] S330. Based on the session identifier information of the transaction session and the revocation random number, determine the third revocation digest.

[0075] The third revocation digest is the data obtained by the initiator calling the source hash time lock contract to perform a hash operation on the session identifier information and the revocation random number.

[0076] Specifically, the two data items are concatenated in a preset fixed order (such as "session identifier information + revocation random number") to form a concatenated string. A cryptographically secure hash algorithm is then called to perform a hash calculation on the concatenated string to obtain the third revocation digest.

[0077] S340. Use the private key to sign the third revocation digest to generate a revocation signature.

[0078] Among them, revocation signature refers to the data obtained by the initiator using its own private key to perform a digital signature operation on the third revocation digest.

[0079] Specifically, the initiator calls an asymmetric encryption signature algorithm and uses its own private key to perform a signature operation on the third revocation digest; the output data after the operation is completed is the revocation signature.

[0080] S350: Generate a revocation command based on the revocation signature, session identifier information, and revocation random number.

[0081] Specifically, the session identifier information, revocation random number, and revocation signature are integrated and encapsulated according to a preset format to generate a structured revocation instruction.

[0082] S360: Send the revocation instruction to the target chain through the cross-chain gateway so that the recipient can execute the revocation process for the cross-chain transaction on the target chain.

[0083] Specifically, the revocation instruction is sent to the target chain via a cross-chain gateway, enabling the recipient to execute the revocation process for the cross-chain transaction on the target chain. This relies on the cross-chain gateway to ensure reliable transmission of instructions between the source and target chains.

[0084] This embodiment also provides a cross-chain transaction process, which optionally includes: performing a hash calculation on the first preimage to obtain the source hash value of the cross-chain transaction, and storing and publishing the source hash value on the source chain so that the recipient can obtain the source hash value from the source chain; setting the transaction state of the second transaction object to a locked state through the source hash time-lock contract on the source chain so that when the recipient detects that the transaction state of the second transaction object is locked, it calls the source hash time-lock contract on the source chain to submit the second preimage to the initiator; when the transaction state of the first transaction object is detected to be locked, it calls the target hash time-lock contract on the target chain to submit the first preimage to the recipient so that the recipient can access the first preimage. A hash calculation is performed to obtain the first hash value of the first preimage. The first hash value is then compared with the target hash value. If they match, the first transaction object is released to the initiator. The source hash time lock contract is invoked to determine the second locking information recorded in the source hash time lock contract. The second locking information includes the second lock start time, the source hash value, and the second timeout time. Based on the second lock start time and the second timeout time, a second tradable time range is determined. If the second preimage submitted by the recipient is obtained within the second tradable time range, a hash calculation is performed on the second preimage to obtain the second hash value of the second preimage. The second hash value is compared with the source hash value. If they match, the second transaction object is released to the recipient.

[0085] The source hash timelock contract is a smart contract deployed on the source chain. The second locking information refers to the data recorded by the source hash timelock contract related to the locking operation of the second transaction object. The second lock start time is the timestamp at which the source hash timelock contract sets the second transaction object to a locked state. The second timeout period is the preset effective duration of the second transaction object's locked state by the source hash timelock contract. The second timeout period is longer than the first timeout period. The second tradable time range is a time window calculated based on the second lock start time and the second timeout period.

[0086] Specifically, the process involves hashing the first preimage of the cross-chain transaction to generate a source hash value; storing and publicly displaying the source hash value on the source chain, allowing the recipient to retrieve it as a verification benchmark; invoking the source chain's source hash time lock contract to set the transaction status of the second transaction object to a locked state, so that the recipient can submit the second preimage to the initiator upon detecting this locked state; after detecting that the transaction status of the first transaction object on the target chain is locked, invoking the target chain's target hash time lock contract to submit the first preimage to the recipient; allowing the recipient to generate a first hash value and compare it with the target hash value, and releasing the first transaction object to the initiator upon successful verification; invoking the source hash time lock contract to obtain the second locking information recorded in the contract (including the second lock start time, source hash value, and second timeout time); calculating the second tradable time range based on the second lock start time and the second timeout time; if the second preimage submitted by the recipient is obtained within the second tradable time range, the initiator hashes the second preimage to generate a second hash value; comparing the second hash value with the source hash value for consistency; if they match, the source hash time lock contract releases the second transaction object to the recipient. By using the first tradable time range of the target chain and the second tradable time range of the source chain, the effective duration of the preimage submission is constrained respectively, avoiding long-term transaction suspension and improving the certainty and execution efficiency of the transaction process; the time lock information (first or second lock information) and the transaction status are synchronously stored on the chain, and all operations are traceable and auditable, which makes it easy for participants to monitor the transaction progress in real time and reduce process management costs.

[0087] In this embodiment of the invention, the initiator only has the right to revoke when the transaction is incomplete or not executed and the transaction object is still locked. This avoids malicious revocation or accidental operation. Compared with the traditional cross-chain transaction mode where the initiator can only passively wait for the timeout to unlock, in this embodiment of the invention, the initiator can actively trigger the revocation process. This can cope with various scenarios such as changes in transaction conditions, on-chain failures, and abnormal recipients, effectively reducing asset liquidity losses caused by transaction deadlock and improving the fault tolerance and scenario adaptability of cross-chain transactions. The generation process of the revocation instruction adopts a dual security mechanism of digest calculation and private key signature to ensure that the revocation instruction has unique identity (only the legitimate initiator can generate a valid signature) and immutability of content. This effectively resists cross-chain malicious attacks such as forged revocation instructions and impersonation of the initiator's identity, and protects the asset security of the initiator and the target link recipient.

[0088] Figure 4 This is a schematic diagram of a cross-chain transaction device provided in an embodiment of the present invention. This embodiment is applicable to cross-chain transactions, particularly object transactions between different blockchains. The device is configured on the receiving end and can be implemented in hardware and / or software. It can be configured in an electronic device with corresponding data processing capabilities, such as a server. Figure 4 As shown, the device includes:

[0089] The instruction acquisition module 410 is used to detect and acquire the revocation instruction sent by the initiator on the target chain; the revocation instruction includes the session identifier information of the cross-chain transaction session, the revocation random number, and the revocation signature;

[0090] The instruction verification module 420 is used to call the target hash time lock contract of the target chain to verify the revocation instruction and obtain the verification result;

[0091] The revocation execution module 430 is used to call the target hash time lock contract if the verification result is successful, update the session state of the transaction session to the revocation state, and set the transaction state of the first transaction object to the unlock state.

[0092] In this embodiment of the invention, the revocation instruction includes session identifier information, a revocation random number, and a revocation signature. The recipient needs to call the target hash time lock contract of the target chain to complete the verification. The verification logic based on the contract ensures the authenticity and legality of the revocation instruction, improving the security and reliability of the cross-chain transaction revocation process. When the initiator initiates revocation due to changes in transaction conditions, on-chain failures, or other reasons, the recipient can respond quickly and complete subsequent processing, avoiding liquidity loss caused by long-term asset locking, and improving the fault tolerance and scenario adaptability of cross-chain transactions. The steps of revocation instruction verification, session state update, and asset unlocking are all completed by calling the target hash time lock contract, without any manual intervention. By utilizing the automation and programmability of smart contracts, human error in the cross-chain transaction revocation process is reduced, and the overall execution efficiency of cross-chain transactions is improved.

[0093] Optionally, the instruction verification module 420 includes:

[0094] The transaction session location unit is used to call the target hash time lock contract of the target chain and locate the transaction session based on the session identifier information.

[0095] The session state determination unit is used to detect whether the session state of a transaction session is in an unexecuted state or an incomplete state.

[0096] The cancellation random number detection unit is used to detect whether the cancellation random number has not been used if the condition is met.

[0097] The first revocation digest determination unit is used to perform a hash calculation on the session identifier information and the revocation random number to obtain the first revocation digest if it is not used.

[0098] The second revocation digest determination unit is used to verify the revocation signature using the initiator's public key to obtain the second revocation digest;

[0099] The first verification unit is used to determine that the verification result is passed if the first revocation digest is consistent with the second revocation digest.

[0100] Optionally, the device further includes: a failure notification information generation module, used to generate failure notification information if the verification result is unsuccessful, and send the failure notification information to the source chain through a cross-chain gateway so that the initiator can obtain the failure notification information on the source chain.

[0101] Optionally, the device also includes:

[0102] The first transaction object locking module is used to set the transaction status of the first transaction object to a locked state through the target hash time lock contract on the target chain, so that when the initiator detects that the transaction status of the first transaction object is locked, it calls the target hash time lock contract on the target chain to submit the first preimage to the receiver.

[0103] The first lock information determination module is used to call the target hash time lock contract to determine the first lock information recorded in the target hash time lock contract; the first lock information includes the first lock start time, the target hash value, and the first timeout time.

[0104] The first tradable time determination module is used to determine the first tradable time range based on the first lock start time and the first timeout time;

[0105] The first hash value determination module is used to perform hash calculation on the first preimage if the first preimage submitted by the initiator is obtained within the first tradable time range, and to obtain the first hash value of the first preimage.

[0106] The first transaction object release module is used to compare the first hash value with the target hash value. If they match, the first transaction object is released to the initiator.

[0107] The second preimage submission module is used to call the source chain's source hash time lock contract when the transaction status of the second transaction object is detected to be locked, and submit the second preimage to the initiator so that the initiator can perform hash calculation on the second preimage to obtain the second hash value of the second preimage, and compare the second hash value with the source hash value. If they match, the second transaction object is released to the receiver.

[0108] The cross-chain transaction device provided in the embodiments of the present invention can execute the cross-chain transaction method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0109] Figure 5 This is a schematic diagram of another cross-chain transaction device provided in an embodiment of the present invention. This embodiment is applicable to cross-chain transactions, especially object transactions between different blockchains. The device is configured on the initiating party and can be implemented in hardware and / or software. It can be configured in an electronic device with corresponding data processing capabilities, such as a server. Figure 5 As shown, the device includes:

[0110] Data generation module 510 is used to generate the first preimage and reversal random number for cross-chain transactions;

[0111] The request initiation module 520 is used to initiate a request to revoke the cross-chain transaction on the source chain when the first preimage is not detected in the blockchain network and the session state of the cross-chain transaction session is locked.

[0112] The summary determination module 530 is used to determine a third revocation summary based on the session identifier information of the transaction session and the revocation random number;

[0113] The signature generation module 540 is used to sign the third revocation digest using a private key to generate a revocation signature;

[0114] The instruction generation module 550 is used to generate a revocation instruction based on the revocation signature, session identifier information, and revocation random number;

[0115] The instruction sending module 560 is used to send revocation instructions to the target chain through the cross-chain gateway, so that the recipient can execute the revocation process of the cross-chain transaction on the target chain.

[0116] In this embodiment of the invention, the initiator only has the right to revoke when the transaction is incomplete or not executed and the transaction object is still locked. This avoids malicious revocation or accidental operation. Compared with the traditional cross-chain transaction mode where the initiator can only passively wait for the timeout to unlock, in this embodiment of the invention, the initiator can actively trigger the revocation process. This can cope with various scenarios such as changes in transaction conditions, on-chain failures, and abnormal recipients, effectively reducing asset liquidity losses caused by transaction deadlock and improving the fault tolerance and scenario adaptability of cross-chain transactions. The generation process of the revocation instruction adopts a dual security mechanism of digest calculation and private key signature to ensure that the revocation instruction has unique identity (only the legitimate initiator can generate a valid signature) and immutability of content. This effectively resists cross-chain malicious attacks such as forged revocation instructions and impersonation of the initiator's identity, and protects the asset security of the initiator and the target link recipient.

[0117] Optionally, the device also includes:

[0118] The target hash value determination module is used to perform hash calculation on the first preimage to obtain the source hash value of the cross-chain transaction, and to store and publish the source hash value on the source chain so that the recipient can obtain the source hash value from the source chain.

[0119] The second transaction object locking module is used to set the transaction status of the second transaction object to a locked state through the source hash time lock contract on the source chain, so that when the receiver detects that the transaction status of the second transaction object is locked, it calls the source hash time lock contract on the source chain to submit the second preimage to the initiator.

[0120] The first preimage submission module is used to call the target hash time lock contract of the target chain when the transaction status of the first transaction object is detected to be locked, and submit the first preimage to the receiver so that the receiver can perform hash calculation on the first preimage to obtain the first hash value of the first preimage, and compare the first hash value with the target hash value. If they match, the first transaction object is released to the initiator.

[0121] The second lock information determination module is used to call the source hash time lock contract to determine the second lock information recorded in the source hash time lock contract; the second lock information includes the second lock start time, the source hash value, and the second timeout time.

[0122] The second tradable time determination module is used to determine the second tradable time range based on the second lock start time and the second timeout time.

[0123] The second hash value determination module is used to perform hash calculation on the second preimage if the second preimage submitted by the recipient is obtained within the second tradable time range, and obtain the second hash value of the second preimage.

[0124] The second transaction object release module is used to compare the second hash value with the source hash value. If they match, the second transaction object is released to the receiver.

[0125] The cross-chain transaction device provided in the embodiments of the present invention can execute the cross-chain transaction method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0126] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0127] Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0128] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0129] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0130] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as cross-chain transaction methods.

[0131] In some embodiments, the cross-chain transaction method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded into and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cross-chain transaction method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the cross-chain transaction method by any other suitable means (e.g., by means of firmware).

[0132] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0133] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0135] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0137] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0138] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0139] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A cross-chain transaction method, characterized in that, Applied to the receiver, the method includes: Detect and obtain the revocation instruction sent by the initiator on the target chain; the revocation instruction includes the session identifier information of the cross-chain transaction session, the revocation random number, and the revocation signature; The target hash time lock contract of the target chain is invoked to verify the revocation instruction, and the verification result is obtained; If the verification result is successful, the target hash time lock contract is invoked to update the session state of the transaction session to the revoked state and set the transaction state of the first transaction object to the unlocked state.

2. The method according to claim 1, characterized in that, The step of calling the target hash time lock contract of the target chain to verify the revocation instruction and obtaining the verification result includes: Invoke the target hash time lock contract of the target chain to locate the transaction session based on the session identifier information; Detect whether the session status of the transaction session is in an unexecuted or incomplete state; If so, check whether the cancellation random number was not used; If not used, perform a hash calculation on the session identifier information and the revocation random number to obtain a first revocation digest; Using the initiator's public key, the revocation signature is verified to obtain a second revocation digest; If the first revocation digest is consistent with the second revocation digest, then the verification result is determined to be successful.

3. The method according to claim 1, characterized in that, The method further includes: If the verification result is unsuccessful, a failure notification is generated and sent to the source chain via a cross-chain gateway so that the initiator can obtain the failure notification on the source chain.

4. The method according to claim 1, characterized in that, The method further includes: By using the target hash time lock contract on the target chain, the transaction status of the first transaction object is set to a locked state, so that when the initiator detects that the transaction status of the first transaction object is locked, it calls the target hash time lock contract on the target chain to submit the first preimage to the receiver. Invoke the target hash time lock contract to determine the first locking information recorded in the target hash time lock contract; the first locking information includes a first locking start time, a target hash value, and a first timeout time. Based on the first lock start time and the first timeout time, a first tradable time range is determined; If the first preimage submitted by the initiator is obtained within the first tradable time range, then the first preimage is hashed to obtain the first hash value of the first preimage. The first hash value is compared with the target hash value. If they match, the first transaction object is released to the initiator. When the transaction status of the second transaction object is detected to be locked, the source hash time lock contract of the source chain is invoked to submit the second preimage to the initiator, so that the initiator performs a hash calculation on the second preimage to obtain the second hash value of the second preimage, and compares the second hash value with the source hash value. If they match, the second transaction object is released to the receiver.

5. A cross-chain transaction method, characterized in that, Applied to the initiator, the method includes: Generate the first preimage and reversal random number for cross-chain transactions; When the first preimage is not detected in the blockchain network and the transaction session of the cross-chain transaction is locked, a request to revoke the cross-chain transaction is initiated on the source chain. Based on the session identifier information of the transaction session and the revocation random number, a third revocation digest is determined; The third revocation digest is signed using the private key to generate a revocation signature; A revocation command is generated based on the revocation signature, the session identifier information, and the revocation random number; The revocation instruction is sent to the target chain through a cross-chain gateway, so that the recipient can perform the revocation process for the cross-chain transaction on the target chain.

6. The method according to claim 5, characterized in that, The method further includes: The first preimage is hashed to obtain the source hash value of the cross-chain transaction, and the source hash value is stored and made public on the source chain so that the recipient can obtain the source hash value from the source chain. The source hash time lock contract on the source chain sets the transaction status of the second transaction object to a locked state, so that when the receiver detects that the transaction status of the second transaction object is locked, it calls the source hash time lock contract on the source chain to submit the second preimage to the initiator. When the transaction status of the first transaction object is detected to be locked, the target hash time lock contract of the target chain is invoked to submit the first preimage to the receiver so that the receiver can perform hash calculation on the first preimage to obtain the first hash value of the first preimage and compare the first hash value with the target hash value. If they match, the first transaction object is released to the initiator. Invoke the source hash time lock contract to determine the second locking information recorded by the source hash time lock contract; the second locking information includes the second locking start time, the source hash value, and the second timeout time. A second tradable time range is determined based on the second lock start time and the second timeout time; If the second preimage submitted by the recipient is obtained within the second tradable time range, then a hash calculation is performed on the second preimage to obtain the second hash value of the second preimage; The second hash value is compared with the source hash value. If they match, the second transaction object is released to the recipient.

7. A cross-chain transaction device, characterized in that, Configured on the receiver, the device includes: The instruction acquisition module is used to detect and acquire the revocation instruction sent by the initiator on the target chain; the revocation instruction includes the session identifier information of the cross-chain transaction session, the revocation random number, and the revocation signature; The instruction verification module is used to call the target hash time lock contract of the target chain to verify the revocation instruction and obtain the verification result; The revocation execution module is used to, if the verification result is passed, call the target hash time lock contract, update the session state of the transaction session to the revocation state, and set the transaction state of the first transaction object to the unlock state.

8. A cross-chain transaction device, characterized in that, Configured on the initiator, the device includes: The data generation module is used to generate the first preimage and reversal random number for cross-chain transactions; The request initiation module is used to initiate a transaction revocation request for the cross-chain transaction on the source chain when the first preimage is not detected in the blockchain network and the session state of the transaction session of the cross-chain transaction is locked. The digest determination module is used to determine a third revocation digest based on the session identifier information of the transaction session and the revocation random number; The signature generation module is used to sign the third revocation digest using a private key to generate a revocation signature; The instruction generation module is used to generate a revocation instruction based on the revocation signature, the session identifier information, and the revocation random number; The instruction sending module is used to send the revocation instruction to the target chain through the cross-chain gateway, so that the recipient can perform the revocation process of the cross-chain transaction on the target chain.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the cross-chain transaction method according to any one of claims 1-4 or 5-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the cross-chain transaction method of any one of claims 1-4 or 5-6.

11. A computer program product comprising a computer program that, when executed by a processor, implements the cross-chain transaction method according to any one of claims 1-4 or 5-6.

Images