Cross-chain digital asset transaction method, transmission protocol and system

Abstract

This application provides a cross-chain digital asset transaction method, transmission protocol, and system, wherein the method includes: a source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset; the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to a target chain, and triggers a second contract on the target chain according to the digital asset transaction request; after determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates a target digital asset on the target chain, and, if a first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, completing the transaction of the target digital asset. This application solves the problem of being unable to effectively protect the privacy of cross-chain digital asset transactions.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a cross-chain digital asset transaction method, transmission protocol, and system. Background Art

[0002] Currently, most cross-chain digital asset transaction solutions rely on the Simplified Payment Verification (SPV) mechanism. This is typically implemented using the following steps: 1) Users lock assets on the source chain; 2) Operation information is transmitted to the target chain via a cross-chain relay or bridge protocol; 3) A mapped asset of equivalent value is generated on the target chain. Due to the need for privacy protection in digital asset transactions, related technologies include obfuscated transaction paths, address obfuscation, and preliminary zero-knowledge proofs to mitigate the risk of privacy leaks.

[0003] However, there are the following technical problems when using the above-mentioned existing technologies for transactions: transaction information is public. Existing solutions will disclose key information such as transfer amounts and user addresses on the chain, allowing external observers to associate the two parties to the transaction through on-chain data; the risk of correlation analysis is high. Due to the lack of effective anonymity processing measures, the fixed format and continuous status updates on the chain are easy to track; privacy protection is insufficient. Although some solutions based on zero-knowledge proof can verify legitimacy, it is difficult to achieve complete decoupling of input and output in cross-chain scenarios, and it is impossible to completely block the correlation between on-chain transactions.

[0004] Therefore, there is a problem in the related technologies that the privacy of cross-chain digital asset transactions cannot be effectively protected. Summary of the Invention

[0005] This application provides a cross-chain digital asset transaction method, transmission protocol, and system to at least solve the problem in related technologies that the privacy of cross-chain digital asset transactions cannot be effectively protected.

[0006] According to one aspect of an embodiment of the present application, a cross-chain digital asset transaction method is provided, comprising:

[0007] The source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset;

[0008] The cross-chain transfer protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers the second contract on the target chain according to the digital asset transaction request;

[0009] After determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and, if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, completing the transaction of the target digital asset.

[0010] Alternatively, as described above:

[0011] After the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the method further includes: the source chain calling a hash function in the first contract to hash at least one random number to obtain a random number hash value, and obtaining a hash tree with the random number hash value as a leaf node, a root hash value of the hash tree, and a path proof based on the random number hash value;

[0012] The cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, including: the cross-chain transmission protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, wherein the first transaction parameters are parameters included in the digital asset transaction request, and the target digital asset parameters include at least a first hash value corresponding to the first random number of the at least one random number;

[0013] The associating the target digital asset on the target chain with the second user account if a first zero-knowledge proof constructed according to the target digital asset parameters is verified to be successful includes: the target chain processes private input and public input through a target arithmetic circuit to obtain a first zero-knowledge proof that satisfies constraints of the target arithmetic circuit, wherein the public input includes the root hash value and the first hash value, and the private input includes the at least one random number and the path proof; and if the first zero-knowledge proof is verified to be successful, associating the target digital asset with the second user account.

[0014] Optionally, as in the aforementioned method, the cross-chain transfer protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, including:

[0015] The cross-chain transfer protocol executes the asset status update function of the second contract on the target chain indicated by the first transaction parameter, identifies the first hash value in the obtained target digital asset parameter as to be traded, obtains the target digital asset parameter, and transmits the target digital asset parameter to the target chain;

[0016] After completing the transaction of the target digital asset, the method further includes: the target chain marking the first hash value as having been traded.

[0017] Optionally, as in the aforementioned method, the constraint conditions include:

[0018] The verification hash value obtained by hashing the random number to be verified in the private input is consistent with the public input;

[0019] Through the root hash value in the public input and the path proof in the private input, it is determined that the random number hash values ​​generated by all random numbers in the private input are leaf nodes of the hash tree.

[0020] Optionally, as in the aforementioned method, when the digital asset transaction request is a digital asset transfer request, before the target chain obtains the target digital asset parameters, the method further includes:

[0021] The source chain destroys the target digital asset on the source chain if a second zero-knowledge proof constructed based on the target digital asset parameters passes verification, including: the source chain processes the private input and the public input through a target arithmetic circuit to obtain a second zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the public input includes the root hash value and the first hash value, the private input includes the at least one random number and the path proof, and the target digital asset is a digital asset of a target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes verification, executing a digital asset destruction function to delete the target digital asset on the source chain and mark the first hash value on the source chain as destroyed;

[0022] The cross-chain transfer protocol triggers a digital asset destruction event in the second contract on the target chain based on the obtained first hash value marked as destroyed;

[0023] The target chain obtains the target digital asset parameters, including: the target chain obtains the target digital asset parameters when determining the digital asset destruction event.

[0024] Optionally, as in the aforementioned method, when the digital asset transaction request is a digital asset exchange request, before the first zero-knowledge proof constructed according to the target digital asset parameters is verified, the method further includes:

[0025] The target chain calls the hash function in the second contract to hash at least one new random number to obtain a new random number hash value, obtains a new hash tree with the new random number hash value as a leaf node, a root hash value of the new hash tree, and a new path proof based on the new random number hash value, obtains the public key generated by the second user account, and transmits purchase parameters to the cross-chain transfer protocol, wherein the purchase parameters include: the public key and the first hash value marked as purchased;

[0026] The cross-chain transfer protocol executes the asset status update function on the source chain according to the purchase parameters, identifies the first hash value as purchased through the asset status update function on the source chain, and transmits the first hash value identified as purchased and the public key to the source chain;

[0027] After determining the purchase event triggered by the second contract, the first user account on the source chain obtains the first hash value indicating the purchase and the public key, and if a third zero-knowledge proof constructed based on the first hash value indicating the purchase passes verification, extracts a digital asset unit consistent with the value of the target digital asset from the first contract, wherein the digital asset unit originally belonged to the second user account and is a digital asset of the target denomination unit from at least one candidate denomination unit.

[0028] Optionally, as in the aforementioned method, when the first zero-knowledge proof constructed according to the target digital asset parameters passes verification, associating the target digital asset with the second user account includes:

[0029] After processing the first designated private input and the first designated public input by the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit is obtained, wherein the first designated public input includes the root hash value of the new hash tree and the first hash value identified as purchased, and the first designated private input includes the at least one new random number and the new path proof;

[0030] If the first zero-knowledge proof is verified successfully, obtaining the metadata digest and metadata digest hash value transmitted by the cross-chain transfer protocol, wherein the metadata digest is obtained by encrypting the metadata of the target digital asset using a public key;

[0031] Decrypting the metadata summary using the private key corresponding to the public key, and performing hash value calculation on the decrypted data to obtain a metadata summary decryption value;

[0032] If it is determined by performing a comparison operation within a preset time period that the metadata digest decryption value is identical to the metadata digest hash value, the target digital asset is purchased by destroying the digital asset unit, and the target digital asset is associated with the second user account.

[0033] Optionally, as in the aforementioned method, extracting from the second contract a digital asset unit consistent with the value of the target digital asset includes:

[0034] After the source chain processes the second designated private input and the second designated public input through the target arithmetic circuit, it obtains a third zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, extracts the target digital asset from the first contract, and identifies the first hash value as pending withdrawal, so that the first user account cannot withdraw the target digital asset, wherein the second designated public input includes the root hash value of the hash tree and the first hash value identified as pending withdrawal, and the second designated private input includes the second random number of the at least one random number, the asset ID corresponding to the target digital asset, and the path proof;

[0035] If the second user account of the target chain does not feedback within a preset time period that the metadata digest decryption value is different from the metadata digest hash value, the target arithmetic circuit processes the first designated private input and the first designated public input to obtain a fourth zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit, wherein the first designated public input includes the root hash value of the new hash tree and the new random number hash value, and the first designated private input includes the at least one new random number and the new path proof;

[0036] When the third zero-knowledge proof is verified successfully, the source chain extracts the digital asset unit from the contract to the first user account.

