A privacy-protected cross-chain asset transfer method

Abstract

The application discloses a privacy-protected cross-chain asset transfer method, and mainly solves the problems of user privacy leakage, poor usability and universality in the prior art cross-chain asset transfer technology. s , asset receiver P r , third-party payment center P h and a block chain, then uses the idea of P s first mortgage, so that P r cannot lock the asset by requesting P h meaninglessly; further uses a synchronous puzzle to prevent P s and P r from colluding to steal P h assets, and at the same time, prevent P h from stealing P s transferred assets but not P r transferred assets; finally, in combination with a two-party adapter signature scheme and a verifiable timing discrete logarithm scheme and other cryptographic tools, the cross-chain transaction format is set according to the in-chain transaction format, and the transaction is completed. The application can effectively protect the privacy of users in terms of indistinguishability and unlinkability when cross-chain assets are transferred, and compatibility, heterogeneity and minimum functional requirements are realized.

Description

Technical Field

[0001] This invention belongs to the field of cybersecurity technology and relates to cross-chain asset transfer, specifically a privacy-preserving method for cross-chain asset transfer. It can be used for interoperability between digital currency systems and offers good privacy, ease of use, and versatility. Background Technology

[0002] Different cryptocurrency systems often differ in their technical implementation, such as consensus mechanisms and on-chain functions. These characteristics pose challenges to the interoperability of cryptocurrency systems.

[0003] Currently, numerous technical solutions have been developed to achieve interoperability of digital currency systems. Cross-system transfer of digital currency (i.e., cross-chain asset transfer), as an important aspect of interoperability, has received widespread attention and in-depth research from scholars. Back et al., in BackA, Corallo M, DashjrL, et al. Enabling blockchain innovations with pegged sidechains[J]., first proposed a sidechain scheme. This scheme allows users to lock a certain amount of assets on one chain (called the main chain), and then provide simple payment verification proof on another chain (called the sidechain, with the same name as the technology) to mint an equivalent amount of assets. While this scheme reduces the verification cost of cross-chain proofs to some extent, it still requires modification of the block structure of the interconnected blockchain and lacks ease of use.

[0004] A sidechain solution is presented in publication CN113781228A, entitled "A Cross-Chain Asset Transfer Method, Apparatus, Device, and Storage Medium." In this solution, a main chain user P creates and registers an asset t, then transfers a certain amount of asset t to another user Q, registering the sidechain information where Q resides. Q can submit proof of the main chain transfer transaction on the sidechain; after successful verification, the sidechain increases Q's holdings of asset t. This solution supports transferring asset t between multiple sidechains and redeeming asset t on the main chain, offering good flexibility. However, it requires the interconnected blockchains to support smart contracts and does not protect the privacy of cross-chain transactions. In the publication CN115641121A, titled "A Method, Apparatus, Electronic Device, and Medium for Cross-Chain Transfer of Digital Assets," a relay chain is used to achieve cross-chain asset transfer. The relay chain receives asset transfer requests from the source chain and issues commands to the target chain to transfer the corresponding assets. Then, the relay chain receives the response from the target chain regarding the asset transfer result and issues commands to the source chain to deduct or unlock the assets. The relay chain introduced in this scheme can also be used to trace cross-chain transaction information. However, this scheme also requires all blockchains to support smart contracts and does not protect the privacy of cross-chain transactions.

[0005] Furthermore, in the publication CN115601164A, titled "Method and System for Cross-Chain Asset Transfer Without Affecting the Normal Execution of Related Asset Transactions," a pre-execution transaction is required before transferring assets out of the main chain and into the side chain. While this solution achieves cross-chain asset transfer without affecting the transaction of related assets, it requires the interconnected blockchain to have some form of asset locking function and does not protect the privacy of cross-chain transactions. Publication CN115660853A, titled "Cross-Chain Asset Transfer Method, Computer Equipment, and Storage Medium," provides an auxiliary architecture supporting cross-chain asset transfer. This architecture includes a main chain for configuring the account model and several parallel chains. The blockchain to which assets are to be transferred updates the on-chain account information of the asset sender and receiver by interacting with the corresponding parallel chains. This architecture facilitates the verification of cross-chain operations but requires the blockchain to have on-chain functionality for verifying zero-knowledge proofs and does not protect the privacy of cross-chain transactions.

[0006] While existing solutions have enabled the transfer of digital currency assets across systems to the recipient using certain technologies, they generally suffer from privacy and security issues and require the underlying blockchain to have many functions, such as verification functions for signatures, commitments, and zero-knowledge proofs. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings of existing technologies by proposing a privacy-preserving cross-chain asset transfer method. This method aims to solve the problems of user privacy leakage, insufficient usability, and lack of universality faced by existing cross-chain asset transfer technologies. This invention utilizes the asset sender P... s Firstly, the concept of collateral allows the asset recipient P to... r Unable to request payment center P h Meaninglessly lock P h Assets; then use synchronous puzzles to prevent P s and P r Collusion to steal P h Assets, while guarding against P h Steal P s Transferred assets but not to P r This invention facilitates asset transfer. Furthermore, it combines synchronization puzzles, phased and fixed-amount payment settings, synchronous communication assumptions, and anonymous channel assumptions to achieve non-linkability. Finally, by incorporating cryptographic tools such as two-party adapter signature schemes and verifiable timed discrete logarithm schemes, it sets cross-chain transaction formats according to in-chain transaction formats, achieving indistinguishability, minimum functional requirements, compatibility, and heterogeneity. This invention effectively protects user privacy in terms of indistinguishability and non-linkability during cross-chain asset transfers, while also achieving compatibility, heterogeneity, and minimum functional requirements.

[0008] The specific steps of this invention to achieve the above objectives are as follows:

[0009] (1) Establish a system by asset sender P s Asset recipient P r The first blockchain B1, the second blockchain B2, and the third-party payment center P h The cross-chain asset transfer system model consists of the asset sender P. s For users and asset recipients P on the first blockchain B1 r For users on the second blockchain B2; assume P s To be transferred to P r The number of assets on B2 is v, and P s The number of assets on B2 is less than v or there is no asset address; third-party payment center P h Used to assist asset sender P s To achieve the transfer of assets from the first blockchain B1 to the second blockchain B2, where P h There are asset addresses on both the first blockchain B1 and the second blockchain B2, and the amount of assets on the second blockchain B2 is not less than v; third-party payment center P h Received from asset sender P on the first blockchain B1 s The asset quantity is u, and the asset recipient is P. r Received from third-party payment center P on the second blockchain B2 h The total quantity of assets is v, and the value of assets B1 with quantity u is greater than the value of assets B2 with quantity v. The excess value is P. s To P h Service fees paid;

[0010] (2) Assume that network communication is synchronous and the communication channel is secure and authenticated; asset sender P s and asset recipient P r The communication channels between them are anonymous and cannot be identified by third parties; cross-chain transactions are completed within a period T, otherwise they are invalid; the quantities u and v are constants within a period; the period T is divided into five stages: transfer locking, puzzle commitment, puzzle solving, transfer completion, and transfer timeout, making the period or stage time long enough and independent of the underlying blockchain;

[0011] (3) Asset sender P s With third-party payment center P h Perform the transfer lock protocol as follows:

[0012] (3.1)P s Initiating execution and P h The joint key generation protocol in the two-party adapter signature scheme, P s and P hEach party receives their respective share's private key and public key, where the public key consists of two parts: the other party's share's public key and the joint public key.

[0013] (3.2)P h Execute the commitment algorithm in the verifiable timed discrete logarithm scheme on its own share of the private key to generate P. h Shared private key commitment and proof, and P h Set the initial difficulty to T1 and send all of them to P. s ;

