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

Abstract

The invention provides a cross-chain digital asset transaction method, transmission protocol and system, and the method comprises the steps: a source chain obtains a digital asset transaction request initiated by a first user account on the source chain through calling a first contract on the source chain, and the digital asset transaction request is used for requesting to carry out the transaction of a target digital asset; the cross-chain transmission protocol transmits a target digital asset parameter 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; and after a second user account on the target chain determines a contract event triggered by the second contract, obtaining a target digital asset parameter, generating a target digital asset on the target chain, and associating the target digital asset to the second user account under the condition that a first zero-knowledge proof obtained by construction according to the target digital asset parameter passes verification, and completing the transaction of the target digital assets. The problem that the transaction privacy of the cross-chain digital assets cannot be effectively protected is solved.

Description

Technical Field

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

[0002] Currently, most cross-chain digital asset trading solutions rely on the Simplified Payment Verification (SPV) mechanism. And generally, the following steps are usually adopted to implement: 1) The user locks the assets on the source chain; 2) The operation information is transmitted to the target chain through a cross-chain relay or bridging protocol; 3) Equivalent mapped assets are generated on the target chain. Since there are privacy protection requirements for digital asset trading, the related technologies introduce obfuscated transaction paths, address obfuscation, and preliminary zero-knowledge proof technologies in order to reduce the risk of privacy leakage.

[0003] However, there are the following technical problems in trading using the above-mentioned existing technologies: The transaction information is public. The existing solutions will publicly disclose key information such as transfer amounts and user addresses on the chain, enabling external observers to associate the two trading parties through the on-chain data; The risk of correlation analysis is high. Due to the lack of effective anonymization measures, the fixed format and continuous state updates on the chain are easy to trace; The privacy protection is insufficient. Although some zero-knowledge proof-based solutions can verify the legitimacy, it is difficult to completely decouple the input and output in the cross-chain scenario and cannot 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 trading cannot be effectively protected. Summary of the Invention

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

[0006] According to one aspect of the embodiments of this application, a cross-chain digital asset trading method is provided, including: The source chain obtains a digital asset trading request initiated by a first user account on the source chain by calling a first contract on the source chain, where the digital asset trading 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 trading request to the target chain and triggers a second contract on the target chain according to the digital asset trading request; After the second user account on the target chain determines the contract event triggered by the second contract, it obtains the target digital asset parameter, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when the first zero-knowledge proof constructed according to the target digital asset parameter passes the verification, completing the transaction of the target digital asset.

[0007] Optionally, for the method as described above: 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 method further includes: the source chain calls the hash function in the first contract to perform hash processing on 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 according to the random number hash value; The cross-chain transfer protocol transfers the target digital asset parameter corresponding to the digital asset transaction request to the target chain, including: the cross-chain transfer protocol transfers the target digital asset parameter obtained based on the first transaction parameter to the target chain, where the first transaction parameter is a parameter included in the digital asset transaction request, and the target digital asset parameter at least includes a first hash value corresponding to a first random number among the at least one random number; When the first zero-knowledge proof constructed according to the target digital asset parameter passes the verification, associating the target digital asset on the target chain with the second user account includes: the target chain processes the private input and the public input through a target arithmetic circuit to obtain a first zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit, where 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; when the first zero-knowledge proof passes the verification, associating the target digital asset with the second user account.

[0008] Optionally, for the method as described above, the cross-chain transfer protocol transfers the target digital asset parameter obtained based on the first transaction parameter to the target chain, including: 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, marks the first hash value in the obtained target digital asset parameter as to be traded, obtains the target digital asset parameter, and transfers the target digital asset parameter to the target chain; After the transaction of the target digital asset is completed, the method further includes: the target chain marks the first hash value as traded.

[0009] Optionally, as in the foregoing method, the constraint conditions include: The verification hash value obtained by hashing the random number to be verified in the private input is consistent with the public input; Based on 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 the leaf nodes of the hash tree.

[0010] Optionally, as in the foregoing 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 second zero-knowledge proof constructed based on the target digital asset parameters passes the verification on the source chain, the target digital asset located on the source chain is destroyed, including: 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 constraint conditions of the target arithmetic circuit is obtained, where 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 the digital asset of the target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes the verification, execute the digital asset destruction function, delete the target digital asset located 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 according to the obtained first hash value marked as destroyed; The target chain obtains the target digital asset parameters, including: when the digital asset destruction event is determined, the target chain obtains the target digital asset parameters.

[0011] Optionally, as in the foregoing method, when the digital asset transaction request is a digital asset exchange request, before the first zero-knowledge proof constructed based on the target digital asset parameters passes the verification, 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 the leaf node, the root hash value of the new hash tree, and a new path proof, obtains the public key generated by the second user account, and transmits purchase parameters to the cross-chain transfer protocol, where 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, marks the first hash value as purchased through the asset status update function on the source chain, and transfers the first hash value marked as purchased and the public key to the source chain; After the first user account on the source chain determines the purchase event triggered by the second contract, it obtains the first hash value marked as purchased and the public key. When the third zero-knowledge proof constructed based on the first hash value marked as purchased passes the verification, it extracts digital asset units with a value consistent with that of the target digital asset from the first contract, where the digital asset units originally belong to the second user account, and the digital asset units are digital assets of the target denomination unit among at least one candidate denomination unit.

[0012] Optionally, as in the foregoing method, when the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associating the target digital asset with the second user account includes: After processing the first specified private input and the first specified public input through a target arithmetic circuit, a first zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained, where the first specified public input includes the root hash value of the new hash tree and the first hash value marked as purchased, and the first specified private input includes the at least one new random number and the new path proof; When the first zero-knowledge proof passes the verification, obtain the metadata digest and the 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 with the public key; Decrypt the metadata digest with the private key corresponding to the public key, and calculate the hash value of the decrypted data to obtain the metadata digest decryption value; When it is determined that the metadata digest decryption value is the same as the metadata digest hash value through an alignment operation within a preset time period, the target digital asset is obtained by destroying the digital asset unit, and the target digital asset is associated with the second user account.

[0013] Optionally, as in the foregoing method, extracting digital asset units with a value consistent with that of the target digital asset from the second contract includes: After the source chain processes the second specified private input and the second specified public input through the target arithmetic circuit, a third zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained, the target digital asset is extracted from the first contract, and the first hash value is marked as to-be-withdrawn, so that the first user account cannot withdraw the target digital asset. Wherein, the second specified public input includes the root hash value of the hash tree and the first hash value marked as to-be-withdrawn, and the second specified private input includes the second random number among the at least one random number, the asset ID corresponding to the target digital asset, and the path proof; When the second user account of the target chain does not feedback that the metadata digest decryption value is different from the metadata digest hash value within the preset time period, after processing the first specified private input and the first specified public input through the target arithmetic circuit, a fourth zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained. Wherein, the first specified public input includes the root hash value of the new hash tree and the new random number hash value, and the first specified private input includes the at least one new random number and the new path proof; When the third zero-knowledge proof is verified and passed on the source chain, the digital asset unit is extracted from the contract to the first user account.