[0037] Optionally, as in the aforementioned method, the method further includes:

[0038] If the second user account of the target chain fails to determine that the metadata digest decrypted value is identical to the metadata digest hash value within the preset time period, an inconsistency message is transmitted to the cross-chain transfer protocol;

[0039] The cross-chain transmission protocol transmits the inconsistent message to the source chain;

[0040] The source chain compares the hash value of the metadata of the target digital asset with the metadata digest hash value according to the inconsistency message. If the comparison result indicates that the hash value of the metadata of the target digital asset is inconsistent with the metadata digest hash value, the digital asset unit is returned to the address corresponding to the second user account on the target chain.

[0041] According to another aspect of an embodiment of the present application, a cross-chain digital asset transaction method is also provided, which is applied to a cross-chain transmission protocol, and the method includes:

[0042] When a source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers a second contract on the target chain according to the digital asset transaction request, so that the second user account on the target chain obtains the target digital asset parameters after determining the contract event triggered by the second contract, generates the target digital asset on the target chain, and when the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, and completes the transaction of the target digital asset, wherein the digital asset transaction request is used to request the transaction of the target digital asset.

[0043] Optionally, as in the aforementioned method, the cross-chain transfer protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, including:

[0044] The cross-chain transfer protocol executes the asset status update function of the second contract on the target chain indicated by the first transaction parameter, identifies the first hash value in the obtained target digital asset parameter as to be traded, obtains the target digital asset parameter, and transmits the target digital asset parameter to the target chain;

[0045] After completing the transaction of the target digital asset, the method further includes: the target chain marking the first hash value as having been traded.

[0046] According to another aspect of the embodiments of the present application, a cross-chain digital asset trading system is provided, including:

[0047] A source chain, configured to obtain a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset;

[0048] A cross-chain transmission protocol for transmitting the target digital asset parameters corresponding to the digital asset transaction request to the target chain and triggering the second contract on the target chain according to the digital asset transaction request;

[0049] The target chain is configured to, after determining that the contract event triggered by the second contract is determined, obtain the target digital asset parameters from the second user account on the target chain, generate the target digital asset on the target chain, and, if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associate the target digital asset with the second user account to complete the transaction of the target digital asset.

[0050] According to another aspect of the embodiments of the present application, a transmission protocol for cross-chain digital asset transactions is also provided, which is used to:

[0051] When a source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers a second contract on the target chain according to the digital asset transaction request, so that the second user account on the target chain obtains the target digital asset parameters after determining the contract event triggered by the second contract, generates the target digital asset on the target chain, and when the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, and completes the transaction of the target digital asset, wherein the digital asset transaction request is used to request the transaction of the target digital asset.

[0052] In an embodiment of the present application, a zero-knowledge proof integration approach is employed to obtain a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset. The cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain and triggers a second contract on the target chain according to the digital asset transaction request. After determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and, if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, completing the transaction of the target digital asset. Since the target chain completes the transaction of the target digital asset through zero-knowledge proof during the transaction, the legitimacy of the transaction can be verified without exposing sensitive transaction information (such as the specific amount, real address, and original data), achieving the technical effect of hiding sensitive information and preventing leakage, thereby solving the problem of ineffective privacy protection in cross-chain digital asset transactions in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0055] Figure 1 Schematic diagram of a hardware environment for an optional cross-chain digital asset transaction method according to an embodiment of the present application;

[0056] Figure 2 This is a flow chart of an optional cross-chain digital asset transaction method according to an embodiment of the present application;

[0057] Figure 3 is a schematic diagram of an optional cross-chain digital asset transaction method according to another embodiment of the present application;

[0058] Figure 4 This is a flowchart of an optional cross-chain digital asset transaction method according to another embodiment of the present application;

[0059] Figure 5This is a structural block diagram of an optional cross-chain digital asset trading system according to an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0061] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0062] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0063] A smart contract is a program running on the blockchain, consisting of a series of code (functions) and data (state) located at a specific address on the blockchain. Unlike ordinary accounts, smart contracts are not controlled by humans; instead, they run automatically on the network as programs. Individual users can interact with smart contracts by submitting transactions to execute functions within them. Like traditional contracts, smart contracts can define rules and automatically enforce them through code. By default, once deployed, smart contracts cannot be deleted, and operations interacting with them are irreversible. Smart contracts can reduce single points of failure and centralization risks.

[0064] The public inputs of zk-SNARK's arithmetic circuit include Merkle tree root, NullifierHash, etc., and the private inputs include Secret, Nullifier, Merkle proof, etc.

[0065] According to one aspect of the embodiment of the present application, a cross-chain digital asset transaction method is provided. Optionally, in this embodiment, the cross-chain digital asset transaction method can be applied to Figure 1 In the hardware environment shown in FIG. 1 , which is composed of a terminal 1402 and a server 1404. Figure 1 As shown, server 1404 is connected to terminal 1402 via a network, and can be used to provide services (such as game services, application services, etc.) for the terminal or the client installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 1404.

[0066] The aforementioned network may include, but is not limited to, at least one of the following: a wired network or a wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: a wide area network, a metropolitan area network, or a local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity) or Bluetooth. The terminal may be, but is not limited to, a PC, a mobile phone, or a tablet computer.

[0067] The cross-chain digital asset transaction method of the embodiment of the present application can be executed by a server, a terminal, or a server and a terminal. The terminal can also execute the cross-chain digital asset transaction method of the embodiment of the present application by a client installed on it.

[0068] Taking the cross-chain digital asset transaction method in this embodiment executed by the server as an example, Figure 2 A cross-chain digital asset transaction method provided in an embodiment of the present application is applied to a cross-chain digital asset transaction system and includes the following steps:

[0069] In step S202, the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset.

[0070] The cross-chain digital asset transaction method of this embodiment can be applied to scenarios where digital assets need to be traded across chains, such as: scenarios where digital assets are transferred across chains, scenarios where digital assets are exchanged across chains, etc., and can also be applied to scenarios where digital assets are traded across chains. In the embodiments of this application, the cross-chain digital asset transaction method is described using the transfer and exchange of digital assets across chains as an example. For other types of transaction methods, the cross-chain digital asset transaction method is also applicable if there is no conflict.

[0071] Specifically, when transferring digital assets across chains, assume that User 1 (the first user account) on Chain I (the source chain) sends an amount Vs to User 2 (the second user account) on Chain II (the target chain), where Vs is a standard value. This amount Vs can be one of multiple smaller denominations (e.g., 1, 10, or 100) obtained by dividing a large asset.