[0014] (3.3)P s Received P h Send P h After committing to and proving your share of the private key, proceed with the following steps:

[0015] (3.3.1) Verify P h Shared private key commitment; if verification passes, forced opening of P will begin. h If the share of the private key is committed, proceed to step (3.3.2); otherwise, proceed directly to step (4.3).

[0016] (3.3.2) Transfer u units of assets on B1 to the joint public key address to complete the asset locking transaction;

[0017] (3.3.3) Randomly select a qualification identifier, execute the commitment algorithm in the randomizable signature scheme on the identifier to generate a qualification identifier commitment, then generate a zero-knowledge proof of the qualification identifier commitment, and combine the zero-knowledge proof, the qualification identifier commitment, and P s Lock transaction identifier sent to P h ;

[0018] (3.4) If both zero-knowledge proofs and locked transactions are valid, P h The signature commitment algorithm in the randomizable signature scheme is applied to the qualification identifier commitment to generate a signature of the qualification identifier commitment, and the signature of the qualification identifier commitment is sent to P. s If not, proceed to step (3.5); otherwise, proceed directly to step (4.3).

[0019] (3.5)P s Extract the signature of the qualification identifier from the signature of the qualification identifier commitment;

[0020] (4)P s Verify the signature of the qualification identifier:

[0021] (4.1) If the verification passes, continue to step (4.2); otherwise, proceed directly to step (4.3).

[0022] (4.2) Randomize the signature using the randomizable signature scheme algorithm, and send the eligibility identifier, the randomized signature, and the first time difficulty T1 to the asset recipient P. r ;

[0023] (4.3) Wait for the transfer lock phase to end, and then begin the puzzle commitment phase, i.e., execute step (5);

[0024] (5) Asset recipient P r With third-party payment center P h Follow these steps to execute the Puzzle Commitment Agreement:

[0025] (5.1)P r Send the qualification identifier and the randomized signature to P. h ;

[0026] (5.2)P h Verify the randomized signature. If the verification passes, continue to step (5.3); otherwise, proceed to step (6.4).

[0027] (5.3)P h Initiate execution and P r The joint key generation protocol in the two-party adapter signature scheme, P h and P r Each party receives their respective share's private key and public key, where the public key consists of two parts: the other party's share's public key and the joint public key.

[0028] (5.4)P r Execute a verifiable timed discrete logarithm scheme commitment algorithm on your own share of the private key to generate P. r Shared private key commitment and proof, and P r Set the second time difficulty T2 and send it all to P. h ;

[0029] (5.5)P h Received P r Send P r After committing to and proving your share of the private key, proceed with the following steps:

[0030] (5.5.1) Verify P r Shared private key commitment; if verification passes, forced opening of P will begin. r If the share of the private key is committed, proceed to step (5.5.2); otherwise, proceed to step (6.4).

[0031] (5.5.2) Transfer v amount of assets on B2 to the federated public key address to complete the asset locking transaction;

[0032] (5.5.3) Take a random number as evidence, calculate the evidence statement, execute the encryption algorithm in the linear encryption scheme to generate the evidence ciphertext, generate a zero-knowledge proof of the evidence statement and the evidence ciphertext, and then transfer the proof, evidence statement, evidence ciphertext, and P... h Lock transaction identifier sent to P r ;

[0033] (5.6) If both zero-knowledge proofs and locked transactions are valid, P r Initiate execution and P h The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P r The public key address processes transactions involving assets of amount v, P. r and P h If both parties receive the joint pre-signature for the transaction, proceed to step (6); otherwise, proceed to step (6.4).

[0034] (6)P r Select a random number and perform the following steps:

[0035] (6.1) Multiply the selected random number with the evidence statement to obtain a first-order randomization statement;

[0036] (6.2) Perform the randomization ciphertext algorithm in the linear encryption scheme on the evidence ciphertext to generate a first-order randomized evidence ciphertext with respect to the random number;

[0037] (6.3) Send the first randomization statement and the first randomization evidence ciphertext together to the asset sender P. s ;

[0038] (6.4) Wait for the puzzle commitment phase to end, and then begin the puzzle-solving phase, i.e., execute step (7);

[0039] (7) Asset sender P s With third-party payment center P h Follow these steps to execute the puzzle-solving protocol:

[0040] (7.1)P s Select a random number, and obtain the double randomization declaration and double randomization evidence ciphertext for the random number according to steps (6.1)-(6.2), and send both to P. h ;

[0041] (7.2)P h Decrypt the double randomized evidence ciphertext and verify the decryption result. If the verification is successful, continue to step (7.2.1); otherwise, directly execute step (9).

[0042] (7.2.1)P hInitiate execution and P s The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P h The public key address processes transactions involving assets of amount u, P. s and P h All received joint pre-signatures for the transaction.