[0014] Optionally, for the method as described above, the method further includes: When the second user account of the target chain feedbacks that it is not determined that the metadata digest decryption value is the same as the metadata digest hash value within the preset time period, an inconsistent message is transmitted to the cross-chain transfer protocol; The cross-chain transfer 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 inconsistent 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.

[0015] According to another aspect of the embodiments of the present application, there is also provided a cross-chain digital asset trading method, which is applied to a cross-chain transfer protocol. The method includes: In the case where the cross-chain transfer protocol obtains a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, the cross-chain transfer protocol transfers the target digital asset parameters corresponding to the digital asset trading request to the target chain, and triggers a second contract on the target chain according to the digital asset trading request, so that after a second user account on the target chain determines a contract event triggered by the second contract, the second user account obtains the target digital asset parameters, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset, where the digital asset trading request is used to request a transaction of the target digital asset.

[0016] Optionally, as in the foregoing method, the cross-chain transfer protocol transfers the target digital asset parameters obtained based on the first transaction parameters to the target chain, including: The cross-chain transfer protocol obtains the target digital asset parameters by executing an asset status update function of a second contract on the target chain indicated by the first transaction parameters, marks the first hash value in the obtained target digital asset parameters as to be traded, and then transfers the target digital asset parameters to the target chain; After the transaction of the target digital asset is completed, the method further includes: the target chain marks the first hash value as traded.

[0017] According to another aspect of the embodiments of the present application, there is also provided a cross-chain digital asset trading system, including: A source chain, configured to obtain a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, where the digital asset trading request is used to request a transaction of a target digital asset; A cross-chain transfer protocol, configured to transfer the target digital asset parameters corresponding to the digital asset trading request to the target chain, and trigger a second contract on the target chain according to the digital asset trading request; The target chain is configured to, after a second user account on the target chain determines a contract event triggered by the second contract, obtain the target digital asset parameters, generate the target digital asset on the target chain, and associate the target digital asset with the second user account when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset.

[0018] According to another aspect of the embodiments of the present application, there is also provided a transmission protocol for cross-chain digital asset trading, for: In the case of obtaining, on the source chain, a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, the cross-chain transfer protocol passes the target digital asset parameters corresponding to the digital asset trading request to the target chain, and triggers a second contract on the target chain according to the digital asset trading request, so that after a second user account on the target chain determines a contract event triggered by the second contract, obtains the target digital asset parameters, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset, where the digital asset trading request is used to request a transaction of a target digital asset.

[0019] In the embodiments of the present application, in a manner of integrating zero-knowledge proof, a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain is obtained through the source chain, where the digital asset trading request is used to request a transaction of a target digital asset; the cross-chain transfer protocol passes the target digital asset parameters corresponding to the digital asset trading request to the target chain, and triggers a second contract on the target chain according to the digital asset trading request; after a second user account on the target chain determines a contract event triggered by the second contract, obtains the target digital asset parameters, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset. Since in the process of the transaction, the target chain completes the transaction of the target digital asset through zero-knowledge proof, the purpose of verifying the legality of the transaction can be achieved without exposing sensitive transaction information (such as specific amounts, real addresses, original data), achieving the technical effect of hiding and avoiding the leakage of sensitive information, and further solving the problem in the related art that the privacy of cross-chain digital asset transactions cannot be effectively protected. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0022] Figure 1Schematic diagram of the hardware environment of an optional cross-chain digital asset trading method according to an embodiment of the present application; Figure 2 Flow chart of an optional cross-chain digital asset trading method according to an embodiment of the present application; Figure 3 Schematic diagram of an optional cross-chain digital asset trading method according to another embodiment of the present application; Figure 4 Flow chart of an optional cross-chain digital asset trading method according to still another embodiment of the present application; Figure 5 Block diagram of the structure of an optional cross-chain digital asset trading system according to an embodiment of the present application. Detailed implementation manners

[0023] In order to enable those skilled in the art to better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0024] 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 do not necessarily need to describe a specific order or sequence. It should be understood that such used data may be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily need to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] First, some nouns or terms that appear in the process of describing the embodiments of the present application are applicable to the following explanations: A smart contract is a program running on a blockchain, which consists of a series of codes (functions) and data (status) located at a specific address on the blockchain. Unlike ordinary accounts, a smart contract is not controlled by a person but runs automatically on the network as a program. Individual users can interact with a smart contract by submitting a transaction to execute a certain function in it. A smart contract can set rules like a traditional contract and automatically execute these rules through code. By default, once deployed, a smart contract cannot be deleted, and the operations interacting with it are also irreversible. Through smart contracts, the single point of failure and centralization risks can be reduced.

[0026] The public inputs of the arithmetic circuit of zk-SNARK include Merkle tree roots, NullifierHash, etc., and the private inputs include Secret, Nullifier, Merkle proofs, etc.

[0027] According to one aspect of the embodiments of the present application, a cross-chain digital asset trading method is provided. Optionally, in this embodiment, the above cross-chain digital asset trading method can be applied to a Figure 1 hardware environment composed of a terminal 1402 and a server 1404 as shown. As Figure 1 shown, the server 1404 is connected to the terminal 1402 through 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 the server 1404.

[0028] The above network can include but is not limited to at least one of the following: wired network, wireless network. The above wired network can include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network. The above wireless network can include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal is not limited to a PC, mobile phone, tablet computer, etc.

[0029] The cross-chain digital asset trading method of the embodiments of the present application can be executed by the server, or by the terminal, or jointly by the server and the terminal. Among them, when the terminal executes the cross-chain digital asset trading method of the embodiments of the present application, it can also be executed by the client installed on it.

[0030] Taking the execution of the cross-chain digital asset trading method in this embodiment by the server as an example, Figure 2 A cross-chain digital asset trading method provided by the embodiments of the present application is applied to a cross-chain digital asset trading system and includes the following steps: Step S202: The source chain obtains a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain. The digital asset transaction request is used to request a transaction for a target digital asset.

[0031] The cross-chain digital asset transaction method in this embodiment can be applied to scenarios where digital assets need to be traded in a cross-chain situation, such as: scenarios of transferring digital assets in a cross-chain situation, scenarios of exchanging digital assets in a cross-chain situation, etc., or other scenarios of trading digital assets in a cross-chain situation. In the embodiments of this application, the cross-chain digital asset transaction method is described by taking the transfer and exchange of digital assets in a cross-chain situation as an example. For other types of trading methods, the above cross-chain digital asset transaction method is equally applicable without contradiction.

[0032] Specifically, when transferring digital assets in a cross-chain situation, assume that User1 in Chain I (i.e., the source chain) sends an amount Vs to User2 in Chain II (i.e., the target chain), where Vs is a standard value. The amount Vs can be one of multiple small-denomination units (such as 1, 10, or 100, etc.) obtained by dividing a large amount of assets.