[0072] like Figure 3 As shown, initially, User1 issues an asset transfer request by calling the ApplayTransferToken(Commitment, NullifierHash, ChainChainIDs, ChainChainIDt, Vs, CCUpdateTransferStatus) function of the contract on Chain I (that is, Figure 3 The Commitment is obtained by using two random numbers, Secret and Nullifier, through a hash function. Secret is a random number that provides the basis for the anonymity of subsequent transactions and is used to construct an identity that is completely independent of other users and is not disclosed. Nullifier can also be used to generate NullifierHash (also known as the first hash value) through a hash function. The role of NullifierHash is to prevent asset transfer requests from being called multiple times (i.e., double-spending attacks) and to indicate the status of cross-chain asset transfer requests. Vs represents the amount to be sent for cross-chain asset transfer, ChainIDs represents the source chain ID (i.e., source chain identifier), ChainIDt represents the target chain ID (i.e., target chain identifier), and CCUpdateTransferStatus (asset status update function) represents the smart contract function on the target chain to be triggered, which is used to change the status of NullifierHash. NullifierHash has five states: "Revoked", "Pending Destruction", "Destroyed", "Pending Withdrawal", and "Withdrawn". In a cross-chain transfer, the NullifierHash on the initiating chain can only be "Revoked", "Pending Destruction", and "Destroyed", and on the target chain can only be "Pending Withdrawal" and "Withdrawn".

[0073] After the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the method further includes the following steps: the source chain calls a hash function in the first contract to hash at least one random number to obtain a random number hash value, obtains a hash tree with the random number hash value as a leaf node, a root hash value of the hash tree, and a path proof.

[0074] Specifically, the source chain hashes the two random numbers, Secret and Nullifier, using a hash function to generate the random hash value, Commitment. The Commitment is then used as a leaf node in a Merkle tree using the ApplyTransferToken function. This function also obtains the root hash value and path proof of the tree. Vs tokens are transferred to the contract on Chain I (the source chain), storing the NullifierHash status as "pending destruction." A cross-chain operation is then triggered, passing the parameters Vs, ChainIDs, ChainIDt, NullifierHash, and CCUpdateTransferStatus.

[0075] In step S204, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers the second contract on the target chain according to the digital asset transaction request.

[0076] Specifically, a digital asset transaction request carries multiple parameters. The cross-chain transmission protocol can pass the target digital asset parameters in the digital asset transaction request to the target chain. In addition, as needed, the cross-chain transmission protocol can also pass other parameters in the digital asset transaction request to the target chain.

[0077] Alternatively, the cross-chain transfer protocol can transmit the target digital asset parameters corresponding to the digital asset transaction request to the target chain through the following steps: the cross-chain transfer protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, where the first transaction parameters are parameters included in the digital asset transaction request, and the target digital asset parameters include at least a first hash value corresponding to a first random number in at least one random number. In other words, the first random number can be the aforementioned Nullifier, and the first transaction parameters include at least the aforementioned NullifierHash.

[0078] As an optional implementation, as in the aforementioned method, the cross-chain transmission protocol can be implemented by passing the target digital asset parameters obtained based on the first transaction parameters to the target chain through the following steps: the cross-chain transmission protocol executes the asset status update function of the second contract on the target chain indicated by the first transaction parameter, identifies the first hash value in the obtained target digital asset parameters as to be traded, obtains the target digital asset parameters, and passes the target digital asset parameters to the target chain.

[0079] Specifically, the cross-chain protocol performs cross-chain operations, and the target digital asset parameters in the acquisition event may include: ChainIDs, ChainIDt, Vs, CCUpdateTransferStatus, NullifierHash parameters, and executes the CCUpdateTransferStatus (NullifierHash) function of the contract on the target chain Chain II according to ChainIDt (that is, Figure 3 The CCUpdateTransferStatus function will update the NullifierHash (i.e., the first hash value) status to "pending withdrawal (one of the optional pending transaction types)" and trigger the ApplayTransferToken contract event, passing the parameters NullifierHash and Vs to the target chain (i.e., Figure 3 (See step 103). It’s worth noting that the CCUpdateTransferStatus function can only be called by a cross-chain contract or a specific administrator account, and this can be modified based on the adopted cross-chain protocol.

[0080] In step S206, after determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, completing the transaction of the target digital asset.

[0081] Specifically, when the target chain obtains the target digital asset parameters, it can construct a zero-knowledge proof by calling the second contract on the target chain to generate the corresponding Proof. After the zero-knowledge proof is passed, the transaction of the target digital asset can be realized.

[0082] As an optional implementation, as in the aforementioned method, when the digital asset transaction request is a digital asset transfer request, before the target chain obtains the target digital asset parameters, the method further includes: when the source chain passes the verification of the second zero-knowledge proof constructed based on the target digital asset parameters, destroying the target digital asset located on the source chain.

[0083] Furthermore, when the second zero-knowledge proof constructed according to the target digital asset parameters of the above-mentioned source chain is verified to be successful, the destruction of the target digital asset located on the source chain can be achieved by the following method: after the source chain processes the private input and the public input through the target arithmetic circuit, a second zero-knowledge proof that satisfies the constraints of the target arithmetic circuit is obtained, wherein the public input includes a root hash value and a first hash value, the private input includes at least one random number and a path proof, and the target digital asset is a digital asset of a target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof is verified to be successful, the digital asset destruction function is executed to delete the target digital asset located on the source chain, and the first hash value on the source chain is marked as destroyed.

[0084] When a digital asset transaction request is a digital asset transfer request, it simply requests the transfer of the target digital asset from a first user account on the source chain to a second user account on the target chain. In this embodiment, after the first user account determines that the original digital asset transaction request is required, it can split the total asset transaction amount in the original digital asset transaction request to obtain quantities corresponding to each digital asset unit, and then obtain digital asset transfer requests corresponding to each digital asset unit. For example, if the total asset transaction amount is 136, and the digital asset units include denominations of 100, 10, and 1, the split can yield digital asset transfer request I corresponding to 100 (wherein the number of digital asset units with a denomination of 100 is 1), digital asset transfer request II corresponding to 10 (wherein the number of digital asset units with a denomination of 10 is 3), and digital asset transfer request III corresponding to 1 (wherein the number of digital asset units with a denomination of 1 is 6). Finally, digital asset transfer request I is deposited into the target transaction pool corresponding to a digital asset unit denomination of 100, digital asset transfer request II is deposited into the target transaction pool corresponding to a digital asset unit denomination of 10, and digital asset transfer request III is deposited into the target transaction pool corresponding to a digital asset unit denomination of 1. In this embodiment, by splitting large assets into standardized digital asset units with fixed denominations (e.g., 1, 10, 100, etc.), all transactions recorded on the chain only involve transfers of these fixed denominations, effectively avoiding direct exposure of the actual amount, making it impossible to track and thus improving privacy protection.

[0085] That is to say, before the target chain obtains the target asset parameters, the target digital assets on the source chain need to be destroyed to avoid the same asset appearing on two chains, resulting in an increase in assets.

[0086] The target chain obtains the target digital asset parameters, including: the target chain obtains the target digital asset parameters when determining the digital asset destruction event.

[0087] Furthermore, the source chain can delete the target digital asset on the source chain when the second zero-knowledge proof constructed according to the target digital asset parameters is verified and passed through the following steps: after the source chain processes the private input and the public input through the target arithmetic circuit, it obtains a second zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the public input includes a root hash value and a first hash value, the private input includes at least one random number and a path proof, and the target digital asset is a digital asset of a target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof is verified and passed, the digital asset destruction function is executed to delete the target digital asset on the source chain, and the first hash value on the source chain is marked as destroyed.

[0088] Optionally, in the case where the digital asset transaction request is a digital asset transfer request, the constraints may include: the verification hash value obtained by hashing the random number to be verified in the private input is consistent with the public input; and the verification hash value generated by determining, through the root hash value in the public input and the path proof in the private input, that all random numbers in the private input are leaf nodes of the hash tree.

[0089] Specifically, when the second user account User2 on Chain II (i.e., the target chain) determines that the ApplayTransferToken event occurs, it obtains the parameters NullifierHash and Vs and calls the ApplayMintToken (NullifierHash, NewCommitment, Vs) function (i.e., the digital asset generation function) in the contract on Chain II, where NewCommitment is obtained in the same way as Commitment in step 1 (i.e., Figure 3 After ApplayMintToken is executed, User 2 needs to determine the DestroyToken event (i.e., the event corresponding to the execution of the digital asset destruction function), obtain the NullifierHash parameter in the event, and wait for User 1 (i.e., the first user account) on Chain 1 to execute the DestroyToken function (i.e., Figure 3 Step 105 is shown).

[0090] User 1 on Chain 1 executes the DestroyToken(Root, ChainIDs, ChainIDt, NullifierHash, Proof1) function, where Root is the state root of the Merkle tree on Chain 1, and Proof1 is the proof data (i.e., the second zero-knowledge proof) proving that User 1 has stored a fixed-denomination token in the anonymous transaction pool using the ApplayTransferToken method. User 1 has the right to change the NullifierHash state to "destroyed" using the DestroyToken method. To prove that the fixed-denomination token stored in the anonymous transaction pool is indeed User 1, User 1's identity must be verified. In this embodiment, Proof1 must be generated by User 1 locally by executing the Alg1 program (i.e., the target arithmetic circuit) to construct a zk-SNARK proof.

[0091] The Alg1 program is compiled into an arithmetic circuit suitable for zk-SNARK. The public input of the circuit includes the root hash value of the Merkle tree (Root) and the hash value of the Nullifier (NullifierHash), and the private input can include the Nullifier, Secret, and Merkle path proof (Merkle Proof).

[0092] First, the verification hash value obtained by hashing the nonce to be verified in the private input can be consistent with the public input. The arithmetic circuit hashes the private input's Nullifier (i.e., the nonce to be verified) using the MiMC hash algorithm, records the result as the verification hash value, and compares the verification hash value with the public input NullifierHash to verify that the user of the first user account actually knows the preimage of the Nullifier. This process ensures that each transaction is uniquely associated with a Nullifier and prevents the reuse of the same Nullifier through NullifierHash, effectively preventing double-spending attacks.

[0093] Subsequently, using the root hash value in the public input and the path proof in the private input, the circuit determines whether the random number hash value generated by all random numbers in the private input is a leaf node of the hash tree. This can be done by: when all random numbers include a Nullifier and a Secret, the circuit combines the Nullifier and Secret and performs a MiMC hash calculation again to obtain the random number hash value, which is recorded as the leaf node hash value (Leaf Hash) of the Merkle tree (i.e., hash tree). Combining the Merkle tree root hash value (Root) in the public input and the Merkle path proof in the private input, the circuit verifies the existence of the leaf node in the Merkle tree, ensuring that the user's claimed token is legally stored in the anonymous transaction pool. The public input includes the root hash value (i.e., Merkle tree root hash value (Root)) and the first hash value, while the private input includes at least one random number and a path proof.

[0094] Specifically, the verification of Proof1 can be verified by the DestroyToken function. After the verification is passed, the first hash value is marked as destroyed by updating the status of NullifierHash to "destroyed", triggering the cross-chain operation, passing the parameters ChainIDs, ChainIDt, NullifierHash, CCUpdateTransferStatus (that is, Figure 3 (See step 106). Furthermore, if the verification of Proof1 fails, the entire cross-chain transfer process fails. User 1 on Chain 1 can execute DestroyToken(Root, ChainIDs, ChainIDt, NullifierHash, Proof1) again, or choose to call the CancelTx(Root, ChainIDs, ChainIDt, NullifierHash, Proof1) function in the contract on Chain 1 to determine whether the status of NullifierHash is "pending destruction" and verify Proof1. After Proof1 is verified, Vs tokens are extracted from the contract and the status of NullifierHash is changed to "revoked".

[0095] After the source chain marks the first hash value as destroyed, for the cross-chain transfer protocol, the cross-chain transfer protocol can trigger a digital asset destruction event in the second contract on the target chain based on the obtained first hash value marked as destroyed.

[0096] Specifically, the cross-chain protocol executes the cross-chain operation, obtains the ChainIDs, ChainIDt, CCUpdateTransferStatus, and NullifierHash parameters in the event corresponding to the cross-chain operation, and after determining that the target digital asset has been destroyed on the source chain according to the NullifierHash parameter, triggers the DestroyToken event (i.e., digital asset destruction event) in the contract on the target chain Chain II according to ChainIDt, passing the NullifierHash parameter (i.e., Figure 3 (shown as step 107).

[0097] As an optional implementation, the target digital asset parameters can be obtained by the following steps: the target chain obtains the target digital asset parameters when a digital asset destruction event is determined. The target digital asset can be saved in the second user account when a first zero-knowledge proof constructed based on the target digital asset parameters is verified to be successful. The target chain processes the private input and the public input through the target arithmetic circuit to obtain a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the public input includes a root hash value and a first hash value, and the private input includes at least one random number and a path proof; when the first zero-knowledge proof is verified to be successful, the target digital asset is saved in the second user account.

[0098] After the target chain obtains the target digital asset, the method further includes: the target chain identifying the target digital asset parameters as having been traded.

[0099] After obtaining the target digital asset parameters and constructing the corresponding zero-knowledge proof (i.e., the first zero-knowledge proof Proof2) by calling the second contract, the target chain completes the transaction of the target digital asset.

[0100] Specifically, when User2 on Chain II determines that a DestroyToken event occurs, it obtains the parameter NullifierHash (which is Figure 3 Step 108) and call the Withdraw (Root, NullifierHash, Address, Proof2) function in the contract on Chain II (that is, Figure 3The asset extraction function in step 109 shown in the figure), where Root is the root hash value of the Merkle tree on Chain I. Since the above-mentioned target digital assets can be transferred to any address on the target chain, Address is any address on Chain II for receiving Tokens. Proof2 is the proof data used to prove that User2 has stored the above-mentioned target digital assets (for example, fixed-denomination Tokens, that is, Vs tokens) in the anonymous transaction pool through the ApplayMintToken method. User2 has the right to withdraw Vs tokens to the Address account through the Withdraw method and modify the status of NullifierHash to "withdrawn". Proof2 must be constructed by User2 locally by executing Alg1 to generate Proof2 by constructing a zero-knowledge proof. The DestroyToken function will verify Proof2. After the verification is passed, Vs tokens (virtual currency) will be extracted from the contract to the account address Address, the status of NullifierHash will be updated to "withdrawn" and the Withdraw contract event will be triggered (that is, Figure 3 At this point, the target digital asset is saved in the second user account, and the transfer of the target digital asset is completed.

[0101] The following embodiment takes the scenario of exchanging digital assets in a cross-chain situation as an example, and the cross-chain digital asset transaction method in this embodiment is executed by the server. Figure 2 A cross-chain digital asset transaction method provided in an embodiment of the present application is applied to a cross-chain digital asset transaction system and includes the following steps:

[0102] In step S202, the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset.

[0103] like Figure 4 As shown, for example, it is assumed that the first user account User1 in the source chain Chain I generates the target digital asset RWAs (i.e., the target digital asset), the asset ID corresponding to the digital asset RWAs is RWAIDs (RWAIDs is a unique index, which is ensured by technical means to not be repeated), and the value is V. User2 in Chain II destroys V tokens to purchase the target digital asset RWAs generated by User1 in Chain I, and generates a new target digital asset RWAt in Chain II. The asset ID corresponding to the new target digital asset RWAt is RWAIDt, RWAIDs is equal to RWAIDt, and V is the standard value.

[0104] After the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the method further includes the following steps: the source chain calls a hash function in the first contract to hash at least one random number to obtain a random number hash value, obtains a hash tree with the random number hash value as a leaf node, a root hash value of the hash tree, and a path proof.

[0105] In this embodiment, if Figure 4 As shown, User1 issues a request to create an asset by calling the CreateRWA (Commitment, RWAIDs, ChainIDs, ChainIDts, V, CCUpdateExchangeStatus) function (i.e., asset creation function) on Chain I. Figure 4 The target digital asset is created (see step 301). Commitment is generated through a hash function using two random numbers: Secret and Nullifier, and the RWAIDs obtained by creating the RWA. In this embodiment, the at least one random number includes Secret, Nullifier, and RWAIDs. Secret provides the basis for anonymity in subsequent transactions and constructs a completely independent identity from other users, which is not disclosed. Nullifier is used to generate NullifierHash through a hash function. NullifierHash prevents multiple asset exchange requests (i.e., double-spending attacks) and indicates the status of the RWA. RWAIDs prevent multiple asset exchanges (i.e., double-spending attacks). V represents the value of the RWA asset created by User 1. CCUpdateExchangeStatus represents the smart contract function to be triggered on the target chain, which is used to change the status of NullifierHash. NullifierHash has four states: "pending purchase," "purchased," "pending withdrawal," and "withdrawn." The CreateRWA function uses Commitment as the leaf node of the Merkle tree, modifies the status of NullifierHash to "agent purchase", 0 and triggers the cross-chain operation, passing parameters V, ChainIDts, RWAIDs, and CCUpdateExchangeStatus.

[0106] In step S204, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers the second contract on the target chain according to the digital asset transaction request.

[0107] Specifically, a digital asset transaction request carries multiple parameters. The cross-chain transmission protocol can pass the target digital asset parameters in the digital asset transaction request to the target chain. In addition, as needed, the cross-chain transmission protocol can also pass other parameters in the digital asset transaction request to the target chain.

[0108] Optionally, the cross-chain transfer protocol can transmit the target digital asset parameters corresponding to the digital asset transaction request to the target chain through the following steps: the cross-chain transfer protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, wherein the first transaction parameters are parameters included in the digital asset transaction request, and the target digital asset parameters include at least a first hash value corresponding to a first random number in at least one random number. In this embodiment, the first transaction parameters include at least the aforementioned NullifierHash.

[0109] As an optional implementation, as in the aforementioned method, the cross-chain transmission protocol can pass the target digital asset parameters obtained based on the first transaction parameters to the target chain through the following steps: the cross-chain transmission protocol executes the asset status update function of the second contract on the target chain indicated by the first transaction parameter, identifies the first hash value in the obtained target digital asset parameters as to be traded, obtains the target digital asset parameters, and passes the target digital asset parameters to the target chain.

[0110] Specifically, the cross-chain transfer protocol performs cross-chain operations, obtains the ChainIDs, ChainIDts, V, CCUpdateExchangeStatus, and RWAIDs parameters in the event, and obtains the target chain ID (i.e., Figure 4 The target chain identifier) ​​executes the CCUpdateExchangeStatus (NullifierHash) function (i.e., asset status update function) of the contract on the target chain (this example assumes that ChainIDts only contains the ID of Chain II) (i.e., Figure 4 The CCUpdateExchangeStatus function updates the NullifierHash (i.e., the first hash value) to "to be purchased" (i.e., one of the states to be traded), and triggers the CreateRWA contract event, passing the parameters NullifierHash, V (i.e., Figure 4 (See step 303). It’s worth noting that the CCUpdateExchangeStatus function can only be called through a cross-chain contract or a specific administrator account, and this can be modified based on the adopted cross-chain protocol.

[0111] In step S206, after determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, completing the transaction of the target digital asset.

[0112] Specifically, the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and constructs a zero-knowledge proof by calling the second contract on the target chain to generate the corresponding Proof. After the above Proof is verified, the transaction of the target digital asset can be realized.

[0113] In this embodiment, obtaining the target digital asset parameters can be achieved by the following steps: when the second user account User2 on the target chain Chain II determines that the CreateRWA event occurs, it obtains the target digital asset parameters as follows: ChainIDs, NullifierHash and V, and calls the BuyRWA (RWAChainIDt, NullifierHash, NewNullifierHash, NewCommitment, V, ChainIDs, ChainIDt, CCUpdateExchangeStatus, Pukt) function in the contract on Chain II (that is, Figure 4 The asset purchase function in step 304 (shown above) creates a new asset, RWAt (i.e., the target digital asset on the target chain), with the corresponding asset ID being RWAIDt. NewCommitment is similarly derived through a hash function using two new random numbers, Secret and Nullifier, and the RWAIDs obtained by User 1 when creating RWA on Chain 1. Pukt is the public key generated off-chain by User 2 on Chain II using an asymmetric encryption algorithm. ChainIDs represents the ID of Chain 1.

[0114] As an optional implementation, the following steps can be used to implement step S206 in which, when the first zero-knowledge proof constructed based on the target digital asset parameters is verified, the target digital asset on the target chain is associated with the second user account: after the target chain processes the private input and the public input through the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit is obtained, wherein the public input includes a root hash value and a first hash value, and the private input includes at least one random number and a path proof; when the first zero-knowledge proof is verified, the target digital asset is associated with the second user account.

[0115] As an optional implementation, when the digital asset transaction request is a digital asset exchange request, before the first zero-knowledge proof constructed according to the target digital asset parameters is verified, the following steps are further included:

[0116] In step 402, the target chain calls the hash function in the second contract to hash at least one new random number to obtain a new random number hash value, obtains a new hash tree with the new random number hash value as a leaf node, the root hash value of the new hash tree, and a new path proof based on the new random number hash value, obtains the public key generated by the second user account, and transmits purchase parameters to the cross-chain transmission protocol, where the purchase parameters include: the public key and the first hash value marked as purchased.

[0117] Specifically, when the second user account User2 on Chain II determines that the CreateRWA event occurs, it obtains the target digital asset parameters as follows: ChainIDs, NullifierHash, and V. It calls the BuyRWA (RWAChainIDt, NullifierHash, NewNullifierHash, NewCommitment, V, ChainIDs, ChainIDt, CCUpdateExchangeStatus, Pukt) function in the contract on Chain II (that is, Figure 4 After obtaining the target digital asset on the target chain (as shown in step 304), the BuyRWA function also generates a new random number hash value, NewCommitment. NewCommitment is similarly derived through a hash function using two new random numbers, Secret, Nullifier, and RWAIDs obtained by User 1 when creating RWA on Chain 1. Furthermore, the BuyRWA function uses NewCommitment as a leaf node in the Merkle tree (i.e., hash tree), modifies the status of NullifierHash to "purchased," and triggers a cross-chain operation. Based on at least the aforementioned public key and the first hash value indicating purchase, the following purchase parameters can be passed: V, ChainIDs, ChainIDt, NullifierHash, CCUpdateExchangeStatus, and Pukt.

[0118] In step 404, the cross-chain transfer protocol executes the asset status update function on the source chain according to the purchase parameters, identifies the first hash value as purchased through the asset status update function on the source chain, and transmits the first hash value and public key identified as purchased to the source chain.

[0119] Specifically, the cross-chain transfer protocol performs cross-chain operations and obtains the purchase parameters in the cross-chain operation: ChainIDs, ChainIDt, V, CCUpdateExchangeStatus, NullifierHash, Pukt, and executes the CCUpdateExchangeStatus (NullifierHash) function (i.e., asset status update function) of the contract on the source chain (i.e., Chain I) according to ChainIDs (i.e., Figure 4 The CCUpdateExchangeStatus function updates the NullifierHash status to "purchased" to mark the first hash value as purchased and triggers the BuyRWA contract event. In addition to passing the first hash value and public key marked as purchased, the parameters passed to the source chain in this embodiment may include: NullifierHash (i.e., the first hash value marked as purchased), V, Pukt (i.e., the public key), ChainIDs, ChainIDt (i.e., Figure 4 (as shown in step 306).

[0120] In step 406, after determining that the purchase event has been triggered by the second contract, the first user account on the source chain obtains the first hash value and public key indicating the purchase. If the third zero-knowledge proof constructed based on the first hash value indicating the purchase passes verification, the first user account extracts a digital asset unit consistent with the value of the target digital asset from the first contract, where the digital asset unit originally belonged to the second user account and is a digital asset of the target denomination from the at least one candidate denomination.

[0121] When the first user account User1 on the source chain Chain 1 determines that a BuyRWA event (i.e., a purchase event) has occurred, it can obtain the following parameters: NullifierHash, V, Pkt, and ChainIDt based on the first hash value and public key that indicate the purchase. The first user account can encrypt the metadata of RWA using Pkt off-chain to obtain the metadata summary M, and call the TransferRWA (Root, NullifierHash, Proof3, M, MHash, ChainIDs, ChainIDt) function in the contract on Chain 1 (i.e., Figure 4The asset transfer function in step 307 is shown, where Root is the root hash value of the Merkle tree on Chain 1, and Proof3 is the third zero-knowledge proof. Proof3 must be executed locally by User 1 by executing Alg2 (i.e., if the digital asset transaction request is a digital asset exchange request, the target arithmetic circuit is Alg2). Using the Root and NullifierHash from step 301 as public inputs, and the Secret, RWAIDs, and Merkle proof as private inputs, a zk-SNARK is constructed to generate Proof3. The TransferRWA function verifies Proof3. Upon successful verification, V tokens (i.e., virtual currency with the same value as the asset) are extracted from the contract, the NullifierHash status is updated to "pending withdrawal," and a cross-chain operation is triggered, passing the parameters M, ChainIDs, ChainIDt, NullifierHash, and MHash.

[0122] In this embodiment, the Alg2 program is compiled into an arithmetic circuit suitable for zk-SNARK. The public inputs of the arithmetic circuit generated by the Alg2 program include the root hash value of the Merkle tree, the hash value of the Nullifier (NullifierHash), and the hash value of the RWA asset ID (RWAIDHash). The private inputs include the Nullifier, Secret, RWAID, and the Merkle path proof.

[0123] The constraints of the target arithmetic circuit in this embodiment include the following (1) to (3):

[0124] (1) The circuit hashes the private input Nullifier using the MiMC hashing algorithm and compares the result with the public input NullifierHash to verify that the user knows the original image of the Nullifier. This process ensures that each transaction corresponds to a unique Nullifier and prevents the reuse of the same Nullifier through NullifierHash, thus effectively defending against double-spending attacks.

[0125] (2) The circuit hashes the private input RWAID using the MiMC hashing algorithm and compares the result with the public input RWAIDHash to verify that the user actually knows the original image of RWAIDHash. This process is to prevent the reuse of the same RWAID, thereby effectively defending against double-spending attacks.

[0126] (3) The circuit combines Nullifier, RWAID and Secret and performs MiMC hash calculation again to generate the leaf node hash value LeafHash of the Merkle tree. Combined with the Merkle tree root hash value Root in the public input and the Merkle path proof in the private input, the circuit verifies the existence of the leaf node in the Merkle tree to ensure that the user's declared token is legally stored in the anonymous transaction pool. The cross-chain protocol performs cross-chain operations, obtains M, ChainIDs, ChainIDt, NullifierHash, MHash parameters in the cross-chain operation, stores M and MHash on the chain, and triggers the TransferRWA contract event, passing the parameter NullifierHash (that is, Figure 4 Step 308 is shown).

[0127] As an optional implementation, when the first zero-knowledge proof constructed according to the target digital asset parameters passes verification, associating the target digital asset with the second user account includes:

[0128] After processing the first designated private input and the first designated public input by the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit is obtained, wherein the first designated public input includes the root hash value of the new hash tree and the first hash value identified as purchased, and the first designated private input includes at least one new random number and a new path proof;

[0129] If the first zero-knowledge proof is verified, obtain the metadata digest and metadata digest hash value transmitted by the cross-chain transfer protocol, where the metadata digest is obtained by encrypting the metadata of the target digital asset using the public key;

[0130] Decrypt the metadata summary using the private key corresponding to the public key, and calculate the hash value of the decrypted data to obtain the metadata summary decryption value;

[0131] If it is determined by performing a comparison operation within a preset time period that the metadata digest decryption value is the same as the metadata digest hash value, the target digital asset is purchased by destroying the digital asset unit and the target digital asset is associated with the second user account.

[0132] Specifically, after the second user account User2 on Chain II determines that the TransferRWA contract event occurs, it obtains the first hash value of the parameter NullifierHash (that is, Figure 4In step 309, the WithdrawRWA (Root, NullifierHash, NewNullifierHash, Proof4) function (i.e., asset withdrawal function) is called, where Root is the root hash value of the Merkle tree on ChainII, and Proof4 is the first zero-knowledge proof in this embodiment (i.e., Figure 4 As shown in step 310). Proof4 must be constructed by User2 locally by executing Alg2 (i.e., the target arithmetic circuit in this embodiment can be Alg2), using the Root (i.e., the root hash value of the new hash tree) and NewNullifierHash (i.e., the new random number hash value) in step 304 as the first designated public input, and Secret, Nullifier (i.e., at least one new random number) and Merkle proof (i.e., the new path proof) as the first designated private input to generate Proof4. WithdrawRWA will verify Proof4 (i.e., the first zero-knowledge proof in this embodiment). After the verification is passed, it will obtain the M (i.e., metadata digest) and MHash (i.e., metadata digest hash value) stored on the chain, and trigger the WithdrawRWA contract event (i.e., the contract event of the asset withdrawal function), passing the first hash value, i.e., the parameter NullifierHash (i.e., Figure 4 (See step 311). User2 can decrypt M using the private key Prikt corresponding to Pukt and hash it to obtain NewMHash (i.e., the metadata digest decrypted value). In other words, if the metadata digest decrypted value and the metadata digest hash value are determined to be identical after a comparison operation at time T (i.e., a preset time period), the target digital asset is purchased by destroying the digital asset unit and associated with the second user account.

[0133] As an optional implementation, the method further includes:

[0134] If the second user account of the target chain fails to confirm that the metadata digest decryption value is the same as the metadata digest hash value within the preset time period, an inconsistency message is transmitted to the cross-chain transfer protocol;

[0135] The cross-chain transfer protocol passes inconsistent messages to the source chain;

[0136] The source chain compares the metadata hash value of the target digital asset with the metadata digest hash value based on the inconsistency message. If the comparison result indicates that the metadata hash value of the target digital asset is inconsistent with the metadata digest hash value, the digital asset unit is returned to the address corresponding to the second user account on the target chain.

[0137] That is, when the NewMHash of the second user account User2 is inconsistent with the MHash within time T (i.e., a preset time period), the following parameters are provided: RWAIDs, NullifierHash, M, MHash, V, ChainIDs, ChainIDt, and Addresst. ChainIDs is the ID of Chain I, ChainIDt is the ID of Chain II, and Addresst is the account address of User2 on Chain II, which can be a temporary address. An inconsistency message is then transmitted to the cross-chain transfer protocol, which then passes the inconsistency message to the source chain. The source chain compares the metadata digest hash value of the target digital asset created by User1 on the chain with the MHash. If there is a discrepancy, V tokens (i.e., digital asset units) are returned to Addresst on Chain II, and the RWA assets on Chain I are locked. When a user attempts to withdraw funds, the user's address is blacklisted.

[0138] As an optional implementation, the following steps may be used to extract digital asset units consistent with the value of the target digital asset from the second contract:

[0139] After the source chain processes the second designated private input and the second designated public input through the target arithmetic circuit, it obtains a third zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, extracts the target digital asset from the first contract, and identifies the first hash value as pending withdrawal, so that the first user account cannot withdraw the target digital asset, wherein the second designated public input includes the root hash value of the hash tree and the first hash value identified as pending withdrawal, and the second designated private input includes a second random number among the at least one random number, the asset ID corresponding to the target digital asset, and the path proof.

[0140] That is, in this embodiment, the second designated public input includes the Root and NullifierHash from step 401, and the second designated private input includes the second random number Secret from at least one random number, RWAIDs (the asset ID corresponding to the target digital asset), and a Merkle proof (i.e., a path proof) as private inputs, thereby constructing a third zero-knowledge proof, Proof3. The TransferRWA function verifies Proof3. Upon successful verification, it extracts Vs tokens from the contract, updates the NullifierHash status to "pending withdrawal," and triggers a cross-chain operation, passing the parameters M, ChainIDs, ChainIDt, NullifierHash, and MHash. However, the NullifierHash is locked at this point, requiring a time T to withdraw the funds. This setting effectively prevents Chain I from passing an incorrect M when executing the TransferRWA function, leaving it to users on Chain II to verify the assets.

[0141] The constraints of the target arithmetic circuit may be the following conditions as mentioned above:

[0142] First, the target arithmetic circuit hashes the private input Nullifier using the MiMC hashing algorithm and compares the hash with the public input NullifierHash to verify that the user knows the preimage of the Nullifier. This process ensures that each transaction is uniquely associated with a Nullifier and prevents the reuse of the same Nullifier through NullifierHash, effectively preventing double-spending attacks.

[0143] Next, the target arithmetic circuit hashes the private input RWAID using the MiMC hashing algorithm and compares the hash with the public input RWAIDHash to verify that the user knows the original image of RWAIDHash. This process prevents the reuse of the same RWAID, effectively defending against double-spending attacks.

[0144] The target arithmetic circuit then combines the Nullifier, RWAID, and Secret and performs another MiMC hash calculation to generate the LeafHash hash value of the Merkle tree leaf node. Combining the Merkle tree root hash value Root in the public input and the Merkle path proof in the private input, the circuit verifies the existence of this leaf node in the Merkle tree, ensuring that the user's claimed token is legally stored in the anonymous transaction pool.

[0145] If the second user account of the target chain does not feedback within a preset time period that the metadata digest decryption value is different from the metadata digest hash value, the target arithmetic circuit processes the first designated private input and the first designated public input to obtain a fourth zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the first designated public input includes the root hash value of the new hash tree and the new random number hash value, and the first designated private input includes at least one new random number and a new path proof.

[0146] When the third zero-knowledge proof is verified, the source chain extracts the digital asset unit from the contract to the first user account.

[0147] After waiting for T time (i.e., a preset time period), the user User1 on Chain 1 can execute the WithdrawToken (Root, NullifierHash, Addresses, Proof3) function (i.e., virtual currency withdrawal function), where Root is the root hash value of the Merkle tree on Chain 1, Addresses is any address on Chain 1 for receiving Tokens, and Proof3 is the third zero-knowledge proof (i.e., Figure 4 Step 312 is shown). WithdrawToken will verify Proof3. After verification, it will extract V tokens (i.e., virtual currency with the same value as the asset) from the contract to the account address of Chain I, and trigger the WithdrawToken contract event, passing the parameter NullifierHash (i.e., Figure 4 (shown as step 313).

[0148] Since the target chain completes the transaction of the target digital asset through zero-knowledge proof during the transaction process, it can verify the legitimacy of the transaction without exposing sensitive transaction information (such as the specific amount, real address, and original data). This achieves the technical effect of hiding sensitive information and preventing it from being leaked, thereby solving the problem of ineffective privacy protection for cross-chain digital asset transactions in related technologies.

[0149] According to another aspect of an embodiment of the present application, a cross-chain digital asset transaction method is provided, which is applied to a cross-chain transmission protocol. The method includes:

[0150] When the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers the second contract on the target chain according to the digital asset transaction request, so that the second user account on the target chain obtains the target digital asset parameters after determining the contract event triggered by the second contract, generates the target digital asset on the target chain, and when the first zero-knowledge proof constructed based on the target digital asset parameters is verified and passed, the target digital asset is associated with the second user account, completing the transaction of the target digital asset, wherein the digital asset transaction request is used to request the transaction of the target digital asset.

[0151] In this embodiment, the cross-chain digital asset transaction method applied to the cross-chain transmission protocol can refer to the relevant implementation methods corresponding to the cross-chain transmission protocol in the cross-chain digital asset transaction method in the aforementioned embodiment, and will not be repeated here.

[0152] As an optional implementation, as in the aforementioned method, the cross-chain transfer protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, including:

[0153] The cross-chain transfer protocol executes the asset status update function of the second contract on the target chain indicated by the first transaction parameter, identifies the first hash value in the obtained target digital asset parameter as to be traded, obtains the target digital asset parameter, and transmits the target digital asset parameter to the target chain;

[0154] After completing the transaction of the target digital asset, the method further includes: the target chain marking the first hash value as having been traded.

[0155] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0156] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, or of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM (Read-Only Memory, Read-Only Memory) / RAM (Random Access Memory, Random Access Memory), a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0157] According to another aspect of the embodiments of the present application, a cross-chain digital asset trading system for implementing the above-mentioned cross-chain digital asset trading method is also provided. Figure 5 This is a structural block diagram of an optional cross-chain digital asset trading system according to an embodiment of the present application, such as Figure 5 As shown, the device may include:

[0158] Source chain 51, used to obtain a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset;

[0159] A cross-chain transmission protocol 52 is used to transmit the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and trigger the second contract on the target chain according to the digital asset transaction request;

[0160] The target chain 53 is configured to, after determining that the contract event triggered by the second contract is triggered, obtain the target digital asset parameters from the second user account on the target chain, generate the target digital asset on the target chain, and, if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associate the target digital asset with the second user account to complete the transaction of the target digital asset.

[0161] It should be noted that the source chain 51 in this embodiment can be used to execute the above step S202, the cross-chain transmission protocol 52 in this embodiment can be used to execute the above step S204, and the target chain 53 in this embodiment can be used to execute the above step S206.

[0162] Through the above module, since the target chain completes the transaction of the target digital asset through zero-knowledge proof during the transaction process, it is possible to verify the legitimacy of the transaction without exposing sensitive transaction information (such as the specific amount, real address, and original data). This achieves the technical effect of hiding sensitive information and preventing it from being leaked, thereby solving the problem of ineffective privacy protection for cross-chain digital asset transactions in related technologies.

[0163] In addition to the above modules, the device in this embodiment may also include a module for executing any method in any of the embodiments of the aforementioned cross-chain digital asset transaction method.

[0164] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. Figure 1 The hardware environment shown can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0165] According to another aspect of the embodiments of the present application, a transmission protocol for cross-chain digital asset transactions is also provided, which is used to:

[0166] When a source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers a second contract on the target chain according to the digital asset transaction request, so that the second user account on the target chain obtains the target digital asset parameters after determining the contract event triggered by the second contract, generates the target digital asset on the target chain, and when the first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associates the target digital asset with the second user account, and completes the transaction of the target digital asset, wherein the digital asset transaction request is used to request the transaction of the target digital asset.

[0167] According to another aspect of the embodiments of the present application, an electronic device for implementing the above-mentioned cross-chain digital asset transaction method is also provided. The electronic device can be a server, a terminal, or a combination thereof.

[0168] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0169] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in various embodiments of the present application.

[0170] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, and can be electrical or other forms.

[0172] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected based on actual needs to achieve the purpose of the solution provided in this embodiment.

[0173] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0174] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A cross-chain digital asset transaction method, characterized in that: include: The source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset; The source chain calls the hash function in the first contract to hash at least one random number to obtain a random number hash value, and obtains a hash tree with the random number hash value as a leaf node, a root hash value of the hash tree, and a path proof based on the random number hash value, including: the source chain calls the hash function to hash the Secret and the Nullifier to obtain the random number hash value used to prevent the asset transfer request from being called multiple times, applies the transfer function to use the random number hash value as a leaf node of the hash tree, and obtains the root hash value of the hash tree and a path proof, wherein the at least one random number includes the Secret and the Nullifier, and the Secret is a random number that is not disclosed and provides the basis for the anonymity of the transaction, and is used to construct an identity identifier of the first user account independent of other user accounts; The cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, and triggers the second contract on the target chain according to the digital asset transaction request; the cross-chain transmission protocol transmits the target digital asset parameters corresponding to the digital asset transaction request to the target chain, including: the cross-chain transmission protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, wherein the first transaction parameters are parameters included in the digital asset transaction request, and the target digital asset parameters include at least a first hash value corresponding to the first random number of the at least one random number; After determining the contract event triggered by the second contract, the second user account on the target chain obtains the target digital asset parameters, generates the target digital asset on the target chain, and if a first zero-knowledge proof constructed based on the target digital asset parameters is verified, associates the target digital asset on the target chain with the second user account, completes the transaction of the target digital asset, and updates the status of the random number hash value in the target digital asset parameters. If the first zero-knowledge proof constructed based on the target digital asset parameters is verified, associating the target digital asset on the target chain with the second user account includes: the target chain processes private input and public input through a target arithmetic circuit to obtain a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the public input includes the root hash value and the first hash value, and the private input includes the at least one random number and the path proof; if the first zero-knowledge proof is verified, associating the target digital asset with the second user account.

2. The method according to claim 1, characterized in that The constraints include: The verification hash value obtained by hashing the random number to be verified in the private input is consistent with the public input; Through the root hash value in the public input and the path proof in the private input, it is determined that the random number hash values ​​generated by all random numbers in the private input are leaf nodes of the hash tree.

3. The method according to claim 1, characterized in that In the case where the digital asset transaction request is a digital asset transfer request, before the target chain obtains the target digital asset parameters, the method further includes: The source chain destroys the target digital asset on the source chain if a second zero-knowledge proof constructed based on the target digital asset parameters passes verification, including: the source chain processes the private input and the public input through a target arithmetic circuit to obtain a second zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, wherein the public input includes the root hash value and the first hash value, the private input includes the at least one random number and the path proof, and the target digital asset is a digital asset of a target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes verification, executing a digital asset destruction function to delete the target digital asset on the source chain and mark the first hash value on the source chain as destroyed; The cross-chain transfer protocol triggers a digital asset destruction event in the second contract on the target chain based on the obtained first hash value marked as destroyed; The target chain obtains the target digital asset parameters, including: the target chain obtains the target digital asset parameters when determining the digital asset destruction event.

4. The method according to claim 1, wherein In a case where the digital asset transaction request is a digital asset exchange request, before the first zero-knowledge proof constructed according to the target digital asset parameters is verified, the method further includes: The target chain calls the hash function in the second contract to hash at least one new random number to obtain a new random number hash value, obtains a new hash tree with the new random number hash value as a leaf node, a root hash value of the new hash tree, and a new path proof based on the new random number hash value, obtains the public key generated by the second user account, and transmits purchase parameters to the cross-chain transfer protocol, wherein the purchase parameters include: the public key and the first hash value marked as purchased; The cross-chain transfer protocol executes the asset status update function on the source chain according to the purchase parameters, identifies the first hash value as purchased through the asset status update function on the source chain, and transmits the first hash value identified as purchased and the public key to the source chain; After determining the purchase event triggered by the second contract, the first user account on the source chain obtains the first hash value indicating the purchase and the public key, and if a third zero-knowledge proof constructed based on the first hash value indicating the purchase passes verification, extracts a digital asset unit consistent with the value of the target digital asset from the first contract, wherein the digital asset unit originally belonged to the second user account and is a digital asset of the target denomination unit from at least one candidate denomination unit.

5. The method according to claim 4, characterized in that The step of associating the target digital asset with the second user account when the first zero-knowledge proof constructed according to the target digital asset parameters passes verification includes: After processing the first designated private input and the first designated public input by the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraints of the target arithmetic circuit is obtained, wherein the first designated public input includes the root hash value of the new hash tree and the new random number hash value, and the first designated private input includes the at least one new random number and the new path proof; If the first zero-knowledge proof is verified successfully, obtaining the metadata digest and metadata digest hash value transmitted by the cross-chain transfer protocol, wherein the metadata digest is obtained by encrypting the metadata of the target digital asset using a public key; Decrypting the metadata summary using the private key corresponding to the public key, and performing hash value calculation on the decrypted data to obtain a metadata summary decryption value; If it is determined by performing a comparison operation within a preset time period that the metadata digest decryption value is identical to the metadata digest hash value, the target digital asset is purchased by destroying the digital asset unit, and the target digital asset is associated with the second user account.

6. The method according to claim 5, characterized in that The extracting, from the second contract, a digital asset unit consistent with the value of the target digital asset comprises: After the source chain processes the second designated private input and the second designated public input through the target arithmetic circuit, it obtains a third zero-knowledge proof that satisfies the constraints of the target arithmetic circuit, extracts the target digital asset from the first contract, and identifies the first hash value as pending withdrawal, so that the first user account cannot withdraw the target digital asset, wherein the second designated public input includes the root hash value of the hash tree and the first hash value identified as pending withdrawal, and the second designated private input includes the second random number of the at least one random number, the asset ID corresponding to the target digital asset, and the path proof; If the second user account of the target chain does not feedback within a preset time period that the metadata digest decryption value is different from the metadata digest hash value, the target arithmetic circuit processes the first designated private input and the first designated public input to obtain a fourth zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit, wherein the first designated public input includes the root hash value of the new hash tree and the new random number hash value, and the first designated private input includes the at least one new random number and the new path proof; When the third zero-knowledge proof is verified successfully, the source chain extracts the digital asset unit from the contract to the first user account.

7. The method according to claim 5, characterized in that The method further comprises: If the second user account of the target chain fails to determine that the metadata digest decrypted value is the same as the metadata digest hash value within the preset time period, an inconsistency message is transmitted to the cross-chain transfer protocol; The cross-chain transmission protocol transmits the inconsistent message to the source chain; The source chain compares the hash value of the metadata of the target digital asset with the metadata digest hash value according to the inconsistency message. If the comparison result indicates that the hash value of the metadata of the target digital asset is inconsistent with the metadata digest hash value, the digital asset unit is returned to the address corresponding to the second user account on the target chain.

8. A cross-chain digital asset trading system, characterized by: include: A source chain, configured to obtain a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain, wherein the digital asset transaction request is used to request a transaction for a target digital asset; calling a hash function in the first contract to hash at least one random number to obtain a random number hash value, and obtaining a hash tree with the random number hash value as a leaf node, a root hash value of the hash tree, and a path proof based on the random number hash value, including: hashing a Secret and a Nullifier by invoking the hash function to obtain the random number hash value used to prevent the asset transfer request from being called multiple times and to indicate the status of the cross-chain asset transfer request; using the random number hash value as a leaf node of the hash tree by applying a transfer function, and obtaining the root hash value of the hash tree and a path proof, wherein the at least one random number includes a Secret and a Nullifier, wherein the Secret is a random number that is not disclosed and provides a basis for the anonymity of the transaction and is used to construct an identity identifier of the first user account independent of other user accounts; A cross-chain transmission protocol, configured to transmit the target digital asset parameters corresponding to the digital asset transaction request to a target chain, and trigger a second contract on the target chain according to the digital asset transaction request; the cross-chain transmission protocol transmitting the target digital asset parameters corresponding to the digital asset transaction request to the target chain, comprising: the cross-chain transmission protocol transmitting the target digital asset parameters obtained based on a first transaction parameter to the target chain, wherein the first transaction parameter is a parameter included in the digital asset transaction request, and the target digital asset parameter includes at least a first hash value corresponding to a first random number of the at least one random number; The target chain is configured to, after determining a contract event triggered by the second contract, enable a second user account on the target chain to obtain the target digital asset parameters, generate the target digital asset on the target chain, and, if a first zero-knowledge proof constructed based on the target digital asset parameters passes verification, associate the target digital asset with the second user account, complete a transaction of the target digital asset, and update the status of the random number hash value in the target digital asset parameters. The associating the target digital asset on the target chain with the second user account if the first zero-knowledge proof constructed based on the target digital asset parameters passes verification comprises: the target chain processes private input and public input through a target arithmetic circuit to obtain a first zero-knowledge proof that satisfies constraints of the target arithmetic circuit, wherein the public input includes the root hash value and the first hash value, and the private input includes the at least one random number and the path proof; and if the first zero-knowledge proof passes verification, associate the target digital asset with the second user account.

9. A transmission protocol for cross-chain digital asset transactions, characterized by: Used for: In the case where the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by calling a first contract on the source chain, the cross-chain transmission protocol transmits the target digital asset parameters obtained based on the first transaction parameters to the target chain, wherein the first transaction parameters are parameters included in the digital asset transaction request, and the target digital asset parameters at least include a first hash value corresponding to a first random number in the at least one random number; and triggers the second contract on the target chain according to the digital asset transaction request, so that the second user account on the target chain obtains the target digital asset parameters after determining the contract event triggered by the second contract, and generates the obtained digital asset parameters on the target chain. The target digital asset, when the first zero-knowledge proof constructed according to the target digital asset parameters is verified, is associated with the target digital asset to the second user account, the transaction of the target digital asset is completed, and the state of the random number hash value in the target digital asset parameters is updated; when the first zero-knowledge proof constructed according to the target digital asset parameters is verified, the target digital asset on the target chain is associated with the second user account, including: the target chain processes the private input and the public input through the target arithmetic circuit to obtain the first zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit, wherein the public input includes The root hash value and the first hash value, the private input includes the at least one random number and the path proof; if the first zero-knowledge proof is verified, the target digital asset is associated with the second user account, wherein the digital asset transaction request is used to request a transaction for the target digital asset; after the source chain obtains the digital asset transaction request initiated by the first user account on the source chain by calling the first contract on the source chain, the source chain calls the hash function in the first contract to hash at least one random number to obtain a random number hash value, and obtains a hash tree with the random number hash value as a leaf node and the root of the hash tree according to the random number hash value. The hash value and path proof include: the source chain hashes the Secret and Nullifier by calling the hash function to obtain the random number hash value used to prevent the asset transfer request from being called multiple times and to represent the status of the cross-chain asset transfer request; the random number hash value is used as the leaf node of the hash tree by applying the transfer function, and the root hash value of the hash tree and the path proof are obtained, wherein the at least one random number includes the Secret and the Nullifier, the Secret is a random number that is not disclosed and provides the basis for the anonymity of the transaction, and is used to construct the identity of the first user account independent of other user accounts.

Images