[0043] (7.2.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the decryption result, the joint pre-signature is converted into P. h Final signature for withdrawal;

[0044] (7.2.3) Publish P on B1 h Withdrawal transactions and P h Final signature for withdrawal, and P h Final signature for withdrawal sent to P s ;

[0045] (7.3)P s By extracting algorithms from the two-party adapter signature scheme, combined with joint pre-signature, P h Extract evidence of double randomization from the final signature and double randomization declaration for withdrawal;

[0046] (8) Asset sender P s The random number from step (7.1) is used to perform a restoration operation with the double randomized evidence to obtain single randomized evidence, which is then sent to the asset recipient P. r ;

[0047] (9) Wait for the puzzle-solving phase to end, and then begin the transition to the completion phase, i.e., execute step (10);

[0048] (10) Asset recipient P r To complete the transfer phase, follow these steps:

[0049] (10.1) Use the random number in step (6) and the first randomized evidence obtained in step (8) to perform a restoration operation to obtain the evidence;

[0050] (10.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the evidence, the joint pre-signature obtained in step (5.6) is transformed into P. r Final signature for withdrawal;

[0051] (10.3) Publish P on B2 r Withdrawal transactions and P r Final signature for withdrawal, wait for the transfer completion period to end, and proceed to step (11);

[0052] (11) After entering the transfer timeout stage, complete this stage according to the following situations:

[0053] P s and P h The joint public key address still has a balance: P s During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T1, P is obtained. h The share of the private key is obtained, and then the joint private key is calculated according to the two-party adapter signature scheme. This generates a public key address that sends a message to P. s The redemption transaction for the public key address payment balance is signed, and the redemption transaction and signature are published on B1;

[0054] P h and P r The joint public key address still has a balance: P h During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T2, P is obtained. r The share of the private key is obtained, and then the joint private key is calculated according to the two-party adapter signature scheme. This generates a public key address that sends a message to P. h The redemption transaction for the public key address to pay the balance is signed, and the redemption transaction and signature are published on B2;

[0055] P s and P h The joint public key address has no balance: P s The waiting timeout period for transfer has ended;

[0056] P h and P r The joint public key address has no balance: P h The waiting timeout period for transfer has ended;

[0057] (12) Complete a cross-chain transaction in which assets are transferred from the first blockchain B1 to the second blockchain B2 within a cycle T.

[0058] Compared with the prior art, the present invention has the following advantages:

[0059] First, both on-chain transactions and the cross-chain transactions involved in this invention include two parts: transaction messages and signatures. Since the format of the cross-chain transaction messages used in this invention is consistent with that of the on-chain transaction messages, and the signatures used are either ordinary digital signatures (the same as those used by the underlying blockchain) or signatures generated by a two-party adapter signature scheme (also consistent with the digital signature format used by the underlying blockchain), the two parts of the two types of transactions are indistinguishable. Therefore, on-chain observers cannot distinguish between cross-chain transactions and on-chain transactions. Furthermore, since the impact of this invention on the underlying blockchain comes from the publication of cross-chain transactions, and the impact of publishing cross-chain transactions on the blockchain is indistinguishable from publishing on-chain transactions, there is no need to modify the block structure of the interconnected blockchain, thus exhibiting good compatibility.

[0060] Second, due to P s and the corresponding P r The risk of being linked comes from two types of entities, namely P h And for on-chain observers, this invention takes into account the linking methods of these two types of entities and adopts different defense measures respectively, so that P h Unable to associate the two signatures through the qualification identifier, unable to associate each pair of P s and P r Two puzzles with a random relationship, where P cannot be obtained. s and P r The communication relationship between them cannot be linked by the time difference in the agreement between the participating parties. s and the corresponding P r This also prevents on-chain observers from linking P through the number of transaction assets on the interconnected blockchain. s and the corresponding P r This allows for privacy protection through non-linkability.

[0061] Third, since all the off-chain cryptographic tools used in this invention only require the underlying blockchain to use one on-chain function, namely the signature verification function, which is also the most basic function of the blockchain, the solution does not impose additional requirements on the underlying blockchain such as commitment or zero-knowledge proof verification functions, thus meeting the minimum functional requirements. Specifically, the blockchain only needs to support the signature verification function of the Schnorr or ECDSA signature scheme, and this function is supported by almost all mainstream blockchains. These blockchains may have different communication mechanisms, block structures, consensus mechanisms, incentive strategies, and other technical implementations, so the technical implementations of interconnected blockchains can be the same or different, exhibiting heterogeneity. Attached image description:

[0062] Figure 1 This is a schematic diagram illustrating an application scenario of the method of the present invention;

[0063] Figure 2This is a flowchart illustrating the implementation of the method of the present invention. Detailed Implementation

[0064] The present invention will now be further described with reference to the accompanying drawings.

[0065] Example 1: Refer to Appendix Figure 1 and Figure 2 This invention proposes a privacy-preserving cross-chain asset transfer method, comprising the following steps:

[0066] Step 1. Refer to Figure 1 Build a platform by asset sender P s Asset recipient P r The first blockchain B1, the second blockchain B2, and the third-party payment center P h The cross-chain asset transfer system model consists of the asset sender P. s For users and asset recipients P on the first blockchain B1 r For users on the second blockchain B2; assume P s To be transferred to P r The number of assets on B2 is v, and P s The number of assets on B2 is less than v or there is no asset address; third-party payment center P h Used to assist asset sender P s To achieve the transfer of assets from the first blockchain B1 to the second blockchain B2, where P h There are asset addresses on both the first blockchain B1 and the second blockchain B2, and the amount of assets on the second blockchain B2 is not less than v; third-party payment center P h Received from asset sender P on the first blockchain B1 s The asset quantity is u, and the asset recipient is P. r Received from third-party payment center P on the second blockchain B2 h The total quantity of assets is v, and the value of assets B1 with quantity u is greater than the value of assets B2 with quantity v. The excess value is P. s To P h Service fees paid;

[0067] Step 2. Assume network communication is synchronous and the communication channel is secure and authenticated; asset sender P s and asset recipient P r The communication channels between them are anonymous and cannot be identified by third parties; cross-chain transactions are completed within a period T, otherwise they are invalid; the quantities u and v are constants within a period; the period T is divided into five stages: transfer locking, puzzle commitment, puzzle solving, transfer completion, and transfer timeout, making the period or stage time long enough and independent of the underlying blockchain;

[0068] Step 3. Asset sender P s With third-party payment center P h Perform the transfer lock protocol as follows:

[0069] (3.1)P s Initiating execution and P h The joint key generation protocol in the two-party adapter signature scheme, P s and P h Each party receives its own share of private and public keys, where the public key consists of the other party's share of public key and a joint public key; the joint public key can be publicly derived to reveal the joint public key address used to control the assets.

[0070] (3.2)P h Execute the commitment algorithm in the verifiable timed discrete logarithm scheme on its own share of the private key to generate P. h Shared private key commitment and proof, and P h Set the initial difficulty to T1 and send all of them to P. s The first difficulty level T1 ends during the transfer timeout phase.

[0071] (3.3)P s Received P h Send P h After committing to and proving your share of the private key, proceed with the following steps:

[0072] (3.3.1) Verify P h Shared private key commitment; if verification passes, forced opening of P will begin. h If the share of the private key is committed, proceed to step (3.3.2); otherwise, proceed directly to step (4.3).

[0073] (3.3.2) Transfer u units of assets on B1 to the joint public key address to complete the asset locking transaction;

[0074] (3.3.3) Randomly select a qualification identifier, execute the commitment algorithm in the randomizable signature scheme on the identifier to generate a qualification identifier commitment, then generate a zero-knowledge proof of the qualification identifier commitment, and combine the zero-knowledge proof, the qualification identifier commitment, and P s Lock transaction identifier sent to P h .

[0075] (3.4) If both zero-knowledge proofs and locked transactions are valid, P h The signature commitment algorithm in the randomizable signature scheme is applied to the qualification identifier commitment to generate a signature of the qualification identifier commitment, and the signature of the qualification identifier commitment is sent to P. s If not, proceed to step (3.5); otherwise, proceed directly to step (4.3).

[0076] (3.5)P s Extract the signature of the qualification identifier from the signature of the qualification identifier commitment;

[0077] Step 4.P s Verify the signature of the qualification identifier:

[0078] (4.1) If the verification passes, continue to step (4.2); otherwise, proceed directly to step (4.3).

[0079] (4.2) Randomize the signature using the randomizable signature scheme algorithm, and send the eligibility identifier, the randomized signature, and the first time difficulty T1 to the asset recipient P. r .

[0080] The eligibility identifier is a random number, representing the asset recipient P. r To the third-party payment center P h The authorization credentials used to initiate the request, and they are used only once.

[0081] (4.3) Wait for the transfer lock phase to end, and then begin the puzzle commitment phase, i.e., execute step (5);

[0082] Step 5. Asset recipient P r With third-party payment center P h Follow these steps to execute the Puzzle Commitment Agreement:

[0083] (5.1)P r Send the qualification identifier and the randomized signature to P. h ;

[0084] (5.2)P h Verify the randomized signature. If the verification passes, proceed to step (5.3); otherwise, proceed to step (6.4).

[0085] (5.3)P h Initiate execution and P r The joint key generation protocol in the two-party adapter signature scheme, P h and P r Each party receives their respective share's private key and public key, where the public key consists of two parts: the other party's share's public key and the joint public key.

[0086] (5.4)P r Execute a verifiable timed discrete logarithm scheme commitment algorithm on your own share of the private key to generate P. r Shared private key commitment and proof, and P r Set the second time difficulty T2 and send it all to P. h ;

[0087] (5.5)P h Received P r Send P r After committing to and proving your share of the private key, proceed with the following steps:

[0088] (5.5.1) Verify P r Shared private key commitment; if verification passes, forced opening of P will begin. r If the share of the private key is committed, proceed to step (5.5.2); otherwise, proceed to step (6.4).

[0089] (5.5.2) Transfer v amount of assets on B2 to the federated public key address to complete the asset locking transaction;

[0090] (5.5.3) Take a random number as evidence, calculate the evidence statement, execute the encryption algorithm in the linear encryption scheme to generate the evidence ciphertext, generate a zero-knowledge proof of the evidence statement and the evidence ciphertext, and then transfer the proof, evidence statement, evidence ciphertext, and P... h Lock transaction identifier sent to P r ;

[0091] The above P s Lock transaction identifier and P h Locked transaction identifiers are used to query locked transactions on the blockchain.

[0092] (5.6) If both zero-knowledge proofs and locked transactions are valid, P r Initiate execution and P h The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P r The public key address processes transactions involving assets of amount v, P. r and P h If both parties receive the joint pre-signature for the transaction, proceed to step (6); otherwise, proceed to step (6.4).

[0093] Step 6.P r Select a random number and perform the following steps:

[0094] (6.1) Multiply the selected random number with the evidence statement to obtain a first-order randomization statement;

[0095] (6.2) Perform the randomization ciphertext algorithm in the linear encryption scheme on the evidence ciphertext to generate a first-order randomized evidence ciphertext with respect to the random number;

[0096] (6.3) Send the first randomization statement and the first randomization evidence ciphertext together to the asset sender P. s ;

[0097] (6.4) Wait for the puzzle commitment phase to end, and then begin the puzzle-solving phase, i.e., execute step (7);

[0098] Step 7. Asset sender P s With third-party payment center P h Follow these steps to execute the puzzle-solving protocol:

[0099] (7.1)P s Select a random number, and obtain the double randomization declaration and double randomization evidence ciphertext for the random number according to steps (6.1)-(6.2), and send both to P. h ;

[0100] (7.2)P h Decrypt the double randomized evidence ciphertext and verify the decryption result. If the verification is successful, continue to step (7.2.1); otherwise, directly execute step (9).

[0101] (7.2.1)P h Initiate execution and P s The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P h The public key address processes transactions involving assets of amount u, P. s and P h All received joint pre-signatures for the transaction.

[0102] (7.2.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the decryption result, the joint pre-signature is converted into P. h Final signature for withdrawal;

[0103] (7.2.3) Publish P on B1 h Withdrawal transactions and P h Final signature for withdrawal, and P h Final signature for withdrawal sent to P s ;

[0104] (7.3)P s By extracting algorithms from the two-party adapter signature scheme, combined with joint pre-signature, P h Extract evidence of double randomization from the final signature and double randomization declaration for withdrawal;

[0105] Step 8. Asset sender P s The random number from step (7.1) is used to perform a restoration operation with the double randomized evidence to obtain single randomized evidence, which is then sent to the asset recipient P. r ;

[0106] Step 9. Wait for the puzzle-solving phase to end, then begin the transition to the completion phase, i.e., execute step (10);

[0107] Step 10. Asset recipient P r To complete the transfer phase, follow these steps:

[0108] (10.1) Use the random number in step (6) and the first randomized evidence obtained in step (8) to perform a restoration operation to obtain the evidence;

[0109] (10.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the evidence, the joint pre-signature obtained in step (5.6) is transformed into P. r Final signature for withdrawal;

[0110] (10.3) Publish P on B2 r Withdrawal transactions and P r Final signature for withdrawal; after the waiting period for transfer completion ends, proceed to step 11.

[0111] Step 11. After entering the transfer timeout phase, complete this phase according to the following situations:

[0112] P s and P h The joint public key address still has a balance: P s During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T1, P is obtained. h The share of the private key is then used to calculate the joint private key based on the two-party adapter signature scheme, generating a public key address from the joint public key address to P. s The redemption transaction for the public key address payment balance is signed, and the redemption transaction and signature are published on B1;

[0113] P h and P r The joint public key address still has a balance: P h During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T2, P is obtained. r The share of the private key is obtained, and then the joint private key is calculated according to the two-party adapter signature scheme. This generates a public key address that sends a message to P. h The redemption transaction for the public key address payment balance is signed, and the redemption transaction and signature are published on B2;

[0114] P s and P h The joint public key address has no balance: P s The waiting timeout period for transfer has ended;

[0115] P h and P r The joint public key address has no balance: Ph The waiting timeout period for the transfer has ended.

[0116] The aforementioned two-party adapter signature scheme includes: a Schnorr-based two-party adapter signature scheme that adds the share private key, and an ECDSA-based two-party adapter signature scheme that multiplies the share private key. Additionally, the two-party adapter signature scheme can be replaced by two two-party protocols: a joint key generation protocol and a joint adapter signature protocol. The joint key generation protocol possesses the functionality of the joint key generation protocol in the two-party adapter signature scheme, while the joint adapter signature protocol possesses all other functions of the two-party adapter signature scheme except for the joint key generation protocol.

[0117] Step 12. Complete a cross-chain transaction within a period T, in which assets are transferred from the first blockchain B1 to the second blockchain B2.

[0118] Example 2: The overall implementation steps of the cross-chain asset transfer method proposed in this example are the same as in Example 1. The technical aspects involved are further explained in detail below:

[0119] (I) Symbol Explanation: The parameter symbols involved in the description of this invention are defined as shown in Table 1.

[0120] Table 1. Symbol Explanation

[0121]

[0122]

[0123] For convenience, the asset address of a blockchain user will be represented by the corresponding signature public key.

[0124] (II) This invention relates to nine aspects of related technologies, including ignorable functions, difficult relations, digital signature schemes, two-party adapter signature schemes, commitment schemes, non-interactive zero-knowledge proof schemes, randomizable signature schemes, linear-only encryption schemes, and verifiable timed discrete logarithm schemes. These are described in detail below:

[0125] a) Negligible function

[0126] If, as the safety parameter increases, the function approaches zero faster than the reciprocal of any positive polynomial approaches zero, then the function is said to be negligible.

[0127] b) Hard relationship

[0128] A relation is considered difficult if the following conditions are met. In this invention, a statement of evidence and evidence constitute a difficult relation, which is a relation R that satisfies the following conditions:

[0129] (a) There exists a probabilistic multinomial-time algorithm GenR such that (Y,y)←GenR(1 λ And satisfy (Y,y)∈R; where Y represents the evidence statement, y represents the evidence, and λ represents the security parameter;

[0130] (b) It is possible to determine whether (Y,y)∈R holds true in polynomial time;

[0131] (c) For any probabilistic polynomial-time adversary, the probability of calculating evidence y from statement Y is negligible.

[0132] c) Digital signature schemes

[0133] A digital signature scheme Π S It consists of three algorithms: KeyGen (key generation algorithm), Sign (signature algorithm), and Verify (signature verification algorithm); where (pk, sk) ← KeyGen (1 λ ), (pk, sk) are the public and private key pair for signing, and λ represents the security parameter; for the message space For any message m, generate a digital signature σ←Sign(sk,m), where σ can be publicly verified, i.e., b:=Verify(pk,m,σ); if the verification passes, output b=1, otherwise output b=0. The digital signature scheme used in this invention satisfies the requirement of signature non-forgeability.

[0134] d) Two-party adapter signature schemes

[0135] A question about difficult relationships R and digital signatures Π S Two-party adapter signature scheme П 2AS It consists of 5 protocols or algorithms.

[0136] ① Two participants, P1 and P2, can obtain key information by running a joint key generation protocol, that is...

[0137] ({(sk P1 ,pk P2 ,pk),⊥},{(sk P2 ,pk P1 ,pk),⊥})←JointKeyGen<P1(),P2()> .

[0138] Where (sk)P1 ,pk P1 ) and (sk P2 ,pk P2 These are the share public / private key pairs for P1 and P2, respectively, and pk is the share private key sk. P1 and SK P2 The joint public key.

[0139] ② P1 and P2 run the joint presignature protocol to obtain message m regarding the presignature of statement Y0. Right now

[0140]

[0141] ③ Public verification is possible through pre-verification algorithms. Right now Specifically, if the verification passes, output b = 1; otherwise, output b = 0.

[0142] ④ Through the adaptation algorithm, the evidence y0 corresponding to input Y0 and The final signature σ can be obtained, that is

[0143] ⑤ Through the extraction algorithm, under normal circumstances, the evidence y0 corresponding to Y0 can be obtained, that is...

[0144] The two-party adapter signature scheme used in this invention satisfies the following requirements: pre-signature correctness, adapter signature non-forgeability, pre-signature adaptability, and evidence extractability.

[0145] e) Commitment schemes