[0033] As Figure 3 shown, initially, User1 issues an asset transfer request by invoking the ApplayTransferToken(Commitment, NullifierHash, ChainChainIDs, ChainChainIDt, Vs, CCUpdateTransferStatus) function of the contract on Chain I (i.e., Figure 3The steps shown in 101). Among them, Commitment is obtained by a Hash function from two random numbers, Secret and Nullifier. Secret is a random number that provides the basis for the anonymity of subsequent transactions, and is also used to construct an identity identifier completely independent of other users without being made public. Nullifier can also be used to generate NullifierHash (i.e., the first hash value) through a hash function. The role of NullifierHash is to prevent the asset transfer request from being called multiple times (i.e., double-spending attack) and to represent the status of the cross-chain asset transfer request. Vs represents the sending amount for cross-chain asset transfer, ChainIDs represents the source chain ID (i.e., the source chain identifier), ChainIDt represents the target chain ID (i.e., the 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", "To be destroyed", "Destroyed", "To be withdrawn", "Withdrawn". In a cross-chain transfer, NullifierHash in the initiating chain can only be "Revoked", "To be destroyed", and "Destroyed", and in the target chain, it can only be "To be withdrawn" and "Withdrawn".

[0034] After obtaining 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 method further includes the steps described below: 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, obtains a hash tree with the random number hash value as the leaf node, the root hash value of the hash tree, and the proof of path.

[0035] Specifically, the source chain calls the hash function to hash two random numbers, Secret and Nullifier, to obtain the random number hash value Commitment. Then, through the application transfer function (i.e., the ApplayTransferToken function), Commitment is used as the leaf node of the Merkle tree. At the same time, the root hash value of the hash tree and the proof of path can be obtained. Transfer Vs tokens to the contract of Chain I (i.e., the source chain), store the status of NullifierHash as "To be destroyed", and trigger the cross-chain operation, passing the parameters Vs, ChainIDs, ChainIDt, NullifierHash, CCUpdateTransferStatus.

[0036] Step S204, the cross-chain transfer protocol transfers 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.

[0037] Specifically, the digital asset trading request carries multiple parameters. The cross-chain transfer protocol can transfer the target digital asset parameters in the digital asset trading request to the target chain. In addition, according to needs, the cross-chain transfer protocol can also transfer other parameters in the digital asset trading request to the target chain.

[0038] Optionally, the cross-chain transfer protocol can transfer the target digital asset parameters corresponding to the digital asset trading request to the target chain through the following steps: The cross-chain transfer protocol transfers the target digital asset parameters obtained based on the first transaction parameter to the target chain, where the first transaction parameter is the parameter included in the digital asset trading request, and the target digital asset parameters at least include the first hash value corresponding to the first random number in at least one random number. That is to say, the first random number can be the aforementioned Nullifier, and then the first transaction parameter at least includes the aforementioned NullifierHash.

[0039] As an alternative implementation, as in the aforementioned method, the cross-chain transfer protocol can transfer the target digital asset parameters obtained based on the first transaction parameter to the target chain through the following steps: The cross-chain transfer protocol marks the first hash value in the obtained target digital asset parameters as to be traded by executing the asset status update function of the second contract on the target chain indicated by the first transaction parameter, and then obtains the target digital asset parameters and transfers the target digital asset parameters to the target chain.

[0040] Specifically, when the cross-chain protocol performs a cross-chain operation, the target digital asset parameters obtained from the event may include: ChainIDs, ChainIDt, Vs, CCUpdateTransferStatus, NullifierHash parameters. According to ChainIDt, execute the CCUpdateTransferStatus(NullifierHash) function of the contract on the target chain Chain II (which is Figure 3 step 102 shown). The CCUpdateTransferStatus function updates the status of NullifierHash (i.e., the first hash value) to "pending withdrawal (one of the optional types of pending transactions)", and triggers the ApplayTransferToken contract event, transferring the parameters NullifierHash and Vs to the target chain (which is Figure 3 step 103 shown). It should be noted that the CCUpdateTransferStatus function can only be called through a cross-chain contract or a specific administrator account, which can be modified according to the cross-chain protocol adopted here.

[0041] Step S206. After the second user account on the target chain determines the contract event triggered by the second contract, it obtains the target digital asset parameters, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thus completing the transaction of the target digital asset.

[0042] 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, and after the zero-knowledge proof passes, the transaction of the target digital asset can be realized.

[0043] As an optional implementation manner, for the method as described above, 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 second zero-knowledge proof constructed according to the target digital asset parameters by the source chain passes the verification, the target digital asset located on the source chain is destroyed.

[0044] Further, when the second zero-knowledge proof constructed according to the target digital asset parameters by the source chain passes the verification, the destruction of the target digital asset located on the source chain can be realized through the following method: the source chain processes the private input and the public input through the target arithmetic circuit to obtain the second zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit, where the public input includes the root hash value and the first hash value, the private input includes at least one random number and the path proof, and the target digital asset is the digital asset of the target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes the verification, execute the digital asset destruction function, delete the target digital asset located on the source chain, and mark the first hash value on the source chain as destroyed.

[0045] When the digital asset transaction request is a digital asset transfer request, it means that the digital asset transaction request is an operation that only requests to transfer the target digital asset from the first user account on the source chain to the second user account on the target chain. In this embodiment, after the first user account determines the need for the original digital asset transaction request, it can split the total asset transaction amount of the original digital asset transaction request to obtain the quantity corresponding to each digital asset unit, and then obtain the digital asset transfer request corresponding to each digital asset unit. For example, when the total asset transaction amount is 136, and the denominations included in the digital asset unit are: 100, 10, and 1, it can be split to obtain the digital asset transfer request I corresponding to 100 (where the quantity of digital asset units with a denomination of 100 is 1), the digital asset transfer request II corresponding to 10 (where the quantity of digital asset units with a denomination of 10 is 3), and the digital asset transfer request III corresponding to 1 (where the quantity of digital asset units with a denomination of 1 is 6). Finally, deposit the digital asset transfer request I into the target transaction pool corresponding to the digital asset unit denomination of 100, deposit the digital asset transfer request II into the target transaction pool corresponding to the digital asset unit denomination of 10, and deposit the digital asset transfer request III into the target transaction pool corresponding to the digital asset unit denomination of 1. In this embodiment, by splitting large amounts of assets into standardized digital asset units with several fixed denominations (such as 1, 10, 100, etc.), all transactions recorded on the chain only involve transfers of these fixed denominations, which can effectively avoid directly exposing the actual amount and thus cannot be tracked, improving the protection of privacy.

[0046] That is to say, before the target chain obtains the target asset parameters, it is necessary to destroy the target digital asset on the source chain to avoid the situation where the same asset appears on two chains, resulting in an increase in assets.

[0047] The target chain obtains the target digital asset parameters, including: the target chain obtains the target digital asset parameters in the case of determining the digital asset destruction event.

[0048] Furthermore, the source chain can delete the target digital asset located on the source chain when the second zero-knowledge proof constructed according to the target digital asset parameters passes the verification 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 constraint conditions of the target arithmetic circuit. Among them, the public input includes the root hash value and the first hash value, the private input includes at least one random number and the path proof, and the target digital asset is the digital asset of the target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes the verification, execute the digital asset destruction function, delete the target digital asset located on the source chain, and mark the first hash value on the source chain as destroyed.

[0049] Optionally, in the case where the digital asset transaction request is a digital asset transfer request, the constraint conditions 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 by using the root hash value in the public input and the path proof in the private input, it is determined that the verification hash values generated by all random numbers in the private input are leaf nodes of the hash tree.

[0050] 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., as Figure 3 shown in Step 104). After ApplayMintToken is executed, the user User2 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 User1 on Chain I (i.e., the first user account) to execute the DestroyToken function (i.e., Figure 3 shown in Step 105).