[0146] A commitment scheme consists of two algorithms: Commit and Verify. The prover can generate a commitment com for message m using Commit, i.e., (com, decom) ← Commit(m), where decom is the verification information. The verifier can verify whether message m has been committed using Verify, i.e., b := Verify(com, decom, m). Specifically, if the verification passes, b = 1 is output; otherwise, b = 0 is output. The commitment scheme used in this invention satisfies concealment and binding properties.

[0147] f) Non-interactive zero-knowledge proof schemes

[0148] A non-interactive zero-knowledge proof scheme Π NIZKThe algorithm consists of three parts: Setup, Prove, and Verify. Setup generates a common reference string crs and a trapdoor τ from a hard relation R, i.e., (crs,τ)←Setup(R). The prover runs Prove to obtain a proof π for the statement x, i.e., π←Prove(crs,w,x), where (x,w)∈R. The proof π is verifiable, i.e., b:=Verify(crs,π,x). Specifically, if the verification passes, b=1; otherwise, b=0. The non-interactive zero-knowledge proof scheme used in this invention satisfies reliability and zero-knowledge requirements. For convenience, the Prove and Verify algorithms mentioned below will default to input crs and will not be described further.

[0149] g) Randomizable signature schemes

[0150] A randomizable signature scheme П RS It consists of 7 algorithms, 3 of which can form a common digital signature scheme, including the key generation algorithm KeyGen, the signature algorithm Sign, and the signature verification algorithm Verify. The other 4 algorithms are described below.

[0151] ① The commitment algorithm can generate a commitment com for the user about message m, that is, (com, decom) ← Commit(m).

[0152] ② The signer runs the signature commitment algorithm to generate a signature for the user's commitment, i.e., σ. com ←SignCom(sk RS ,com), where sk RS This is the signer's private key.

[0153] ③ The user can obtain the signature of message m by running the signature extraction algorithm, that is, σ←Ext(decom,σ com ).

[0154] ④ The user can obtain a random signature for message m by running the randomized signature algorithm, i.e., σ'←RandSign(σ).

[0155] The commitments and signatures generated by the randomizable signature scheme used in this invention satisfy the same security properties as both the commitment scheme and the digital signature scheme.

[0156] h) Linear-only encryption schemes

[0157] A linear encryption scheme Π LOEIt consists of four algorithms: KeyGen (key generation algorithm), Enc (encryption algorithm), RandEnc (randomization ciphertext algorithm), and Dec (decryption algorithm). Running KeyGen generates a public-private key pair for encryption, i.e., (pk... L ,sk L )←KeyGen(1 λ Running the encryption algorithm generates the ciphertext c corresponding to the plaintext m, i.e., c ← Enc(pk). L Under normal circumstances, running the decryption algorithm Dec can extract the plaintext m corresponding to the ciphertext c, that is, {m, ⊥} := Dec(sk L c). The randomized ciphertext algorithm can generate a random ciphertext c' of ciphertext c with respect to a random number r, i.e., c'←RandEnc(c,r). The linear-only encryption scheme used in this invention satisfies OM-CCA-A2L security.

[0158] i) Verifiable timed discrete logarithm schemes

[0159] A verifiable timed discrete logarithmic scheme ∏ VTD It consists of four algorithms: Commit, Verify, Open, and ForceOp.

[0160] ① The committer runs the commitment algorithm to generate a certain integer. The time complexity is T for the commitment and proof, i.e., (C,π)←Commit(x,T).

[0161] ② The verifier runs the Verify algorithm to determine whether x is contained in C and H = g. x That is, b:=Verify(H,C,π). Specifically, if the verification passes, output b=1, otherwise output b=0. H is sent by the committer to the verifier.

[0162] ③ The committer can run the Open algorithm at any time, i.e. (x,r)←Open(C), where r is the implicit input information in step ①.

[0163] ④ The verifier can only open C after running the ForceOp algorithm for a period of time T, i.e., x←ForceOp(C).

[0164] The verifiable timed discrete logarithmic scheme used in this invention satisfies both reliability and privacy requirements.

[0165] Example 3: The overall implementation steps of the cross-chain asset transfer method proposed in this example are the same as in Example 1. Now, based on Example 2, specific operation steps are given to further describe the implementation process of this invention:

[0166] Step A: P s and P h Execute the transfer lock protocol:

[0167] 1.1)P s Initiate execution

[0168]

[0169] Under normal circumstances, P s and P h Received respectively and Otherwise, terminate.

[0170] 1.2)P h implement And send (C1,π1) to P s .

[0171] 1.3)P s Perform the following steps.

[0172] like Then terminate. Begin solving Π. VTD .ForceOp(C1). Generates a lock transaction signature. Will Published to B1, obtained transaction identifier Select qualification identifier tid← $ Z q And promises (com,decom)←Π RS .Commit(tid). Generates a statement of commitment.

[0173]

[0174] And the proof of the statement π B ←Π NIZK .Prove(decom,tid,st B ).Will Send to P h .

[0175] 1.4)P h Perform the following steps.

[0176] If Π NIZK .Verify(π B ,st B If ) ≠ 1, then the process terminates. If it has already been received, then the process will terminate. If not confirmed on B1, the process terminates. Generate a signature for the eligibility commitment. And send to P s .

[0177] 1.5)P s Extract qualification identifier signature σ tid ←Π RS .ExtSign(decom,σ com ).

[0178] Step B: P s Perform the following steps.

[0179] like Then it terminates. Randomized signature σ' tid ←Π RS .RandSign(σ tid ). tid T1 and T1 are sent to P r .

[0180] Step C: P h and P r Enforcing the Puzzle Commitment Agreement:

[0181] 3.1)P r (tid,σ') tid Send to P h .

[0182] 3.2)P h Perform the following steps.

[0183] If tid has already been received, then the process terminates. Then terminate. Initiate execution. Under normal circumstances, P h and P r Received respectively and Otherwise, terminate.

[0184] 3.3)P r implement And send (C2,π2) to P h .

[0185] 3.4)P h Perform the following steps.

[0186] like Then terminate. Begin solving Π. VTD .ForceOp(C2). Generates a lock transaction signature. Will Published to B2, obtained transaction identifier Select evidence s← $ Z q The declaration of computational evidence Y:=s·g. Encrypted evidence Generate statements of evidence and encrypted text. And proof of the statement Will Send to P r .

[0187] 3.5)P r Perform the following steps.

[0188] If Π NIZK .Verify(π E ,st E If ) ≠ 1, then the process terminates. If no confirmation is received on B2, the process will terminate. Initiate the following operation:

[0189]

[0190] Under normal circumstances, P r and P h All received Otherwise, terminate.

[0191] Step D: P r Perform the following steps.

[0192] Select r'← $ Z q And randomize the declaration Y':=r'·Y and the ciphertext c'←Π LOE .RandEnc(c,r'). Sends (Y',c') to P s .

[0193] Step E: P s and P h Execute the puzzle-solving protocol:

[0194] 5.1)P s Perform the following operations:

[0195] Select r”← $ Z q And randomize the declaration Y”:=r”·Y' and the ciphertext c”←Π LOE .RandEnc(c',r”). Sends (Y”,c”) to P h ;

[0196] 5.2)P h Perform the following operations:

[0197] Decryption If Y”≠s”·g, then terminate. Initiate the following operations:

[0198]