[0051] User1 on Chain I executes the DestroyToken(Root, ChainIDs, ChainIDt, NullifierHash, Proof1) function, where Root is the state root of the Merkle tree on Chain I, and Proof1 is the proof data (i.e., the second zero-knowledge proof), which is used to prove that User1 has stored a fixed-denomination Token in the anonymous transaction pool through the ApplayTransferToken method, and User1 has the right to modify the state of NullifierHash to "destroyed" through the DestroyToken method. In order to prove that the fixed-denomination Token stored in the anonymous transaction pool is indeed stored by User1, User1 needs to be verified. In this embodiment, Proof1 must be constructed by User1 locally by executing the Alg1 program (i.e., the target arithmetic circuit) to generate a zk-SNARK proof to generate Proof1.

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

[0053] First, it can be that the verification hash value obtained by hashing the random number to be verified in the private input is consistent with the public input: The arithmetic circuit performs a hash calculation on the Nullifier to be verified (i.e., the random number to be verified) in the private input through 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 indeed knows the preimage of the Nullifier. This process ensures that each transaction uniquely corresponds to a Nullifier and prevents the reuse of the same Nullifier through NullifierHash, thus effectively resisting double-spending attacks.

[0054] Subsequently, it can be determined whether the random number hash value generated by all random numbers in the private input is a leaf node of the hash tree through the root hash value in the public input and the path proof in the private input: When all random numbers include the Nullifier and Secret, the circuit combines the Nullifier and Secret and performs another MiMC hash calculation to obtain the random number hash value, and records this random number hash value as the leaf node hash value (Leaf Hash) of the Merkle tree (i.e., the 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 this leaf node in the Merkle tree to ensure that the Token declared by the user is legally stored in the anonymous transaction pool. The public input includes the root hash value (i.e., the Merkle tree root hash value (Root)) and the first hash value, and the private input includes at least one random number and the path proof.

[0055] Specifically, the verification of Proof1 can be verified through the DestroyToken function. After successful verification, the status of NullifierHash is updated to "destroyed" to mark the first hash value as destroyed, triggering a cross-chain operation and passing parameters ChainIDs, ChainIDt, NullifierHash, CCUpdateTransferStatus (i.e., Figure 3The step 106) shown above. Further, if the verification of Proof1 fails, the entire cross-chain transfer process fails. The user User1 on Chain I 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 I to check whether the status of NullifierHash is "to be destroyed" and verify Proof1. After the verification of Proof1 passes, extract Vs tokens from the contract and modify the status of NullifierHash to "revoked".

[0056] 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 according to the obtained first hash value marked as destroyed.

[0057] Specifically, the cross-chain protocol performs a cross-chain operation, obtains the parameters ChainIDs, ChainIDt, CCUpdateTransferStatus, and NullifierHash in the event corresponding to the cross-chain operation. After determining that the target digital asset has been destroyed on the source chain according to the NullifierHash parameter, trigger the DestroyToken event (i.e., the digital asset destruction event) in the contract on the target chain Chain II according to ChainIDt, and pass the NullifierHash parameter (i.e., Figure 3 The step 107) shown above.

[0058] As an alternative implementation, the following steps can be used to obtain the target digital asset parameters: when the target chain determines a digital asset destruction event, obtain the target digital asset parameters. The following steps can be used to save the target digital asset in the second user account when the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification: 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 constraint conditions of the target arithmetic circuit, where the public input includes the root hash value and the first hash value, and the private input includes at least one random number and a path proof; when the first zero-knowledge proof passes the verification, save the target digital asset in the second user account.

[0059] After the target chain obtains the target digital asset, the method further includes: the target chain marks the target digital asset parameters as traded.

[0060] 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.

[0061] Specifically, when the user User2 on Chain II determines that the DestroyToken event occurs, the parameter NullifierHash (i.e., Figure 3 the step 108 shown) is obtained and the Withdraw (Root, NullifierHash, Address, Proof2) function in the contract on Chain II is called (i.e., Figure 3 the asset extraction function in the step 109 shown). Here, Root is the root hash value of the Merkle tree on Chain I. Since the above target digital asset can be transferred to any address on the target chain, Address is any address on Chain II used to receive the Token, and Proof2 is the proof data used to prove that User2 has stored the above target digital asset (e.g., Token with a fixed denomination, i.e., 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. The DestroyToken function will verify Proof2. After the verification passes, Vs tokens (virtual currency) are extracted from the contract to the account address Address, the status of NullifierHash is updated to "withdrawn", and the Withdraw contract event is triggered (i.e., Figure 3 the step 110 shown). Thus, the target digital asset is saved in the second user account, and the transfer of the target digital asset is completed.

[0062] In the following embodiments, taking the scenario of exchanging digital assets in a cross-chain situation and the server executing the cross-chain digital asset trading method in this embodiment as an example, Figure 2 A cross-chain digital asset trading method provided by an embodiment of the present application is applied to a cross-chain digital asset trading system and includes the following steps: Step S202, the source chain obtains a digital asset trading request initiated by a first user account on the source chain by calling a first contract on the source chain, where the digital asset trading request is used to request a transaction for a target digital asset.

[0063] As Figure 4As shown, by way of 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, and technical means are used to ensure that there are no duplicates). 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, and RWAIDs is equal to RWAIDt, where V is a standard value.

[0064] After the source chain obtains a digital asset transaction request initiated by the first user account on the source chain by calling the first contract on the source chain, the method further includes the steps described below: The source chain calls the hash function in the first contract to perform hash processing on 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, the root hash value of the hash tree, and the path proof.

[0065] In this embodiment, as Figure 4 shown, User1 issues a request to create an asset (i.e., Figure 4The step 301) shown above is used to create the target digital asset. Among them, Commitment is obtained through a Hash function by two random numbers Secret, Nullifier, and the RWAIDs obtained by creating RWA. That is, in this embodiment, the above at least one random number includes: Secret, Nullifier, and RWAIDs. Secret provides a basis for the anonymity of subsequent transactions, and at the same time constructs an identity identifier completely independent of other users without being made public. Nullifier is used to generate NullifierHash through a hash function. The role of NullifierHash is to prevent the asset exchange request from being called multiple times (i.e., double-spending attack) and represent the status of RWA. The role of RWAIDs is to prevent the asset from being exchanged multiple times (i.e., double-spending attack). V represents the value of the RWA asset created by User1. CCUpdateExchangeStatus represents the smart contract function on the target chain to be triggered, which is used to change the status of NullifierHash. NullifierHash has four states: "pending purchase", "purchased", "pending withdrawal", "withdrawn". The CreateRWA function takes Commitment as the leaf node of the Merkle tree, changes the status of NullifierHash to "pending purchase", and triggers a cross-chain operation, passing the parameters V, ChainIDts, RWAIDs, CCUpdateExchangeStatus.

[0066] Step S204, the cross-chain transfer protocol transfers 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.

[0067] Specifically, the digital asset transaction request carries multiple parameters. The cross-chain transfer protocol can transfer the target digital asset parameters in the digital asset transaction request to the target chain. In addition, according to needs, the cross-chain transfer protocol can also transfer other parameters in the digital asset transaction request to the target chain.

[0068] Optionally, the cross-chain transfer protocol can transfer 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 transfers the target digital asset parameters obtained based on the first transaction parameters to the target chain, where the first transaction parameters are the parameters included in the digital asset transaction request, and the target digital asset parameters at least include the first hash value corresponding to the first random number in at least one random number. In this embodiment, the first transaction parameters at least include the aforementioned NullifierHash.

[0069] As an alternative implementation, as in the aforementioned method, the cross-chain transfer 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 transfer protocol marks the first hash value in the obtained target digital asset parameters as pending transaction by executing the asset status update function of the second contract on the target chain indicated by the first transaction parameters, and then obtains the target digital asset parameters and passes the target digital asset parameters to the target chain.

[0070] Specifically, the cross-chain transfer protocol performs a cross-chain operation, obtains the parameters of ChainIDs, ChainIDts, V, CCUpdateExchangeStatus, and RWAIDs in the event, and executes the CCUpdateExchangeStatus (NullifierHash) function (i.e., the asset status update function) of the contract on the target chain according to the ID of the target chain (i.e., Figure 4 the target chain identifier) in the ChainIDts set (i.e., the target chain information set) (assuming that only the ID of Chain II is included in ChainIDts in this example) (i.e., Figure 4 step 302 as shown). The CCUpdateExchangeStatus function updates the status of NullifierHash (i.e., the first hash value) to "pending purchase" (i.e., one of the pending transaction statuses) and triggers the CreateRWA contract event, passing the parameters NullifierHash and V (i.e., Figure 4 step 303 as shown). It should be noted that the CCUpdateExchangeStatus function can only be called through a cross-chain contract or a specific administrator account, which can be modified according to the adopted cross-chain protocol.

[0071] Step S206: After the second user account on the target chain determines the contract event triggered by the second contract, it obtains the target digital asset parameters, generates the target digital asset on the target chain, and associates the target digital asset with the second user account when the first zero-knowledge proof constructed based on the target digital asset parameters passes the verification, thus completing the transaction of the target digital asset.

[0072] Specifically, the target chain obtains the target digital asset parameters, can generate the target digital asset on the target chain, constructs a zero-knowledge proof by calling the second contract on the target chain to generate the corresponding Proof, and can realize the transaction of the target digital asset after the above Proof passes the verification.

[0073] In this embodiment, obtaining the target digital asset parameters can be achieved through the following steps: When the second user account User2 on the target chain Chain II determines that a CreateRWA event has occurred, the following target digital asset parameters are obtained: ChainIDs, NullifierHash, and V. The BuyRWA (RWAChainIDt, NullifierHash, NewNullifierHash, NewCommitment, V, ChainIDs, ChainIDt, CCUpdateExchangeStatus, Pukt) function in the contract on Chain II (i.e., Figure 4 the asset purchase function in step 304 shown) is called to create a new asset RWAt (i.e., the target digital asset on the target chain), and the corresponding asset ID is RWAIDt. Among them, NewCommitment is also obtained through the Hash function from two new random numbers Secret, Nullifier, and the RWAIDs obtained by User1 on Chain I when creating RWA. Pukt is the public key generated by the user User2 on Chain II through the asymmetric encryption algorithm off-chain. ChainIDs represents the ID of Chain I.

[0074] As an alternative implementation, the following steps can be used to associate the target digital asset on the target chain with the second user account when the first zero-knowledge proof constructed based on the target digital asset parameters passes the verification: 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 constraint conditions of the target arithmetic circuit is obtained. Among them, the public input includes the root hash value and the first hash value, and the private input includes at least one random number and the path proof; when the first zero-knowledge proof passes the verification, the target digital asset is associated with the second user account.

[0075] As an alternative implementation, when the digital asset transaction request is a digital asset exchange request, before the first zero-knowledge proof constructed based on the target digital asset parameters passes the verification, the following steps are also included: 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. Based on the new random number hash value, a new hash tree with the new random number hash value as the leaf node, the root hash value of the new hash tree, and a new path proof are obtained. The public key generated by the second user account is obtained, and the purchase parameters are transmitted to the cross-chain transfer protocol. The purchase parameters include: the public key and the first hash value marked as purchased.

[0076] Specifically, when the second user account User2 on Chain II determines that a CreateRWA event has occurred, it obtains the following target digital asset parameters: ChainIDs, NullifierHash, and V. After calling the BuyRWA (RWAChainIDt, NullifierHash, NewNullifierHash, NewCommitment, V, ChainIDs, ChainIDt, CCUpdateExchangeStatus, Pukt) function in the contract on Chain II (i.e., Figure 4 step 304 shown), after creating the target digital asset on the target chain as described above. The BuyRWA function also generates a new random number hash value NewCommitment, which is also obtained by the Hash function using two new random numbers Secret, Nullifier, and the RWAIDs obtained by User1 on Chain I when creating RWA. Moreover, the BuyRWA function takes NewCommitment as a leaf node of 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 marked as purchased, the following purchase parameters can be transmitted: V, ChainIDs, ChainIDt, NullifierHash, CCUpdateExchangeStatus, Pukt.

[0077] Step 404, the cross-chain transfer protocol executes the asset status update function on the source chain according to the purchase parameters. The first hash value is marked as purchased through the asset status update function on the source chain, and the first hash value marked as purchased and the public key are transmitted to the source chain.

[0078] Specifically, the cross-chain transfer protocol performs a cross-chain operation, 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) in the contract on the source chain (i.e., Chain I) according to ChainIDs (i.e., Figure 4The steps shown in 305). The CCUpdateExchangeStatus function updates the NullifierHash status to "purchased" to identify the first hash value as purchased and triggers the BuyRWA contract event. In addition to passing the first hash value identified as purchased and the public key as described above, the parameters passed to the source chain in this embodiment may include: NullifierHash (i.e., the first hash value identified as purchased), V, Pukt (i.e., the public key), ChainIDs, ChainIDt (i.e., Figure 4 The steps shown in 306).