[0199] Under normal circumstances, P s and P h All received Otherwise, terminate. Calculate the final transaction signature. Post a withdrawal transaction on B1 Will Send to P s .

[0200] 5.3)P s Perform the following operations

[0201] Extracting randomized evidence Under normal circumstances, 's' can be obtained; otherwise, the process terminates. s Calculate the randomized evidence s' = s”·(r”) -1 And send to P r ;

[0202] Step F: P r Extracting evidence s = s'·(r') -1 Calculate the final transaction signature Post withdrawal transactions on B2

[0203] Step G: If P s and P h If the joint public key address still has a balance, then P s Perform the following steps. Forcefully acquire P h private key Calculate the federated private key from the share private key:

[0204]

[0205] The implementation of GetJointSk here can be adjusted according to the specific two-party adapter signature scheme. For example, the GetJointSk function based on the Schnorr two-party adapter signature scheme can perform addition on the share private key, while the GetJointSk function based on the ECDSA two-party adapter signature scheme can perform multiplication on the share private key. Generate redemption transaction signature. And publish redemption transactions on B1

[0206] If P h and P r If the joint public key address still has a balance, then P h Perform the following steps. Forcefully acquire Pr private key Calculate the federated private key from the share private key Generate redemption transaction signature And post withdrawal transactions on B2

[0207] To highlight the beneficial effects of the present invention, the following further explains the five properties of the present invention:

[0208] Compared to existing cross-chain asset transfer solutions, this invention possesses the following five properties, thereby solving the problems of user privacy leakage, lack of ease of use and universality in existing work.

[0209] Indistinguishability: Transactions involving cross-chain asset transfers cannot be distinguished from ordinary on-chain transactions by on-chain observers.

[0210] Unlinkability: The sender and receiver of an asset cannot be linked together by others.

[0211] Compatibility: The block structure of the interconnected blockchain does not need to be modified.

[0212] Heterogeneity: The technical implementations of interconnected blockchains can be the same or different.

[0213] Minimum functional requirements: Only the interconnected blockchain is required to support the minimum on-chain function of signature verification.

[0214] The following analysis demonstrates that this invention can achieve the above five properties:

[0215]

I

[0216] Cross-chain transactions include six types of transaction messages, namely and The format of each type of transaction message is consistent with the format of in-chain transaction messages.

[0217] Cross-chain transactions include two types of signatures, one of which is... The signature is the same as the digital signature used by the underlying blockchain. Another type is... and The signature is generated by a two-party adapter signature scheme and is consistent with the digital signature format used by the underlying blockchain.

[0218] Since the two parts of the two transactions are indistinguishable, it is impossible for an on-chain observer to distinguish between cross-chain transactions and on-chain transactions.

[0219] [II] Inability to Link: In this invention, P s and the corresponding P rThe risk of being linked comes from two types of entities, namely P h And on-chain observers. The following describes the linking methods for these two types of entities and the defense methods of this scheme.

[0220] The first type: P h During the transfer locking phase, P is... s Generate a signature of the commitment for tid, and receive P during the puzzle commitment phase. r The tid and its signature sent, P h They will try to associate the two signatures through tid, and then link P. s and the corresponding P r However, due to the hidden nature of the commitment mechanism and the randomness of the randomizable signature scheme, the commitment and its signature will not reveal any information about tid. r The sent tid and its signature are verifiable, so P h It is impossible to associate two signatures through tid.

[0221] The second type: P h respectively with P r and P s Given shared puzzles (Y,c) and (Y”,c”), therefore P h It will try to find the relationship between (Y,c) and (Y”,c”), and then link P. s and the corresponding P r However, because (Y”,c”) is obtained by performing some kind of composite operation on (Y,c) and a random number, when there are multiple pairs of P… s and P r When it exists, P h It is impossible to associate every pair of P s and P r Two puzzles with a random relationship.

[0222] The third type: P h They will try to eavesdrop on P s or P r External communication, and thus link P s and the corresponding P r However, because the plan assumes P s and P r The communication channel between them is anonymous, so P h It is impossible to obtain P s and P r The communication relationship between them.

[0223] The fourth type: P h It will record the participants in various protocols and algorithms and their key moments, linking to P. s and the corresponding P rFor example, a participant who completes the previous protocol earlier may have a link to a participant who starts the next protocol earlier. However, because the scheme assumes that the protocols and algorithms are executed in stages, participants have flexible protocol initiation times and a sufficiently long protocol completion time independent of the underlying blockchain, therefore P h It is impossible for the parties to link P based on differences in timeliness in the agreement. s and the corresponding P r .

[0224] Fifth: On-chain observers will link P through the number of transaction assets on the interconnected blockchain. s and the corresponding P r For example, the sender of a transaction with asset quantity u on B1 might have a link relationship with the receiver of a transaction with asset quantity v on B2. However, the scheme assumes that within a given period, all asset senders send the same amount of assets, and all asset receivers receive the same amount of assets. Therefore, when there are multiple pairs of P... s and P r When it exists, on-chain observers cannot link P through the number of transaction assets on the interconnected blockchain. s and the corresponding P r .

[0225] In summary, P in this invention s and the corresponding P r It cannot be linked by others.

[0226]

III

[0227]

IV

[0228] 【5】Minimum Functional Requirements: Since the solution of this invention requires the underlying blockchain to use only one on-chain function, namely the signature verification function, which is the most basic function of the blockchain, the solution meets the minimum functional requirements.

[0229] Compared with existing cross-chain asset transfer solutions, the implementation of the above five properties is shown in Table 2.

[0230] Table 2 Comparison of Cross-Chain Asset Transfer Schemes

[0231] Indistinguishability N N N N Y Y Unlinkability N N N N Y Y compatibility N Y Y Y Y Y Heterogeneity Y N Y Y N Y Minimum functional requirements N N N Y N Y

[0232] Where: Y indicates that the condition is met, and N indicates that the condition is not met; [*] represents a custom prior art document number, and the corresponding prior art documents are listed below:

[0233] [1]Kiayias A,Zindros D.Proof-of-work sidechains[C] / / InternationalConference on Financial Cryptography and Data Security.2019:21-34.

[0234] [2]Garoffolo A, Kaidalov D, Oliynykov R.Zendoo: a zk-SNARK verifiable cross-chain transfer scheme enabling decoupled and decentralized sidechains[C] / / 2020IEEE 40th International Conference on Distributed Computing Systems(ICDCS).IEEE,2020:1257-1262.

[0235] [3] P,Kiayias A,Zindros D.Proof-of-stake sidechains[C] / / 2019IEEESymposium on Security andPrivacy(SP).IEEE,2019:139-156.

[0236] [4] Yan Minmin. A method, apparatus, device and storage medium for cross-chain asset transfer [P]. Beijing: CN113781228A, 2021-12-10.

[0237] [5] Qian Jin, Min Xinping, Zhang Yubo, Zheng Yongqing, Li Qingzhong, Wang Minxia, ​​Yi Li, Jin Runyu, Yu Junfeng, Zhou Xuan. A method and system for cross-chain transfer of assets without affecting the normal execution of related asset transactions [P]. Shandong Province: CN115601164A, 2023-01-13.

[0238] [6] Huang Yan, Ma Dengji, Wang Zhiwen, Wu Sijin. Cross-chain asset transfer methods, computer equipment and storage media [P]. Zhejiang Province: CN115660853A, 2023-01-31.

[0239] [7] Wang Xiaoyi, Cai Liang, Li Ruiyang, Qiu Weiwei, Zhang Shuai. A method, device, electronic device and medium for cross-chain transfer of digital assets [P]. Zhejiang Province: CN115641121A, 2023-01-24.

[0240] [8]Xie T, Zhang J, Cheng Z, et al.zkBridge: Trustless Cross-chain BridgesMade Practical[C] / / Proceedings of the 2022ACM SIGSAC Conference on Computerand Communications Security.2022:3003-3017.

[0241] [9]Zamyatin A, Harz D, Lind J, et al.

[0242]

[10] Tian H, Xue K, Luo X, et al. Enabling cross-chain transactions: Adecentralized cryptocurrency exchange protocol [J]. IEEE Transactions on Information Forensics and Security, 2021, 16: 3928-3941.

[0243]

[11] Yin Z, Zhang B, Xu J, et al. Bool Network: An Open, Distributed, SecureCross-Chain Notary Platform [J]. IEEE Transactions on Information Forensics and Security, 2022, 17: 3465-3478.

[0244]

[12] Baldimtsi F, Miers I, Zhang X. Anonymous Sidechains[M] / / Data Privacy Management, Cryptocurrencies and Blockchain Technology. Springer, Cham, 2021: 262-277.

[0245] As can be seen from the comparison of the above solutions, the cross-chain asset transfer method proposed in this invention is significantly superior to existing technical solutions and has made remarkable progress.

[0246] The parts of this invention not described in detail are common knowledge to those skilled in the art.

[0247] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Obviously, those skilled in the art, after understanding the content and principle of the present invention, may make various modifications and changes in form and detail without departing from the principle and structure of the present invention. However, these modifications and changes based on the concept of the present invention are still within the scope of protection of the claims of the present invention.

Claims