[0079] Step 406. After the first user account on the source chain determines the purchase event triggered by the second contract, it obtains the first hash value identified as purchased and the public key. When the third zero-knowledge proof constructed based on the first hash value identified as purchased passes the verification, it extracts digital asset units consistent with the value of the target digital asset from the first contract, where the digital asset units originally belong to the second user account, and the digital asset units are digital assets of the target denomination unit among at least one candidate denomination unit.

[0080] When the first user account User1 on the source chain Chain I determines that a BuyRWA event (i.e., a purchase event) occurs, on the premise of obtaining the first hash value identified as purchased and the public key, it can obtain the following parameters: NullifierHash, V, Pkt, ChainIDt. The first user account can encrypt the metadata of the RWA off-chain through Pkt to obtain the digest M of the metadata, and call the TransferRWA (Root, NullifierHash, Proof3, M, MHash, ChainIDs, ChainIDt) function in the contract on Chain I (i.e., Figure 4The asset transfer function in step 307 as shown), where Root is the root hash value of the Merkle tree on Chain I, and Proof3 is the third zero-knowledge proof. Proof3 must be constructed by User1 locally by executing Alg2 (i.e., in the case where the digital asset transaction request is a digital asset exchange request, the target arithmetic circuit is Alg2), taking the Root and NullifierHash in step 301 as public inputs, and Secret, RWAIDs, and Merkle proof as private inputs to generate Proof3 using zk-SNARK. The TransferRWA function will verify Proof3. After successful verification, it will extract V tokens (i.e., virtual currency with the same value as the asset) from the contract, update the status of NullifierHash to "pending withdrawal", and trigger a cross-chain operation, passing the parameters M, ChainIDs, ChainIDt, NullifierHash, and MHash.