1. A privacy-preserving cross-chain asset transfer method, characterized in that, Includes the following steps: (1) Establish a system by asset sender P s Asset recipient P r The first blockchain B1, the second blockchain B2, and the third-party payment center P h The cross-chain asset transfer system model consists of the asset sender P. s For users and asset recipients P on the first blockchain B1 r For users on the second blockchain B2; assume P s To be transferred to P r The number of assets on B2 is v, and P s The number of assets on B2 is less than v or there are no asset addresses; Third-party payment center P h Used to assist asset sender P s To achieve the transfer of assets from the first blockchain B1 to the second blockchain B2, where P h There are asset addresses on both the first blockchain B1 and the second blockchain B2, and the amount of assets on the second blockchain B2 is not less than v; third-party payment center P h Received from asset sender P on the first blockchain B1 s The asset quantity is u, and the asset recipient is P. r Received from third-party payment center P on the second blockchain B2 h The total quantity of assets is v, and the value of assets B1 with quantity u is greater than the value of assets B2 with quantity v. The excess value is P. s To P h Service fees paid; (2) Assume that network communication is synchronous and the communication channel is secure and authenticated; asset sender P s and asset recipient P r The communication channels between them are anonymous and cannot be identified by third parties; cross-chain transactions are completed within a period T, otherwise they are invalid; the quantities u and v are constants within a period; the period T is divided into five stages: transfer locking, puzzle commitment, puzzle solving, transfer completion, and transfer timeout, making the period or stage time long enough and independent of the underlying blockchain; (3) Asset sender P s With third-party payment center P h Perform the transfer lock protocol as follows: (3.1)P s Initiating execution and P h The joint key generation protocol in the two-party adapter signature scheme, P s and P h Each party receives their respective share's private key and public key, where the public key consists of two parts: the other party's share's public key and the joint public key. (3.2)P h Execute the commitment algorithm in the verifiable timed discrete logarithm scheme on its own share of the private key to generate P. h Shared private key commitment and proof, and P h Set the initial difficulty to T1 and send all of them to P. s ; (3.3)P s Received P h Send P h After committing and proving your share of the private key, proceed with the following steps: (3.3.1) Verify P h Shared private key commitment; if verification passes, forced opening of P will begin. h If the share of the private key is committed, proceed to step (3.3.2); otherwise, proceed directly to step (4.3). (3.3.2) Transfer u units of assets on B1 to the joint public key address to complete the asset locking transaction; (3.3.3) Randomly select a qualification identifier, execute the commitment algorithm in the randomizable signature scheme on the identifier to generate a qualification identifier commitment, then generate a zero-knowledge proof of the qualification identifier commitment, and combine the zero-knowledge proof, the qualification identifier commitment, and P s Lock transaction identifier sent to P h ; ( 3.4) If both zero-knowledge proofs and locked transactions are valid, P h The signature commitment algorithm in the randomizable signature scheme is applied to the qualification identifier commitment to generate a signature of the qualification identifier commitment, and the signature of the qualification identifier commitment is sent to P. s If not, proceed to step (3.5); otherwise, proceed directly to step (4.3). (3.5)P s Extract the signature of the qualification identifier from the signature of the qualification identifier commitment; (4)P s Verify the signature of the qualification identifier: (4.1) If the verification passes, continue to step (4.2); otherwise, proceed directly to step (4.3). (4.2) Randomize the signature using the randomizable signature scheme algorithm, and send the eligibility identifier, the randomized signature, and the first time difficulty T1 to the asset recipient P. r ; (4.3) Wait for the transfer lock phase to end, and then begin the puzzle commitment phase, i.e., execute step (5); (5) Asset recipient P r With third-party payment center P h Follow these steps to execute the Puzzle Commitment Agreement: (5.1)P r Send the qualification identifier and the randomized signature to P. h ; (5.2)P h Verify the randomized signature. If the verification passes, proceed to step (5.3); otherwise, proceed to step (6.4). (5.3)P h Initiate execution and P r The joint key generation protocol in the two-party adapter signature scheme, P h and P r Each party receives their respective share's private key and public key, where the public key consists of two parts: the other party's share's public key and the joint public key. (5.4)P r Execute a verifiable timed discrete logarithm scheme commitment algorithm on your own share of the private key to generate P. r Shared private key commitment and proof, and P r Set the second time difficulty T2 and send it all to P. h ; (5.5)P h Received P r Send P r After committing to and proving your share of the private key, proceed with the following steps: (5.5.1) Verify P r Shared private key commitment; if verification passes, forced opening of P will begin. r If the share of the private key is committed, proceed to step (5.5.2); otherwise, proceed to step (6.4). (5.5.2) Transfer v amount of assets on B2 to the federated public key address to complete the asset locking transaction; (5.5.3) Take a random number as evidence, calculate the evidence statement, execute the encryption algorithm in the linear encryption scheme to generate the evidence ciphertext, generate a zero-knowledge proof of the evidence statement and the evidence ciphertext, and then transfer the proof, evidence statement, evidence ciphertext, and P... h Lock transaction identifier sent to P r ; ( 5.6) If both zero-knowledge proofs and locked transactions are valid, P r Initiate execution and P h The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P r The public key address processes transactions involving assets of amount v, P. r and P h If both parties receive the joint pre-signature for the transaction, proceed to step (6); otherwise, proceed to step (6.4). (6)P r Select a random number and perform the following steps: (6.1) Multiply the selected random number with the evidence statement to obtain a first-order randomization statement; (6.2) Perform the randomization ciphertext algorithm in the linear encryption scheme on the evidence ciphertext to generate a first-order randomized evidence ciphertext with respect to the random number; (6.3) Send the first randomization statement and the first randomization evidence ciphertext together to the asset sender P. s ; (6.4) Wait for the puzzle commitment phase to end, and then begin the puzzle-solving phase, i.e., execute step (7); (7) Asset sender P s With third-party payment center P h Follow these steps to execute the puzzle-solving protocol: (7.1)P s Select a random number, and obtain the double randomization declaration and double randomization evidence ciphertext for the random number according to steps (6.1)-(6.2), and send both to P. h ; (7.2)P h Decrypt the double randomized evidence ciphertext and verify the decryption result. If the verification is successful, continue to step (7.2.1); otherwise, directly execute step (9). (7.2.1)P h Initiate execution and P s The joint pre-signature protocol in the two-party adapter signature scheme, for the joint public key address to P h The public key address processes transactions involving assets of amount u, P. s and P h All received joint pre-signatures for the transaction. (7.2.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the decryption result, the joint pre-signature is transformed into P. h Final signature for withdrawal; (7.2.3) Publish P on B1 h Withdrawal transactions and P h Final signature for withdrawal, and P h Final signature for withdrawal sent to P s ; ( 7.3)P s By extracting algorithms from the two-party adapter signature scheme, combined with joint pre-signature, P h Extract evidence of double randomization from the final signature and double randomization declaration for withdrawal; (8) Asset sender P s The random number from step (7.1) is used to perform a restoration operation with the double randomized evidence to obtain single randomized evidence, which is then sent to the asset recipient P. r ; (9) Wait for the puzzle-solving phase to end, and then begin the transition to the completion phase, i.e., execute step (10); (10) Asset recipient P r To complete the transfer completion phase, follow these steps: (10.1) Use the random number in step (6) and the first randomized evidence obtained in step (8) to perform a restoration operation to obtain the evidence; (10.2) Using the adaptation algorithm in the two-party adapter signature scheme, combined with the evidence, the joint pre-signature obtained in step (5.6) is transformed into P. r Final signature for withdrawal; (10.3) Publish P on B2 r Withdrawal transactions and P r Final signature for withdrawal, wait for the transfer completion period to end, and proceed to step (11); (11) After entering the transfer timeout stage, complete this stage according to the following situations: P s and P h The joint public key address still has a balance: P s During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T1, P is obtained. h The share of the private key is then used to calculate the joint private key based on the two-party adapter signature scheme, generating a public key address from the joint public key address to P. s The redemption transaction for the public key address payment balance is signed, and the redemption transaction and signature are published on B1; P h and P r The joint public key address still has a balance: P h During the execution of the forced-open algorithm for the verifiable timed discrete logarithmic scheme for duration T2, P is obtained. r The share of the private key is obtained, and then the joint private key is calculated according to the two-party adapter signature scheme. This generates a joint public key address that sends a message to P. h The redemption transaction for the public key address to pay the balance is signed, and the redemption transaction and signature are published on B2; P s and P h The joint public key address has no balance: P s The waiting timeout period for transfer has ended; P h and P r The joint public key address has no balance: P h The waiting timeout period for transfer has ended; (12) Complete a cross-chain transaction in which assets are transferred from the first blockchain B1 to the second blockchain B2 within a cycle T.

2. The method according to claim 1, characterized in that: The eligibility identifier in steps (3)-(5) is a random number, representing the asset recipient P. r To the third-party payment center P h The authorization credentials used to initiate the request, and they are used only once.

3. The method according to claim 1, characterized in that: The restoration operation in steps (8) and (10.1) refers to multiplying the single or double randomized evidence with the multiplicative inverse of the random number.

4. The method according to claim 1, characterized in that: The evidence in steps (5)-(10) is all random numbers. The evidence statement and the evidence constitute a difficult relationship, which is a relationship R that satisfies the following conditions: ① There exists a probabilistic multinomial-time algorithm GenR such that (Y, y) ← GenR(1 λ And satisfy (Y, y)∈R; where Y represents the evidence statement, y represents the evidence, and λ represents the security parameter; ② It is possible to determine whether (Y, y)∈R holds true in polynomial time; ③ For any probabilistic polynomial-time adversary, the probability of calculating y from Y is negligible.

5. The method according to claim 1, characterized in that: A digital signature scheme, satisfying the requirement of signature non-forgeability, consists of three algorithms: KeyGen (key generation algorithm), Sign (signature algorithm), and Verify (signature verification algorithm); where (pk, sk) ← KeyGen (1 λ (pk, sk) are the public and private key pair for signing, and λ represents the security parameter; for the message space For any message m, generate a digital signature σ←Sign(sk, m). σ can be publicly verified, i.e., b := Verify(pk, m, σ). If the verification is successful, output b = 1; otherwise, output b = 0.

6. The method according to claim 1, characterized in that: The two-party adapter signature scheme mentioned in step (11) includes: a Schnorr-based two-party adapter signature scheme that adds the share private key, and an ECDSA-based two-party adapter signature scheme that multiplies the share private key; in addition, the two-party adapter signature scheme can also be replaced by two two-party protocols, namely a joint key generation protocol and a joint adapter signature protocol, wherein the joint key generation protocol has the functions of the joint key generation protocol in the two-party adapter signature scheme, and the joint adapter signature protocol has the other functions in the two-party adapter signature scheme except for the joint key generation protocol.

7. The method according to claim 1, characterized in that: The verifiable timed discrete logarithm scheme consists of four algorithms: Commit, Verify, Open, and ForceOp, and satisfies both reliability and privacy requirements. ① The committer runs the commitment algorithm to generate an integer. The time difficulty is T for the commitment and proof, i.e. (C, π) ← Commit(x, T); ② The verifier runs the Verify algorithm to determine whether x is contained in C and H = g. x That is, b := Verify(H, C, π). If the verification passes, output b=1, otherwise output b=0, where H is sent by the promiser to the verifier. ③ The committer runs the Open algorithm at any time, i.e. (x, r) ← Open(C), where r is the input information implicit in step ①; ④ The verifier can only open C after running the ForceOp algorithm for a period of time T, i.e., x←ForceOp(C).

8. The method according to claim 1, characterized in that: The generation and verification of the zero-knowledge proof are accomplished by a non-interactive zero-knowledge proof scheme. This scheme satisfies reliability and zero-knowledge requirements and consists of three algorithms: Setup, Prove, and Verify. Setup generates a common reference string crs and a trapdoor τ from a hard relation R, i.e., (crs, τ) ← Setup(R). The prover runs Prove to obtain a proof π for the declaration x, i.e., π ← Prove(crs, w, x), where (x, w) ∈ R. π is verified, i.e., b := Verify(crs, π, x). If the verification passes, b = 1 is output; otherwise, b = 0 is output. The Prove and Verify algorithms default to input crs.

9. The method according to claim 1, characterized in that: The randomizable signature scheme consists of 7 algorithms, 3 of which can form a common digital signature scheme, including the key generation algorithm KeyGen, the signature algorithm Sign, and the signature verification algorithm Verify. The other 4 algorithms are as follows: 1) The commitment algorithm generates a commitment com for the user about message m, i.e. (com, decom) ← Commit(m); 2) The signer runs the signature commitment algorithm to generate a signature for the user's commitment, i.e., σ. com ←SignCom(sk RS ,com), where sk RS The signer's private key; 3) The user runs the signature extraction algorithm to obtain the signature of message m, i.e., σ←Ext(decom, σ com ); 4) The user runs the randomized signature algorithm to obtain a random signature of message m, i.e., σ′←RandSign(σ).

10. The method according to claim 1, characterized in that: The linear encryption scheme consists of a key generation algorithm KeyGen, an encryption algorithm Enc, a randomization ciphertext algorithm RandEnc, and a decryption algorithm Dec. The key generation algorithm is used to generate encrypted public-private key pairs, i.e., (pk L ,sk L )←KeyGen(1 λ The encryption algorithm is used to generate the ciphertext c corresponding to the plaintext m, i.e., c ← Enc(pk). L The decryption algorithm is used to extract the plaintext m corresponding to the ciphertext c, i.e., {m, ⊥} := Dec(sk L ,c); The randomized ciphertext algorithm is used to generate random ciphertext c′ with respect to random number r, i.e., c′←RandEnc(c,r).

Images