[0081] 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 Root of the Merkle tree, the hash value NullifierHash of the Nullifier, and the hash value RWAIDHash of the RWA asset ID. The private inputs include Nullifier, Secret, RWAID, and Merkle path proof.

[0082] The constraint conditions of the target arithmetic circuit in this embodiment are as follows (1) to (3): (1) The circuit calculates the hash of the private input Nullifier through the MiMC hash algorithm and compares the result with the public input NullifierHash to verify that the user indeed knows the preimage of Nullifier. This process ensures that each transaction uniquely corresponds to a Nullifier and prevents the reuse of the same Nullifier through NullifierHash, thus effectively resisting double-spending attacks.

[0083] (2) The circuit calculates the hash of the private input RWAID through the MiMC hash algorithm and compares the result with the public input RWAIDHash to verify that the user indeed knows the preimage of RWAIDHash. This process is to prevent the reuse of the same RWAID, thus effectively resisting double-spending attacks.

[0084] (3) The circuit combines the Nullifier, RWAID, and Secret and performs MiMC hashing again to generate the leaf node hash value LeafHash of the Merkle tree. Combining the Merkle 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 Token declared by the user is legally stored in the anonymous transaction pool. The cross-chain protocol performs cross-chain operations, obtains the parameters M, ChainIDs, ChainIDt, NullifierHash, and MHash in the cross-chain operations. M and MHash are stored on the chain, and the TransferRWA contract event is triggered, passing the parameter NullifierHash (i.e., Figure 4 the step 308 shown).

[0085] As an optional implementation manner, when the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associating the target digital asset with the second user account includes: After processing the first specified private input and the first specified public input through the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained. Among them, the first specified public input includes the root hash value of the new hash tree and the first hash value marked as purchased, and the first specified private input includes at least one new random number and a new path proof; When the first zero-knowledge proof passes the verification, obtain the metadata digest and the 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 with the public key; Decrypt the metadata digest with the private key corresponding to the public key, and calculate the hash value of the decrypted data to obtain the metadata digest decryption value; When it is determined that the metadata digest decryption value is the same as the metadata digest hash value by performing a comparison operation within a preset time period, obtain the target digital asset by destroying the digital asset unit purchase, and associate the target digital asset with the second user account.

[0086] Specifically, after the second user account User2 on Chain II determines that the TransferRWA contract event occurs, obtain the parameter first hash value NullifierHash (i.e., Figure 4In step 309) as shown, call the WithdrawRWA(Root, NullifierHash, NewNullifierHash, Proof4) function (i.e., the asset withdrawal function), 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 In step 310) as shown. Proof4 must be constructed by User2 locally by executing Alg2 (i.e., the target arithmetic circuit in this embodiment can be Alg2), taking the Root in step 304 (i.e., the root hash value of the new hash tree) and NewNullifierHash (i.e., the new nonce hash value) as the first specified public inputs, and Secret, Nullifier (i.e., at least one new nonce) and Merkle proof (i.e., the new path proof) as the first specified private inputs to generate Proof4. WithdrawRWA will verify Proof4 (i.e., the first zero-knowledge proof in this embodiment). After successful verification, it will obtain M (i.e., the metadata digest) and MHash (i.e., the 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 In step 311) as shown. User2 can decrypt M using the private key Prikt corresponding to Pukt and perform a hash operation on it to obtain NewMHash (i.e., the decrypted value of the metadata digest). That is, when it is determined through a comparison operation at time T (i.e., the preset time period) that the decrypted value of the metadata digest 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.

[0087] As an alternative implementation, the method further includes: When the second user account on the target chain feedbacks that the decrypted value of the metadata digest and the metadata digest hash value are not determined to be the same within the preset time period, an inconsistent message is passed to the cross-chain transfer protocol; The cross-chain transfer protocol passes 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 inconsistent 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.

[0088] That is to say, when the second user account User2 has an inconsistency between NewMHash and MHash within the time T (i.e., the preset time period), the following parameters are provided: RWAIDs, NullifierHash, M, MHash, V, ChainIDs, ChainIDt, Addresst, where 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, and this address can be a temporary address. Then, an inconsistency message is transmitted to the cross-chain transfer protocol, and then the inconsistency message is transmitted to the source chain through the cross-chain transfer protocol. The source chain compares the metadata digest hash value of the target digital asset created by User1 on the chain with MHash. If they are inconsistent, V tokens (i.e., digital asset units) are returned to the Addresst address on Chain II, and the RWA assets on Chain I are locked. When a user performs a withdrawal operation, the user address is added to the blacklist.

[0089] As an optional implementation manner, the digital asset unit consistent with the value of the target digital asset can be extracted from the second contract through the steps described below: After the source chain processes the second specified private input and the second specified public input through the target arithmetic circuit, a third zero-knowledge proof that meets the constraint conditions of the target arithmetic circuit is obtained, and the target digital asset is extracted from the first contract, and the first hash value is marked as to-be-withdrawn, so that the first user account cannot withdraw the target digital asset. The second specified public input includes the root hash value of the hash tree and the first hash value marked as to-be-withdrawn, and the second specified private input includes the second random number in at least one random number, the asset ID corresponding to the target digital asset, and the path proof.

[0090] That is to say, in this embodiment, the second designated public input includes the Root and NullifierHash in step 401, and the second designated private input includes the second random number Secret in at least one random number, RWAIDs (asset ID corresponding to the target digital asset) and Merkle proof (i.e., path proof) as private input, and constructs a third zero-knowledge proof Proof3. The TransferRWA function will verify Proof3. After the verification is passed, Vs tokens will be extracted from the contract, the status of NullifierHash will be updated to "pending withdrawal" and the cross-chain operation will be triggered, passing parameters M, ChainIDs, ChainIDt, NullifierHash, and MHash. However, at this time, NullifierHash is locked and it takes T time to withdraw money. This setting can effectively prevent Chain I from passing the wrong M when executing the TransferRWA function, so as to leave it for users on Chain II to verify the assets.

[0091] The constraints of the target arithmetic circuit may be the following conditions as mentioned above: First, the target arithmetic circuit hashes the private input Nullifier using the MiMC hash 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 uniquely corresponds to a Nullifier, and prevents the reuse of the same Nullifier through NullifierHash, thereby effectively resisting double-spending attacks.

[0092] Secondly, the target arithmetic circuit hashes the private input RWAID through the MiMC hash algorithm, and compares the result with the public input RWAIDHash to verify that the user knows the original image of RWAIDHash. This process is to prevent the reuse of the same RWAID, thereby effectively resisting double-spending attacks.

[0093] Subsequently, the target arithmetic circuit combines Nullifier, RWAID and Secret and performs MiMC hash calculation again to generate the leaf node hash value LeafHash of the Merkle 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 to ensure that the user's declared token is legally stored in the anonymous transaction pool.

[0094] When the second user account of the target chain does not feedback that the metadata summary decryption value is different from the metadata summary hash value within a preset time period, after processing the first specified private input and the first specified public input through the target arithmetic circuit, a fourth zero-knowledge proof that meets the constraint conditions of the target arithmetic circuit is obtained, where the first specified public input includes the root hash value of the new hash tree and the new random number hash value, and the first specified private input includes at least one new random number and a new path proof; When the verification of the third zero-knowledge proof passes, the source chain extracts digital asset units from the contract to the first user account.

[0095] After waiting for T time (i.e., the preset time period), User1 on Chain I can execute the WithdrawToken (Root, NullifierHash, Addresss, Proof3) function (i.e., the virtual currency withdrawal function), where Root is the root hash value of the Merkle tree on Chain I, Addresss is any address on Chain I used to receive tokens, and Proof3 is the third zero-knowledge proof (i.e., Figure 4 the step 312 shown). WithdrawToken will verify Proof3. After the verification passes, it extracts V tokens (i.e., virtual currencies with the same value of the asset) from the contract to the account address Address of Chain I and triggers the WithdrawToken contract event, passing the parameter NullifierHash (i.e., Figure 4 the step 313 shown).

[0096] Since in the process of conducting transactions, the target chain uses zero-knowledge proofs to complete the transactions of target digital assets, it can achieve the purpose of verifying the legality of transactions without exposing transaction-sensitive information (such as specific amounts, real addresses, and original data), achieving the technical effect of hiding and avoiding the leakage of sensitive information, and thus solving the problem in related technologies that the privacy of cross-chain digital asset transactions cannot be effectively protected.

[0097] According to another aspect of the embodiments of the present application, a cross-chain digital asset transaction method applied to a cross-chain transmission protocol is further provided. The method includes: In the case where the cross-chain transfer protocol obtains a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain, the cross-chain transfer protocol transfers 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 after a second user account on the target chain determines a contract event triggered by the second contract, the second user account obtains the target digital asset parameters, generates a target digital asset on the target chain, and associates the target digital asset with the second user account when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset. The digital asset transaction request is used to request a transaction of the target digital asset.

[0098] In this embodiment, the cross-chain digital asset transaction method applied to the cross-chain transfer protocol may refer to the relevant implementation manners corresponding to the cross-chain transfer protocol in the cross-chain digital asset transaction method in the foregoing embodiment, and will not be elaborated herein.

[0099] As an alternative implementation manner, as in the foregoing method, the cross-chain transfer protocol transfers the target digital asset parameters obtained based on the first transaction parameters to the target chain, including: The cross-chain transfer protocol executes an asset status update function of a second contract on the target chain indicated by the first transaction parameters, marks the first hash value in the obtained target digital asset parameters as to be traded, and then obtains the target digital asset parameters, and transfers the target digital asset parameters to the target chain; After the transaction of the target digital asset is completed, the method further includes: the target chain marks the first hash value as traded.

[0100] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0101] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence 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), RAM (Random Access Memory), magnetic disk, optical disc), and includes several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present application.

[0102] According to another aspect of the embodiments of the present application, there is also provided a cross-chain digital asset trading system for implementing the above cross-chain digital asset trading method. Figure 5 is a structural block diagram of an optional cross-chain digital asset trading system according to an embodiment of the present application, as Figure 5 shown, the device may include: A source chain 51, configured to obtain a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, where the digital asset trading request is used to request a transaction for a target digital asset; A cross-chain transmission protocol 52, configured to transfer the target digital asset parameters corresponding to the digital asset trading request to a target chain, and trigger a second contract on the target chain according to the digital asset trading request; The target chain 53 is configured to, after a second user account on the target chain determines a contract event triggered by the second contract, obtain the target digital asset parameters, generate the target digital asset on the target chain, and associate the target digital asset with the second user account when the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, thereby completing the transaction of the target digital asset.

[0103] 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.

[0104] Through the above-mentioned module, since in the process of conducting a transaction, the target chain completes the transaction of the target digital asset through zero-knowledge proof, it is possible to achieve the purpose of verifying the legality of the transaction without exposing sensitive transaction information (such as specific amounts, real addresses, original data), achieving the technical effect of hiding and preventing the leakage of sensitive information, and thus solving the problem in the related art that the privacy of cross-chain digital asset transactions cannot be effectively protected.

[0105] The device in this embodiment, in addition to including the above-mentioned module, may also include a module for executing any method in the embodiments of the cross-chain digital asset transaction method described above.

[0106] It should be noted here that the examples and application scenarios implemented by the above-mentioned module and the corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above-mentioned module, as a part of the device, can run in the hardware environment as shown in Figure 1 and can be implemented by software or by hardware, where the hardware environment includes a network environment.

[0107] According to another aspect of the embodiments of the present application, there is also provided a transmission protocol for cross-chain digital asset transactions, which is used for: When the cross-chain transmission protocol 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 transfers 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 after a second user account on the target chain determines a contract event triggered by the second contract, it obtains the target digital asset parameters, generates the target digital asset on the target chain, and when a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associates the target digital asset with the second user account to complete the transaction of the target digital asset, where the digital asset transaction request is used to request a transaction of the target digital asset.

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

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

[0110] If the integrated unit in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the above computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing one or more computer devices (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0111] In the above embodiments of this application, the descriptions of the various embodiments each have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0112] In the several embodiments provided by this application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0113] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution provided in this embodiment.

[0114] In addition, the functional units in the various embodiments of this application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0115] The above are only the preferred embodiments of this application. It should be noted that for those of ordinary skill in the art of this technology, without departing from the principle of this application, several improvements and refinements can still be made, and these improvements and refinements should also be regarded as the protection scope of this application.

Claims

1. A cross-chain digital asset trading method, characterized in that, Including: The source chain obtains a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, wherein the digital asset trading request is used to request a transaction of a target digital asset; The cross-chain transfer protocol transfers the target digital asset parameters corresponding to the digital asset trading request to the target chain and triggers a second contract on the target chain according to the digital asset trading request; After a second user account on the target chain determines a contract event triggered by the second contract, obtains the target digital asset parameters, generates the target digital asset on the target chain, and in the case where a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associates the target digital asset on the target chain with the second user account to complete the transaction of the target digital asset.

2. The method according to claim 1, wherein: After the source chain obtains a digital asset trading request initiated by a first user account on the source chain by invoking a first contract on the source chain, the method further includes: the source chain invokes a hash function in the first contract to perform hash processing on 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 according to the random number hash value; The cross-chain transfer protocol transfers the target digital asset parameters corresponding to the digital asset trading request to the target chain, including: the cross-chain transfer protocol transfers the target digital asset parameters obtained based on first transaction parameters to the target chain, wherein the first transaction parameters are parameters included in the digital asset trading request, and the target digital asset parameters at least include a first hash value corresponding to a first random number among the at least one random number; In the case where a first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associating the target digital asset on the target chain with the second user account includes: the target chain processes a private input and a public input through a target arithmetic circuit to obtain a 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, and the private input includes the at least one random number and the path proof; in the case where the first zero-knowledge proof passes the verification, associating the target digital asset with the second user account.

3. The method according to claim 2, characterized in that, The constraint conditions include: A verification hash value obtained by performing hash calculation on a random number to be verified in the private input is consistent with the public input; By using the root hash value in the public input and the path proof in the private input, it is determined that the random number hash value generated by all random numbers in the private input is a leaf node of the hash tree.

4. The method according to claim 2, wherein In the case where the digital asset trading 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 destroys the target digital asset located on the source chain under the condition that the second zero-knowledge proof constructed according to the target digital asset parameters passes the verification, it includes: after the source chain processes the private input and the public input through the target arithmetic circuit, a second zero-knowledge proof that meets the constraint conditions of the target arithmetic circuit is obtained, where 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 the digital asset of the target denomination unit among at least one candidate denomination unit; after the second zero-knowledge proof passes the verification, execute the digital asset destruction function, delete the target digital asset located 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 according to the obtained first hash value marked as destroyed; The target chain obtains the target digital asset parameters, including: when the target chain determines the digital asset destruction event, it obtains the target digital asset parameters.

5. The method according to claim 2, characterized in that 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 passes the verification, 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, the root hash value of the new hash tree, and a new path proof according to 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, where 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, marks the first hash value as purchased through the asset status update function on the source chain, and transmits the first hash value marked as purchased and the public key to the source chain; After the first user account on the source chain determines the purchase event triggered by the second contract, it obtains the first hash value marked as purchased and the public key. When the third zero-knowledge proof constructed according to the first hash value marked as purchased passes the verification, it extracts digital asset units with a value consistent with that of the target digital asset from the first contract, where the digital asset units originally belonged to the second user account, and the digital asset units are digital assets of the target denomination unit among at least one candidate denomination unit.

6. The method according to claim 5, wherein When the first zero-knowledge proof constructed according to the target digital asset parameters passes the verification, associating the target digital asset with the second user account includes: After processing the first specified private input and the first specified public input through the target arithmetic circuit, a first zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained. Among them, the first specified public input includes the root hash value of the new hash tree and the new random number hash value, and the first specified private input includes the at least one new random number and the new path proof; When the first zero-knowledge proof passes the verification, obtain the metadata digest and the metadata digest hash value transmitted by the cross-chain transfer protocol. Among them, the metadata digest is obtained by encrypting the metadata of the target digital asset with the public key; Decrypt the metadata digest with the private key corresponding to the public key, and calculate the hash value of the decrypted data to obtain the metadata digest decryption value; When it is determined that the metadata digest decryption value is the same as the metadata digest hash value through the comparison operation within the preset time period, obtain the target digital asset by destroying the digital asset unit purchase, and associate the target digital asset with the second user account.

7. The method according to claim 6, characterized in that, The extracting the digital asset unit with the same value as the target digital asset from the second contract includes: After the source chain processes the second specified private input and the second specified public input through the target arithmetic circuit, a third zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained, extract the target digital asset from the first contract, and mark the first hash value as to-be-withdrawn, so that the first user account cannot withdraw the target digital asset. Among them, the second specified public input includes the root hash value of the hash tree and the first hash value marked as to-be-withdrawn, and the second specified private input includes the second random number in the at least one random number, the asset ID corresponding to the target digital asset, and the path proof; When the second user account of the target chain does not feedback that the metadata digest decryption value is different from the metadata digest hash value within the preset time period, after processing the first specified private input and the first specified public input through the target arithmetic circuit, a fourth zero-knowledge proof that satisfies the constraint conditions of the target arithmetic circuit is obtained. Among them, the first specified public input includes the root hash value of the new hash tree and the new random number hash value, and the first specified private input includes the at least one new random number and the new path proof; When the third zero-knowledge proof passes the verification, the source chain extracts the digital asset unit from the contract to the first user account.

8. The method according to claim 6, wherein The method further includes: When the second user account of the target chain feedbacks that it is not determined that the metadata digest decryption value is the same as the metadata digest hash value within the preset time period, transmit an inconsistent message to the cross-chain transfer protocol; The cross-chain transfer 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 inconsistent 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.

9. A cross-chain digital asset trading system, characterized in that, Including: A source chain for obtaining a digital asset transaction request initiated by a first user account on the source chain by invoking a first contract on the source chain, where the digital asset transaction request is used to request a transaction for a target digital asset; 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 a second contract on the target chain according to the digital asset transaction request; The target chain is used to obtain the target digital asset parameters after the second user account on the target chain determines the contract event triggered by the second contract, generate the target digital asset on the target chain, and associate the target digital asset with the second user account under the condition that the first zero-knowledge proof constructed according to the target digital asset parameters is verified, thereby completing the transaction of the target digital asset.

10. A transmission protocol for cross-chain digital asset transactions, characterized in that, For: When the source chain obtains a digital asset transaction request initiated by a first user account on the source chain by invoking 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 can obtain the target digital asset parameters after determining the contract event triggered by the second contract, generate the target digital asset on the target chain, and associate the target digital asset with the second user account under the condition that the first zero-knowledge proof constructed according to the target digital asset parameters is verified, thereby completing the transaction of the target digital asset, where the digital asset transaction request is used to request a transaction for a target digital asset.

Images