Method and system for carrying out block chain distributed account book transaction by utilizing unspent transaction output Merkel tree data structure

Abstract

The invention provides an improved computer privacy method to allow distributed account book transactions of specially configured block chain smart contracts to be processed based on a block chain privacy transaction protocol. The method describes an encryption process, and corresponding devices and computer program products using a pair of specialized UTXO Merkel tree data structures, authentication logout based on zero-knowledge proof, and public-private key pairs. The process includes storing a transaction amount as a UTXO into a first Merkel tree data structure and confirming the transaction by declaring ownership on the UTXO in the first Merkel tree data structure using a private token, and moving the UTXO into a second Merkel tree data structure for redemption.

Description

Technical Field

[0001] The present invention relates to the technical fields of computer architecture and inter-process encrypted data communication, and particularly to a method and system for blockchain distributed ledger transactions using an unspent transaction output (UTXO) Merkle tree data structure. Background Art

[0002] One technical challenge in decentralized blockchain transactions is that the recording process creates an immutable record through which a third party can identify the sender's wallet address, the recipient's wallet address, and the field corresponding to the transfer amount. This privacy issue is due to the technical characteristics and architecture of the blockchain's transaction propagation and consensus mechanisms, as the distributed ledger is updated with each block.

[0003] Therefore, in the current blockchain architecture, transactions are not private. A blockchain transaction protocol is needed to enhance the privacy of each transaction so that a third party cannot view or access the details of the transaction (e.g., the parties involved, the transaction amount, etc.).

[0004] In addition, there are some technical challenges in existing privacy-enhanced transaction (PET) protocols. For example, some PET protocols utilize the functions of the blockchain but do not support smart contracts, which hinders business scalability and implementation.

[0005] Account balance management based on accounts in PET can cause concurrency issues due to hidden transaction amounts. Since the account balance is constantly changing, the zero-knowledge proofs generated based on the current balance become invalid. The implementation of zero-knowledge proofs is also too complex, resulting in high verification costs and excessive blockchain transaction fees (gas).

[0006] Some protocols use the unspent transaction output (UTXO) model, but their architecture design is often too complex for the client. For example, the client usually needs to maintain Merkle tree proofs consistent with the contract state and attempt to decrypt each transaction in the system. It may even need to know the public keys of any potential participants who may transfer funds to the client. Since the participants and amounts of each transfer are encrypted / hidden, the funds can never be withdrawn if the recipient cannot know that a certain sender has transferred tokens to them. The current system lacks the ability to support non-repudiation without third-party intervention. Summary of the Invention

[0007] The present invention proposes an improved method based on computational privacy to allow processing of distributed ledger transactions for blockchain privacy-enabled transaction protocols for specially configured blockchain smart contracts. The method describes an encryption process, as well as corresponding devices and computer program products using a pair of specialized UTXO Merkle tree data structures, a zero-knowledge proof-based authentication invalidator, and a set of public-private key pairs. The process includes storing the transaction amount as a UTXO in a first Merkle tree data structure (i.e., the pending UTXO Merkle tree), and confirming the transaction by claiming ownership of the UTXO in the first Merkle tree data structure using a private token, and moving the UTXO to a second Merkle tree data structure (i.e., the confirmed UTXO Merkle tree) for redemption.

[0008] A Merkle tree is a data structure where each "leaf" node is labeled with the cryptographic hash value of a data block, and each non-leaf node (i.e., branch) is labeled with the cryptographic hash value of its child node labels. The Merkle tree data structure allows for efficient and secure verification of the content of large data structures and helps ensure that data blocks received from other entities in the network have not been corrupted or tampered with.

[0009] In this method, both the sender and the receiver of funds can claim ownership of UTXOs from the pending and confirmed UTXO Merkle trees, ensuring that UTXOs are not lost during a transaction or wallet client recovery process. By storing the pending UTXOs in the pending Merkle tree and the confirmed UTXOs in the confirmed UTXO Merkle tree, the information in the private token can be decrypted using only the private key of the sender or receiver, without the need for the sender's public key. This ensures that UTXOs in the confirmed UTXO Merkle tree are not left unclaimed. Merkle tree proofs can be provided from the Merkle tree through a public function of the proposed smart contract, so that the client does not need to maintain a complete mirror of the same UTXO Merkle tree as on the smart contract.

[0010] The process of moving UTXOs from the pending Merkle tree to the confirmed Merkle tree can be clearly recorded and distinguished as initiated by the sender or the receiver through the proposed smart contract, without the assistance of a third party. This allows for clear resolution of any potential transaction issues. The method utilizes smart contracts to achieve business scalability. The smart contract requires different zero-knowledge proof (ZKP) verification logic when verifying the sender and the receiver, and the differences between the two parties in this verification method are also recorded in the transaction data.

[0011] Moving UTXOs from the pending Merkle tree to the confirmed Merkle tree authorizes transactions using the ZKP method. When the recipient wishes to extract and generate new confirmed UTXOs from the pending UTXOs in the pending Merkle tree, the recipient can use a hash function to generate a pending authentication revocation symbol. The pending authentication revocation symbol has a direct relationship with the pending UTXO, but this relationship cannot be identified by the hash value. Therefore, ZKP can be used to verify that the recipient has provided the correct input without revealing or knowing the actual input value. Other entities can attempt to verify the ZKP logic, but only the recipient will have the correct pending authentication revocation symbol as input.

[0012] The proposed method uses the Circom programming language to implement a zero-knowledge proof circuit with clear and simple logic, and can automatically generate verification code on the contract side. Using UTXOs effectively eliminates the concept of total balance and facilitates the solution of concurrency problems. The method also ensures that UTXOs are not stuck or unclaimed, as the sender can always retrieve or extract the UTXOs.

[0013] The use of the pending UTXO Merkle tree is the key to the proposed method of the present invention. The pending UTXO Merkle tree sets the conditions and time limits for unlocking funds, ensuring that only recipients who provide the correct unlocking information (e.g., their own private key) can access and obtain the transferred funds.

[0014] Embodiments of the present invention provide a computing system for processing private blockchain distributed ledger transactions using two UTXO Merkle tree data structures. The system includes a computer processor coupled to a computer memory and a non-volatile computer-readable storage medium. The computer processor is configured to persist an intelligent contract data object that includes a pending UTXO Merkle tree data structure and a confirmed UTXO Merkle tree data structure. The computer processor is configured to: receive a set of tokens from a sender blockchain wallet that are sent to a receiver blockchain wallet; generate and insert a first set of confirmed UTXOs corresponding to the set of tokens into the confirmed UTXO Merkle tree data structure; receive a transfer request from the sender blockchain wallet to transfer the set of tokens to the receiver blockchain wallet; and verify the transfer request and the sender blockchain wallet using a first confirmed nullifier. After successfully verifying the transfer request, the computer processor is configured to generate and insert a set of pending UTXOs into the pending UTXO Merkle tree data structure. The computer processor records the first confirmed nullifier in the intelligent contract data object and destroys the first set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure, where the pending UTXOs are encrypted using public keys associated with the sender blockchain wallet and the receiver blockchain wallet. Then, the computer processor is configured to receive an extraction request from an owner to extract the set of pending UTXOs, where the owner is one of the sender blockchain wallet and the receiver blockchain wallet; the computer processor verifies the extraction request and the owner using a pending nullifier. After successfully verifying the extraction request, the computer processor is configured to extract the set of pending UTXOs from the pending UTXO Merkle tree data structure, generate a second set of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, and record the pending nullifier in the intelligent contract data object. Then, the computer processor is configured to receive a withdrawal request from the owner to withdraw the set of tokens; verify the withdrawal request using a second confirmed nullifier. After successfully verifying the withdrawal request, the computer processor is configured to transfer the set of tokens to the owner, record the second confirmed nullifier in the intelligent contract data object, and destroy the second set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure.

[0015] In some embodiments, the computer processor generates a pending nullifier using a pending random number, an elliptic curve Diffie-Hellman (ECDH) shared key, and a hash function of the values of the plurality of tokens.

[0016] In some embodiments, the computer processor generates the first and second confirmed nullifiers using a confirmation random number, the private key of the owner, and a hash function of the values of the plurality of tokens.

[0017] In some embodiments, the computer processor uses zero - knowledge proofs and Circom circuits to verify transfer requests to prove that the first set of confirmed UTXOs exists in the confirmed UTXO Merkle tree data structure. Among them, the first confirmed nullifier is mapped to the first set of confirmed UTXOs; the first confirmed nullifier is not recorded in the smart contract data object; the pending UTXOs do not exist in the pending UTXO Merkle tree data structure; and the first set of confirmed UTXOs and the pending UTXOs correspond to the same token value.

[0018] In some embodiments, the computer processor uses zero - knowledge proofs and Circom circuits to verify withdrawal requests to prove that the pending UTXOs exist in the pending UTXO Merkle tree data structure. Among them, the pending nullifier is mapped to the pending UTXOs and is not recorded in the smart contract data object; the second set of confirmed UTXOs does not exist in the confirmed UTXO Merkle tree data structure, and the pending UTXOs and the second set of confirmed UTXOs correspond to the same token value.

[0019] In some embodiments, the computer processor uses zero - knowledge proofs and Circom circuits to verify withdrawal requests to prove that the second set of confirmed UTXOs exists in the confirmed UTXO Merkle tree data structure. Among them, the second confirmed nullifier is mapped to the second set of confirmed UTXOs, and the second confirmed nullifier is not recorded in the smart contract data object.

[0020] In some embodiments, the smart contract data object further includes an event bus that the recipient blockchain wallet can query to check the pending UTXOs assigned to the recipient blockchain wallet in the pending UTXO Merkle tree data structure.

[0021] In some embodiments, the computer processor is further configured to set an expiration time limit and, when the time limit expires and the pending UTXOs have not been withdrawn within the expiration time limit, automatically withdraw this set of pending UTXOs from the pending UTXO Merkle tree data structure and return this set of tokens to the sender blockchain wallet.

[0022] In some embodiments, the recipient blockchain wallet is a custodial wallet that can be accessed by multiple entities to withdraw and use the pending UTXOs in the pending UTXO Merkle tree data structure and the second set of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, where the multiple entities can access the custodial wallet simultaneously through access control.

[0023] In some embodiments, the computer processor is further configured to generate a UTXO designated for the sender blockchain wallet as change after successfully verifying the transfer request.

[0024] On the other hand, embodiments of the present invention provide a computing method for processing private blockchain distributed ledger transactions using two UTXO Merkle tree data structures. The method includes persisting a smart contract data object that includes a pending UTXO Merkle tree data structure and a confirmed UTXO Merkle tree data structure. The method includes: receiving a set of tokens from a sender blockchain wallet that are to be sent to a receiver blockchain wallet; generating and inserting a first set of confirmed UTXOs corresponding to the set of tokens into the confirmed UTXO Merkle tree data structure; receiving a transfer request from the sender blockchain wallet to transfer the set of tokens to the receiver blockchain wallet; and verifying the transfer request and the sender blockchain wallet using a first confirmed nullifier. After successfully verifying the transfer request, the method further includes: generating and inserting a set of pending UTXOs into the pending UTXO Merkle tree data structure, recording the first confirmed nullifier in the smart contract data object, and destroying the first set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure. Wherein the pending UTXOs are encrypted using public keys associated with the sender blockchain wallet and the receiver blockchain wallet. The method further includes receiving an extraction request from an owner to extract the set of pending UTXOs, where the owner is one of the sender blockchain wallet and the receiver blockchain wallet, and verifying the extraction request and the owner using a pending nullifier. After successfully verifying the extraction request, the method further includes extracting the set of pending UTXOs from the pending UTXO Merkle tree data structure, generating a second set of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, and recording the pending nullifier in the smart contract data object. The method further includes receiving a withdrawal request from the owner to withdraw the set of tokens and verifying the withdrawal request using a second confirmed nullifier. After successfully verifying the withdrawal request, the method includes transferring the set of tokens to the owner, recording the second confirmed nullifier in the smart contract data object, and destroying the second set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure.

[0025] In some embodiments, the pending nullifier is generated using a pending random number, an elliptic curve Diffie-Hellman (ECDH) shared key, and a hash function of the values of multiple tokens.

[0026] In some embodiments, the first and second confirmed nullifiers are generated using a confirmed random number, the private key of the owner, and a hash function of the values of multiple tokens.

[0027] In some embodiments, verifying a transfer request involves using zero - knowledge proofs and Circom circuits to prove that a first set of confirmed UTXOs exists in the confirmed UTXO Merkle tree data structure. Herein, the first confirmed nullifier maps to the first set of confirmed UTXOs; the first confirmed nullifier is not recorded in the smart contract data object; multiple pending UTXOs do not exist in the pending UTXO Merkle tree data structure; and the first set of confirmed UTXOs and the multiple pending UTXOs correspond to the same token value.

[0028] In some embodiments, verifying a withdrawal request involves using zero - knowledge proofs and Circom circuits to prove that multiple pending UTXOs exist in the pending UTXO Merkle tree data structure. Herein, the pending nullifier maps to the multiple pending UTXOs; the pending nullifier is not recorded in the smart contract data object; a second set of confirmed UTXOs does not exist in the confirmed UTXO Merkle tree data structure; and the multiple pending UTXOs and the second set of confirmed UTXOs correspond to the same token value.

[0029] In some embodiments, verifying a withdrawal request involves using zero - knowledge proofs and Circom circuits to prove that a second set of confirmed UTXOs exists in the confirmed UTXO Merkle tree data structure. Herein, the second confirmed nullifier maps to the second set of confirmed UTXOs, and the second confirmed nullifier is not recorded in the smart contract data object.

[0030] In some embodiments, the smart contract data object in the computing method further includes an event bus that the receiving blockchain wallet can query to check for pending UTXOs assigned to the receiving blockchain wallet in the pending UTXO Merkle tree data structure.

[0031] In some embodiments, the computing method also involves setting an expiration time limit and, when the time limit expires and the pending UTXOs are not withdrawn within the expiration time limit, automatically withdrawing the multiple pending UTXOs from the pending UTXO Merkle tree data structure and returning the multiple tokens to the sending blockchain wallet.

[0032] In some embodiments, the receiving blockchain wallet of the computing method is a custodial wallet, and multiple entities can access the custodial wallet to withdraw and use the multiple pending UTXOs in the pending UTXO Merkle tree data structure and the second set of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, where the multiple entities can access the custodial wallet simultaneously through access control.

[0033] Another aspect of the present invention provides a non - volatile computer - readable medium for storing computer - readable instructions that, when executed by a computer processor, cause the computer processor to perform a method of processing private blockchain distributed ledger transactions using two UTXO Merkle tree data structures. The method includes persisting a smart contract data object that includes a pending UTXO Merkle tree data structure and a confirmed UTXO Merkle tree data structure. The method includes: receiving a set of tokens from a sender blockchain wallet that are to be sent to a receiver blockchain wallet; generating and inserting a first set of confirmed UTXOs corresponding to the set of tokens into the confirmed UTXO Merkle tree data structure; receiving a transfer request from the sender blockchain wallet to transfer the set of tokens to the receiver blockchain wallet; and verifying the transfer request and the sender blockchain wallet using a first confirmed nullifier. After successfully verifying the transfer request, the method further includes: generating and inserting a set of pending UTXOs into the pending UTXO Merkle tree data structure, recording the first confirmed nullifier in the smart contract data object, and destroying the first set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure. Wherein the pending UTXOs are encrypted using public keys associated with the sender blockchain wallet and the receiver blockchain wallet. The method further includes receiving an extraction request from an owner to extract the set of pending UTXOs, where the owner is one of the sender blockchain wallet and the receiver blockchain wallet, and verifying the extraction request and the owner using a pending nullifier. After successfully verifying the extraction request, the method also includes extracting the set of pending UTXOs from the pending UTXO Merkle tree data structure, generating a second set of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, and recording the pending nullifier in the smart contract data object. The method further includes receiving a withdrawal request from the owner to withdraw the set of tokens and verifying the withdrawal request using a second confirmed nullifier. After successfully verifying the withdrawal request, the method includes transferring the set of tokens to the owner, recording the second confirmed nullifier in the smart contract data object, and destroying the second set of confirmed UTXOs from the confirmed UTXO Merkle tree data structure

[0034] Other features and advantages will be described hereinafter. Those skilled in the art should understand that the disclosed concepts and specific embodiments can be used as a basis for modifying or designing other structures. Those skilled in the art should also recognize that these equivalent structures do not depart from the spirit and scope of the embodiments described herein. The unique features of the present invention, whether in its organizational manner or operating method, as well as further objectives and advantages, will be better understood from the following description in conjunction with the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to define the limitations of the embodiments described herein BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a block diagram of an example system of a blockchain privacy transaction protocol for distributed ledger transactions using a UTXO Merkle tree data structure according to some embodiments of the present invention.

[0036] Figure 2 It shows a comparison chart between an example of an account balance blockchain model and an example of an unspent transaction output (UTXO) blockchain model according to some embodiments of the present invention.

[0037] Figure 3 It shows the components of an example UTXO Merkle tree data structure according to some embodiments of the present invention.

[0038] Figure 4 It shows a pair of dedicated UTXO Merkle tree data structures of an example smart contract of a blockchain privacy-enabled transaction protocol proposed according to some embodiments of the present invention.

[0039] Figure 5 It shows an example zero-knowledge proof for verification between UTXO and nullifiers according to some embodiments of the present invention.

[0040] Figure 6 It is a flowchart of an example transaction process of a smart contract proposed according to some embodiments of the present invention.

[0041] Figure 7 It is a flowchart of a deposit / minting process of an example private transaction of a smart contract proposed according to some embodiments of the present invention.

[0042] Figure 8 It is a flowchart of a transfer process of an example private transaction of a smart contract proposed according to some embodiments of the present invention.

[0043] Figure 9 It is a flowchart of a withdrawal process of an example private transaction of a smart contract proposed according to some embodiments of the present invention.

[0044] Figure 10 It is a flowchart of an extraction / destruction process of an example private transaction of a smart contract proposed according to some embodiments of the present invention.

[0045] Figure 11 It is a flowchart of a process of restoring a user wallet for an example private transaction of a smart contract proposed according to some embodiments of the present invention.

[0046] Figure 12 It is a schematic diagram of the structure of a computer device and a computer-readable medium carried thereon provided according to an aspect of the present invention. Detailed implementation manners

[0047] Privacy issues in blockchain transactions are becoming increasingly prominent. Although the transparent nature of blockchain ensures data security and transaction traceability, it also increases the risk of personal and business data exposure. Public transaction records can reveal user identities, asset details, and transaction behaviors, leading to privacy issues and subsequent economic losses and security threats.

[0048] The deficiencies of the prior art need to be addressed by a blockchain transaction protocol that provides enhanced privacy protection for each transaction, preventing third parties from viewing or accessing transaction details (e.g., the parties involved, transaction amounts, etc.). A private transaction refers to a transaction where only the participants (i.e., the sender and the recipient) can understand all the details. Third parties cannot access transaction information including the sender, the recipient, and the transaction amount.

[0049] Private transactions have become a key requirement in the blockchain field to protect users' sensitive information from unnecessary exposure. Examples of sensitive transactions include salary transactions, intra-family transfers (e.g., one child gets more pocket money than another), sensitive shopping information, etc.

[0050] Other deficiencies of the prior art additionally need to be remedied by a blockchain transaction protocol that allows the sender to cancel or revoke a transaction. Typical cryptocurrency transactions are irreversible after being confirmed and recorded on the blockchain, making it difficult or impossible to make changes or revoke them in case of errors. For example, if the receiving address is entered incorrectly, the recipient will not know that the sender has transferred tokens to them, and the funds may never be withdrawn and get stuck on the blockchain.

[0051] To achieve the ability of private transactions and transaction revocation, the present invention proposes an improved privacy method for handling a blockchain privacy transaction protocol executed by a specially configured blockchain smart contract distributed ledger. The method describes an encryption process, as well as corresponding devices and computer program products using a pair of dedicated UTXO Merkle tree data structures based on zero-knowledge proofs and public-private key pairs. The process includes storing the transaction amount as a UTXO in a first Merkle tree data structure, confirming the transaction by claiming ownership of the UTXO in the first Merkle tree data structure using a private token, and moving the UTXO to a second Merkle tree data structure for redemption.

[0052] An example method of private transactions is Anonymous Zether, a privacy payment system based on the EVM that aims to protect the privacy of blockchain transactions. It uses encryption and zero-knowledge proof (ZKP) techniques to hide the sender, recipient, and transaction amount while maintaining the security and transparency of the system. Anonymous Zether employs elliptic curve cryptography (ECC) to protect transaction data and uses zero-knowledge proofs to verify the validity of transactions without revealing specific information. One drawback of using Zether is that transactions are verified using on-chain ZKP technology, which results in high blockchain operating costs (gas). Additionally, if the recipient denies receiving funds, verification is not possible because all information, including the sender and transaction amount, is invisible.

[0053] Another example method of private transactions is Zeto, an application that provides a user interface to interact with the blockchain network. It uses the Zeta SDK to perform private transactions on the EVM. Users can connect their wallets, view account information, and conduct transactions. Zeto also incorporates third-party non-repudiation. Contracts can encrypt transfer information using a shared key combined with their own private key and the public key of a third-party regulatory entity and record the transaction on the blockchain. When a transfer dispute occurs, the third-party entity can intervene to verify the authenticity of the transaction. However, this method requires providing relevant evidence offline and involves third-party review of the evidence to confirm the correctness of the transaction.

[0054] Zcash is an example of a privacy-focused cryptocurrency. Zcash transactions can be transparent or can use a ZKP to provide anonymity for transactions. Zcash also offers the option of private transactions through the use of a "selective disclosure" feature, allowing users to prove payments for auditing purposes. The drawbacks of using Zcash are that it does not provide a non-repudiation feature and does not support smart contract infrastructure.

[0055] Figure 1 is a block diagram of an example system of a blockchain privacy transaction protocol for distributed ledger transactions using a UTXO Merkle tree data structure according to some embodiments of the present invention.

[0056] In Figure 1In this example, the system is a distributed computing system 100 that maintains, updates, and persists distributed ledger data objects among multiple computing nodes, and each node updates the distributed ledger data objects according to one or more logical consensus rule mechanisms used to control how updates are broadcast. In some embodiments, the distributed computing system 100 is a decentralized computing system that uses blockchain data objects to update the distributed computing system, and these data objects are sequentially coupled in a series of update blocks by encrypted hash data objects. And the distributed computing system 100 is configured to execute smart contract functions, where the distributed ledger can also be used to provide a runtime environment for transaction execution, as a deterministic state machine operating according to a Turing-complete instruction set.

[0057] The smart contract data object 102 is specially configured to improve privacy methods, suitable for enhancing privacy and non-repudiation, while supporting the reversibility of distributed ledger transactions using zero-knowledge proofs and auditor-generated public / private key pairs. The purpose of the proposed method is to improve existing privacy transaction protocols to enhance privacy while providing non-repudiation support and the ability to revoke transactions. Specifically, the special configuration provides a technical mechanism that uses the UTXO Merkle tree data structure to ensure data authenticity without exposing transaction information to non-participating parties.

[0058] The proposed smart contract data object 102 runs on the distributed computing system 100 and is associated with multiple parties to a transaction. The parties are represented by public keys 108 associated with a specific electronic wallet 104A belonging to the sender 104 and a specific electronic wallet 106A belonging to the receiver 106, and these wallet addresses can hold digital assets or digital objects on the distributed computing system 100. The smart contract data object 102 is configured to be able to store digital assets corresponding to the smart contract data object 102 itself, and transactions can occur between the parties in the smart contract data object 102, but third parties cannot interpret the transactions taking place because the specific parties to the transaction and the amount transferred are not public information.

[0059] Sender 104 registers its e-wallet 104A with the smart contract data object 102 to generate a smart contract private key 104B and a related public key. Sender 104 can send funds to recipient 106, which also has a wallet 106A registered with the smart contract data object 102 and a corresponding smart contract private key 106B. Sender 104 can deposit funds into the smart contract data object 102, and then the smart contract data object 102 generates privacy tokens to transfer to sender 104 and recipient 106, such that both sender 104 and recipient 106 can use the tokens to redeem funds later. When sender 104 deposits funds into the smart contract data object 102, the funds are converted into UTXOs and stored in the UTXO Merkle tree data structure 110. The smart contract data object 102 can have a transaction API to record transaction information, such as the amount of privacy tokens to be transferred and the parties. Recipient 106 can use its private key 106B to verify the transaction and redeem its privacy tokens to withdraw the stored funds.

[0060] The proposed method extends the existing privacy transaction protocol by introducing a series of functions to support non-repudiation and the ability to revoke transactions while maintaining transaction privacy. These functions are implemented through modifications and extensions to the smart contract, specifically including Figures 5-11 the several key functions described.

[0061] In some embodiments, a transaction can have more than two parties, which can be a controllable factor adjustable through the configuration of the underlying execution logic of the proposed smart contract data object 102.

[0062] Figure 2 A comparison between an example account model and an example unspent transaction output (UTXO) blockchain model is shown.

[0063] In the account model, each account maintains a single balance, and transactions directly update the balance by deducting from the sender's account and adding to the recipient's account. Thus, the balance of an account is tracked based on the overall account state rather than tracking the composition of the actual balance itself. For example, in Figure 2 Alice (A) starts with a balance of 6 ETH and Bob (B) starts with a balance of 8 ETH. If A sends 2 ETH to B, then A's balance becomes 4 ETH and B's balance becomes 10 ETH. The transaction essentially transfers 2 ETH from A's address to B's address.

[0064] In the UTXO model, a transaction involves the sender "consuming" UTXOs, enabling the sender to send tokens in the transaction and creating new UTXOs on behalf of the recipient representing the change amount. For example, in Figure 2In it, A starts with a balance of 6 UTXOs, and B starts with a group of 1 UTXO and 7 UTXOs, where each group represents a different transaction. When A spends 2 UTXOs to send 2 tokens to B, A's balance becomes 4 UTXOs, B receives 2 tokens, and as a result, 2 new UTXOs are created and listed as the third group in B's balance. After the transaction, A's original 6 UTXOs become 4 UTXOs in A's balance and 2 UTXOs in B's balance. A UTXO can be regarded as a token that allows an entity to spend / send. Each UTXO is non-fungible and can only be used once.

[0065] Using the UTXO model can prevent problems such as double spending, ensure that the inputs of transactions are equal to the outputs, and maintain the balance in the network. The UTXO model can also operate without central control, which allows for decentralized transaction management. The account model has scalability challenges when dealing with many accounts, while the UTXO model can overcome these challenges through its parallel transaction processing capabilities.

[0066] Figure 3 Shows the components of an example UTXO Merkle tree data structure.

[0067] A Merkle tree is a tree-like data structure where each leaf node is labeled with the cryptographic hash value of a data block, and each non-leaf node (i.e., a branch) is labeled with the cryptographic hash value of its child nodes' labels. The hash values are combined and hashed again from the leaves upwards at each layer of the tree, and the final hash value at the top layer (i.e., the Merkle root) is stored as a summary of all the transactions within the block. As Figure 3 shown, each data block (i.e., Data A, Data B, Data C, etc.) contains a UTXO transaction. The cryptographic hash value of each data block or UTXO transaction is used to label the leaf nodes at the bottommost layer of the Merkle tree (i.e., Hash A, Hash B, etc.). The hash values are combined in pairs, and each pair is hashed again to generate a new hash value for the layer above the leaf nodes (i.e., Hash AB, Hash CD, etc.). The hashing continues upwards until the top hash.

[0068] The Merkle root node can be stored in the block header and then added to the blockchain. When a new block is added to the blockchain, the Merkle root of the previous block is included in the header of the new block. This creates a chain of blocks in the blockchain, where each block contains the Merkle root of the previous block.

[0069] Merkle tree proof generation can be provided from the Merkle tree through the public functions of the proposed smart contract, so that the client does not need to maintain a complete mirror of the same UTXO Merkle tree as on the smart contract. As Figure 3As shown, to prove that the hash of data B exists in the Merkle tree, it is sufficient to provide a Merkle tree proof consisting of dark nodes. The verifier can then calculate the hash values of the dark nodes layer by layer and finally obtain the Merkle tree root node. The Merkle tree root node can then be compared with the Merkle tree root node obtained from another trusted registry to verify whether the Merkle tree has been tampered with.

[0070] In some solutions, the client locally maintains the entire Merkle tree by listening to smart contract events and generating Merkle tree proofs from the local Merkle tree data when needed. The drawback of these solutions is that if the client misses any event, the Merkle tree maintained by the client will be inconsistent with the Merkle tree maintained by the smart contract, resulting in a Merkle tree proof that cannot be verified by the smart contract.

[0071] In contrast, the embodiments proposed in this paper provide a smart contract data object for maintaining the entire Merkle tree. When the client needs to generate a Merkle tree proof to prove the existence of a specific leaf node in the tree, the client can obtain the Merkle tree proof by calling the function provided by the smart contract data object.

[0072] The Merkle tree provides enhanced security for cryptocurrency transactions. Due to the structure of the Merkle tree, any modification of the data within the tree can be easily detected because any change in the data block will generate a different hash value, which will propagate up the Merkle tree to the Merkle root node. Such a modification can be easily detected during the verification process. The ability to detect changes in the Merkle root node based on any differences in the data nodes allows for the quick identification of inconsistencies. The additional security provided by the Merkle tree for the blockchain makes it difficult for attackers to tamper with the data block information content.

[0073] Figure 4 Shows a pair of dedicated UTXO Merkle tree data structures for an example smart contract for the proposed blockchain privacy transaction protocol.

[0074] System 400 shows a pending UTXO sparse Merkle tree (SMT) data structure 110 and a confirmed UTXO SMT, each with a corresponding mapping of nullifiers. The embodiments described herein use the pair of pending and confirmed UTXO SMTs to manage Figure 1 UTXO transactions within smart contract 102. When the sender consumes a certain number of input UTXOs, some output UTXOs are generated and stored in the pending UTXO SMT until the receiver extracts them into the confirmed UTXO SMT, at which point the transaction is considered successfully completed.

[0075] The use of the pending Merkle tree is crucial in the proposed method. The pending UTXO SMT sets the conditions and time limits for unlocking funds, ensuring that only the intended recipient who provides the correct unlocking information and credentials (e.g., the recipient's private key) can access the transferred funds. The UTXOs in the pending UTXO SMT cannot be directly used for consumption but must be extracted into the confirmed UTXO SMT. Only the UTXOs in the confirmed UTXO SMT can be used and consumed. After a pending UTXO is extracted into the confirmed UTXO SMT, it is marked as used by recording its corresponding nullifier, and then a new UTXO is generated and inserted into the confirmed UTXO SMT.

[0076] The nullifier mapping included in system 400 specifies the nullifiers that can be used to extract UTXOs from the SMT. Specifically, only the pending nullifiers that are one-to-one mapped to the pending UTXOs can be used to extract the pending UTXOs from the pending UTXO SMT. Similarly, only the confirmed nullifiers that are one-to-one mapped to the confirmed UTXOs can be used to extract the confirmed UTXOs from the confirmed UTXO SMT. This is described in more detail below. Figure 5 This is described in more detail below.

[0077] In the proposed method, the user / client needs to provide a nullifier to prove ownership of a specific UTXO. Both the nullifier and the UTXO are hash values, and the relationship between them is proven through a ZKP circuit.

[0078] There are two versions of the ZKP circuit corresponding to the sender and the recipient (although the values of the pending nullifiers generated by the sender and the recipient are the same). The first version is used by the sender, and the second version is used by the recipient. In the first version for the sender, the ZKP circuit is used to prove that the sender's private key can be used to derive the senderPubKey. In the second version for the recipient, the ZKP circuit is used to prove that the recipient's private key can be used to derive the recipientPubKey. Therefore, when calling the function of the smart contract 102 to verify the ZKP, the version of the circuit being used must be declared. The smart contract 102 can record whether a specific pending UTXO was extracted by the sender or the recipient. Additionally, combined with the OHPETPendingUTXOEvent containing the recipientPubKey, the sender has enough information to prove that the specified recipient performed the extraction operation using their own public key.

[0079] A nullifier is a hash value that is one-to-one mapped to a specified UTXO, enabling the owner / user to provide the nullifier and verify it against the UTXO through zero-knowledge proof. Only the recipient or the sender can generate the nullifier that can decrypt and extract the corresponding UTXO.

[0080] In some embodiments, the smart contract can be designed such that transferred funds can be redeemed by multiple parties, and multiple parties can withdraw and consume the UTXOs of the same recipient account. An example implementation is to have multiple participants create a escrow wallet. Through access control, multiple parties can access the escrow wallet simultaneously, and the information of the operator can be recorded.

[0081] As Figure 5 shown, the Pending UTXO can be generated by the following function:

[0082] Pending UTXO = hash(senderPubKey,recipientAddr,tokenValue,noncePending)(1)

[0083] The Pending Nullifier can be generated by the following hash function:

[0084] Pending Nullifier = hash(encrypt(ECDH - shared - secret,(tokenValue,noncePending)))(2)

[0085] Once the Pending UTXO is inserted into the Pending UTXO SMT, the smart contract 102 will publicly transmit a smart contract event OHPETPendingUTXOEvent, which includes the following information: the public key of the recipient, the public key of the sender, tokenValue, and noncePending. This information is encrypted twice, once using the sender's public key and once using the recipient's public key. Thus, both the recipient and the sender can decrypt the information using their own private keys. This ensures that the recipient or the sender (but no third party) can generate the nullifier, extract the Pending UTXO from the Pending UTXO SMT, and generate a new confirmed UTXO with the same tokenValue in the Confirmed UTXO SMT.

[0086] The noncePending value in the above formulas (1) and (2) is set to generate different UTXOs even when the amounts and participants are the same. The noncePending value is generated by the sender before initiating the transfer and is sent in the OHPETPendingUTXOEvent after being encrypted through two independent encryption processes using the public keys of the two participants.

[0087] In some embodiments, the secret key is generated using the Elliptic Curve Cryptography (ECC) method. Using the existing ECC key pair (i.e., private key and public key) and the generated ephemeral ECC key pair (i.e., ephemeral private key and ephemeral public key), specifically the public key and the ephemeral private key, the Elliptic Curve Diffie-Hellman (ECDH) shared key in function (2) can be calculated. Then, the message can be encrypted with AES using the shared key to generate the ciphertext. The final encrypted content is a combination of the ephemeral public key and the ciphertext. During the decryption process, the ephemeral public key must be extracted from the final encrypted content. The shared key can also be recalculated according to ECDH using the ephemeral public key and the original private key. The decrypting party can use the shared key to decrypt the ciphertext back to the original message.

[0088] The sender or the receiver can use their respective private keys to decrypt the OHPETPendingUTXOEvent message and obtain the public keys, tokenValue, and noncePending of the two participants. If the decryption is successful, the user can construct a nullifier according to the pending nullifier construction rules, and then query the smart contract 102 to verify whether the nullifier has been used. If the nullifier has not been used, the user can extract the UTXO into the confirmed UTXO SMT.

[0089] In some embodiments, if the user is unable to fully recover their UTXO from the pending UTXO SMT for various reasons, the sender of these missed UTXOs can choose to extract them into the confirmed UTXO SMT at any time.

[0090] As Figure 5 shown, the confirmed UTXO can be generated by the following hash function:

[0091] Confirmed UTXO = hash(ownerPrivateKey, tokenValue, nonceConfirmed)(3)

[0092] The confirmed nullifier can be generated by the following hash function:

[0093] Confirmed Nullifier=hash(hash(ownerPrivateKey),hash(tokenValue),hash(nonceConfirmed))(4)

[0094] The nonceConfirmed value in formulas (3) and (4) is generated by the UTXO owner before extraction from the pending UTXO SMT and sent in the OHPETConfirmedUTXOEvent.

[0095] When a new confirmed UTXO is inserted into the confirmed UTXO SMT, the smart contract 102 will publicly transmit a smart contract event OHPETConfirmedUTXOEvent, which contains the tokenValue and nonceConfirmed. This information is encrypted using the owner's public key. Any user can attempt to decrypt the encrypted tokenValue and nonceConfirmed from the OHPETConfirmedUTXOEvent. The user must be the owner of the relevant UTXO to successfully decrypt, and can use the decrypted tokenValue and nonceConfirmed along with its private key to generate a confirmation cancellation symbol to consume the UTXO. After using the cancellation symbol, the smart contract 102 records it to prevent double spending of the UTXO.

[0096] Users can attempt to decrypt the OHPETConfirmedUTXOEvent message using their own private key to obtain the tokenValue and nonceConfirmed values. If the decryption is successful (i.e., the user is the recipient or sender), the user can construct a cancellation symbol according to the confirmation cancellation symbol construction rules, and then query the smart contract 102 to verify whether the cancellation symbol has been used. If the cancellation symbol has not been used, the user can use the relevant UTXO in a subsequent transaction.

[0097] In some embodiments, the completion of a transaction does not require a cancellation symbol, especially for transactions that do not require a high level of privacy. Using such a system, some information will be exposed during the transaction process (for example, Alice is the one who puts the UTXO into the tree. When Alice sends the UTXO to Bob, if the cancellation symbol is not used, then everyone will know that Bob has withdrawn the UTXO). When the sender provides a cancellation symbol, the public can only see that the smart contract records a new cancellation symbol, and a new UTXO is inserted into the confirmed UTXO SMT. But the public cannot know the recipient or the relationship between the recipient and the sender.

[0098] Figure 6 A flowchart showing an example transaction process using the proposed smart contract is shown.

[0099] Process 600 is an example transaction process, showing two possible outcomes: a successful transaction and a failed transaction.

[0100] In step 602, the sender obtains the recipient's public key from the recipient.

[0101] In step 604, the sender starts the fund transfer by consuming a certain number of input UTXOs to generate output UTXOs, and then inserts these output UTXOs as pending UTXOs into the pending UTXO SMT. The pending UTXOs are encrypted so that only the sender or the receiver can generate the nullifiers that map to the pending UTXOs to satisfy the ZKP.

[0102] In step 606, once the pending UTXOs are inserted into the pending UTXO SMT, the smart contract 102 publicly transmits a smart contract event OHPETPendingUTXOEvent, which includes the following information: the public key of the receiver, the public key of the sender, tokenValue, and noncePending. This information is encrypted twice, once using the sender's public key and once using the receiver's public key. Thus, both the receiver and the sender can decrypt the information using their own private keys. This ensures that the receiver or the sender (but no third party) can generate the nullifiers, extract the pending UTXOs from the pending UTXO SMT, and generate new confirmed UTXOs with the same tokenValue in the confirmed UTXO SMT.

[0103] In step 608, the receiver can use their private key to decrypt the OHPETPendingUTXOEvent message and obtain the public keys of the two participants, tokenValue, and noncePending. If the decryption is successful, the user can construct the nullifier according to the pending nullifier construction rules and then query the smart contract 102 to verify whether the nullifier has been used. If the nullifier has not been used, the user can extract the UTXOs into the confirmed UTXO SMT.

[0104] If the recipient extracts the pending UTXO from the pending UTXO SMT, the transaction is considered successful. At step 610a, the recipient uses its pending nullifier and ZKP to extract the pending UTXO from the pending UTXO SMT and generates a new confirmed UTXO with the same tokenValue in the confirmed UTXO SMT. At step 612a, the smart contract 102 publicly transmits a smart contract event OHPETConfirmedUTXOEvent, which contains the tokenValue and nonceConfirmed. This information is encrypted using the owner's public key. Any user can attempt to decrypt the encrypted tokenValue and nonceConfirmed from the OHPETConfirmedUTXOEvent. The user must be the owner of the relevant UTXO to successfully decrypt and can use the decrypted tokenValue and nonceConfirmed along with its private key to generate a confirmation nullifier to consume the UTXO. After using the nullifier, the smart contract 102 records it to prevent double-spending of the UTXO. If any pending UTXOs are prepared for the sender (as change), whether the change is extracted by the sender or not, it does not affect the completion of the transfer transaction.

[0105] If the recipient is unable to extract the pending UTXO from the pending UTXO SMT for some reason, the sender can choose to extract it as its own asset into the confirmed UTXO SMT. If the sender extracts the pending UTXO from the pending UTXO SMT, the transaction is considered failed, but the UTXOs are not lost as they can still be extracted. At step 610b, the sender uses its pending nullifier and ZKP to extract the pending UTXO from the pending UTXO SMT and generates a new confirmed UTXO with the same tokenValue in the confirmed UTXO SMT. At step 612b, the smart contract 102 publicly transmits a smart contract event OHPETConfirmedUTXOEvent, which contains the tokenValue and nonceConfirmed. This information is encrypted using the owner's public key. Any user can attempt to decrypt the encrypted tokenValue and nonceConfirmed from the OHPETConfirmedUTXOEvent. The user must be the owner of the relevant UTXO to successfully decrypt and can use the decrypted tokenValue and nonceConfirmed along with its private key to generate a confirmation nullifier to consume the UTXO. After using the nullifier, the smart contract 102 records it to prevent double-spending of the UTXO.

[0106] All OHPETPendingUTXOEvent and OHPETConfirmedUTXOEvent are stored on the event bus of the smart contract without using temporary network communication methods. Therefore, if the recipient does not receive the transmission at that time, the transmission event will not be lost. When the pending UTXO is recycled / extracted, the event bus updates another event to indicate that the pending UTXO has been recycled or extracted. Therefore, the recipient needs to read and check all events to calculate the balance in the SMT.

[0107] In some embodiments, the recipient can query the event bus on the smart contract to check if there are any UTXOs allocated to them in the pending UTXO SMT, which indicates that someone has sent them funds that they need to extract from the smart contract.

[0108] In some embodiments, after the transaction is initiated, the sender can set a timer (e.g., 24 hours) to automatically revoke the transaction. If the recipient fails to extract the pending UTXO, the sender can revoke the transaction when the timer expires. If the recipient has successfully extracted the pending UTXO into the confirmed UTXO SMT, the revocation function call will fail because the cancellation symbols generated by the sender and the recipient will be the same. This timer mechanism does not affect the implementation of the complete functionality of the proposed process of the present invention.

[0109] In some embodiments, multiple parties can consume the UTXOs of the same sender / recipient account. An example implementation of this embodiment is to let the participants in the transaction create a escrow wallet. Through access control, multiple parties can access this escrow wallet simultaneously, and the information of the operator can be recorded. This part may be combined with Web2 solutions rather than pure Web3 solutions.

[0110] Figure 7 A flowchart showing a deposit / minting process 700 of an example private transaction using the proposed smart contract is presented.

[0111] In step 702, the sender / user deposits a certain amount of ETH or other tokens into the smart contract 102.

[0112] In step 704, the smart contract 102 mints tokens by inserting the UTXO into the confirmed UTXO SMT.

[0113] Figure 8 A flowchart showing a transfer process 800 of an example private transaction using the proposed smart contract is presented.

[0114] In step 802, the sender and the recipient obtain each other's public keys.

[0115] In step 804, the sender initiates a fund transfer by consuming a certain number of input UTXOs to generate some output UTXOs. The pending UTXOs are encrypted so that only the sender or the receiver can generate the nullifiers that map to the pending UTXOs to satisfy the ZKP.

[0116] In step 806, the smart contract 102 uses ZKP and the Circom circuit to verify the transfer. The ZKP and the Circom circuit must prove that: the confirmed input UTXOs exist in the confirmed UTXO SMT; the confirmed nullifiers match the confirmed UTXOs; the confirmed nullifiers have not been recorded and do not exist in the smart contract 102; the output pending UTXOs do not exist in the pending UTXO SMT; the corresponding token values of the input and output UTXOs are equal and legal, and the ECC key pairs match. Once the ZKP is satisfied, the smart contract 102 then records the confirmed nullifiers and inserts the output pending UTXOs into the pending UTXO SMT.

[0117] In step 808, once the pending UTXOs are inserted into the pending UTXO SMT, the smart contract 102 publicly transmits a smart contract event OHPETPendingUTXOEvent, which includes the following information: the public key of the receiver, the public key of the sender, tokenValue, and noncePending. This information is encrypted twice, once using the sender's public key and once using the receiver's public key. Therefore, both the receiver and the sender can decrypt the information using their own private keys. This ensures that the receiver or the sender (but no third party) can generate the nullifiers, extract the pending UTXOs from the pending UTXO SMT, and generate new confirmed UTXOs with the same tokenValue in the confirmed UTXO SMT.

[0118] In step 810, the receiver can use their respective private keys to decrypt the OHPETPendingUTXOEvent message and obtain the public keys of the two participants, tokenValue, and noncePending. If the decryption is successful, the user can construct the nullifiers according to the pending nullifier construction rules and then query the smart contract 102 to verify whether the nullifiers have been used. If the nullifiers have not been used, the user can extract the UTXOs into the confirmed UTXO SMT.

[0119] Each transfer transaction has at most two output UTXOs, where only one can be designated to the recipient, and the other UTXO (if it exists) must be designated to the sender as change. This design ensures data synchronization and avoids the situation where some pending UTXOs are withdrawn while others are not in the case of multiple recipients receiving funds. Since at most one UTXO can be sent to the recipient in a single transaction, the transfer transaction is considered complete when two situations occur: The first situation is that the recipient withdraws the output pending UTXO into the confirmed UTXO SMT, and the transaction is considered successful; the second situation is that the recipient fails to withdraw successfully, and the sender withdraws the output pending UTXO into the confirmed UTXO SMT, and the transaction is considered failed / voided. If any of the output pending UTXOs are prepared for the sender (as change), whether they are withdrawn by the sender or not will not affect the completion of the transfer transaction.

[0120] The embodiments described in this document guarantee the non-repudiation of the sender. When initiating a transfer, the sender can set an expiration time and lock the funds in the smart contract 102. The sender can define a condition in the pending UTXO SMT: only when the recipient provides the correct hash value within the specified time can the funds be transferred to the recipient's e-wallet. If the recipient fails to provide the correct information within the specified time, the funds will be returned to the sender. Through this mechanism, the sender cannot falsely claim that they did not initiate the transfer.

[0121] The embodiments described in this document ensure the non-repudiation of the recipient. By scanning the publicly available event information on the blockchain, the recipient will receive a notification indicating that there is a pending transfer in the pending UTXO SMT. The recipient can use their private key to decrypt and withdraw the pending UTXO from the pending UTXO SMT into the confirmed UTXO SMT. If the recipient claims that they did not receive the funds, the hash in the confirmed UTXO SMT will prove that their claim is false. Once the recipient unlocks and receives the funds, this operation will be recorded and cannot be denied. If the recipient fails to fully recover their UTXOs from the pending UTXO SMT for various reasons, the senders of these missed UTXOs can choose to withdraw them into the confirmed UTXO SMT at any time.

[0122] In some embodiments, the decentralized application running the smart contract 102 can automatically send a notification to the recipient informing them of a pending transfer. After receiving the notification, the recipient must perform a confirmation signature operation to record the recipient's actions to ensure that they cannot deny later that they have received and confirmed the transfer. If the recipient fails to confirm within the specified time, the transfer will fail and the funds will be returned to the sender. All steps of this process are recorded for auditing and tracking.

[0123] In case of a dispute (e.g., the sender claims a transfer has been made, but the receiver denies receiving it), verification and arbitration can be carried out based on the transfer status recorded on the blockchain, the execution status in the UXTO SMT, and the digital signatures of both parties. These immutable records provide strong evidence for a third party or arbitration institution to ensure a fair resolution of any dispute.

[0124] Figure 9 A flowchart showing an extraction process 900 of an example private transaction using the proposed smart contract is presented.

[0125] In step 902, the owner initiates the extraction of a pending UTXO from the pending UTXO SMT to the confirmed UTXO SMT. The owner can be either the sender or the receiver, as they can both generate the same pending nullifier.

[0126] In step 904, the smart contract 102 verifies the extraction using ZKP and the Circom circuit. The ZKP and the Circom circuit must prove that: the input pending UTXO exists in the pending UTXO SMT; the pending nullifier matches the pending UTXO; the pending nullifier has not been recorded and does not exist in the smart contract 102; the output confirmed UTXO does not exist in the confirmed UTXO SMT; and the corresponding token values of the input and output UTXOs are equal and compliant. Once the ZKP is satisfied, the smart contract 102 records the pending nullifier and inserts the output confirmed UTXO into the confirmed UTXO SMT.

[0127] In step 906, once the confirmed UTXO is inserted into the confirmed UTXO SMT, the smart contract 102 publicly transmits a smart contract event OHPETConfirmedUTXOEvent, which contains the tokenValue and the nonceConfirmed. This information is encrypted using the owner's public key. Any user can attempt to decrypt the encrypted tokenValue and nonceConfirmed from the OHPETConfirmedUTXOEvent. The user must be the owner of the relevant UTXO to decrypt successfully and can use the decrypted tokenValue and nonceConfirmed along with its private key to generate a confirmed nullifier to consume the UTXO.

[0128] In step 908, the owner can use its own private key to decrypt the OHPETConfirmedUTXOEvent message and obtain the tokenValue and the nonceConfirmed.

[0129] Figure 10Present a flowchart of the withdrawal / destruction process of an example private transaction using the proposed smart contract.

[0130] In step 1002, the user initiates a fund withdrawal and confirms the destruction of the UTXO.

[0131] In step 1004, the smart contract 102 verifies the withdrawal using ZKP. The ZKP must prove that: the confirmed UTXO exists in the confirmed UTXO SMT; the confirmation cancellation symbol provided by the user matches the confirmed UTXO; the confirmed cancellation symbol has not been recorded and does not exist in the smart contract 102. Once the ZKP is satisfied, the smart contract 102 records the confirmed cancellation symbol and destroys the confirmed UTXO tokens.

[0132] In step 1006, the smart contract 102 transfers ETH or other token funds to the digital wallet specified by the user.

[0133] Figure 11 Present a flowchart of the user wallet recovery process 1100 of an example private transaction using the proposed smart contract. The process 1100 may be necessary when the user needs to recover / restore their digital wallet (e.g., after reinstalling the client).

[0134] In step 1102, the user reads all OHPETPendingUTXOEvent from the smart contract data object 102.

[0135] In step 1104, since the content of the OHPETPendingUTXOEvent is encrypted using the public keys of the sender and the receiver, the user can try to decrypt the content of the OHPETPendingUTXOEvent using their private key. The user must be the sender or the receiver of the OHPETPendingUTXOEvent to successfully unlock it. Therefore, the user can obtain the following information about the pending UTXO: the public key of the sender, the public key of the receiver, tokenValue, and noncePending. The user can save this obtained information for use when they need to consume / use this pending UTXO.

[0136] In step 1106, the user checks and reads all OHPETConfirmedUTXOEvent from the smart contract data object 102.

[0137] In step 1108, since the content of the OHPETConfirmedUTXOEvent is encrypted using the owner's public key, the user can attempt to decrypt the content of the OHPETConfirmedUTXOEvent using their own private key. The user must be the owner of the OHPETConfirmedUTXOEvent to successfully decrypt it. Thus, the user can obtain the following information about the confirmed UTXO: tokenValue and nonceConfirmed. The user can save this information for use when consuming the confirmed UTXO as needed.

[0138] Figure 12 is a schematic structural diagram of a computer device according to an aspect of the present invention. As Figure 12 shown, the computing device may include: at least one processor ( Figure 12 only one is shown in the figure), a memory, a computer-readable storage medium, and a computer program stored on the computer-readable storage medium in the memory and executable on at least one processor. When the processor executes the computer program, it implements various steps in the above-described embodiments of the method for blockchain distributed ledger transactions using the UTXO Merkle tree data structure. Those skilled in the art can understand that Figure 12 is merely an example of a computer device and does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include a network interface, a display screen, and an input device, etc.

[0139] The embodiments described herein have a gas fee cost similar to other similar solutions. For gas fee payment, different methods can be adopted to handle it. These methods may include paying privacy tokens to a third-party minting service, or in other embodiments, the smart contract can be coupled to a fee repository where the trading parties have paid.

[0140] Use cases for private transactions include transactions related to high-value items (such as houses, cars, etc.), where the parties are willing to bear the additional miner fee cost to obfuscate the transaction in order to prevent third parties from learning the transaction details, but still allow auditors to retain the ability to decrypt as required.

[0141] Further variants may include examples of blockchains or digital decentralized currencies, where, for example, some transactions can be designated as semi-private transactions between parties. In other variants, it can be implemented by a digital decentralized currency, where each transaction requires encryption as described herein. Another variant can be used for cross-chain implementation, where the smart contract also acts as an intermediary between different blockchains or different types of objects minted by different institutions existing on the blockchain.

[0142] Those skilled in the art can understand that the above descriptions and examples are for illustrative purposes only. Different technologies and processes can be used to represent information and signals. For example, the data, instructions, commands, information, signals, bits, symbols, and chips mentioned in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or combinations thereof.

[0143] The functional modules and units described in the present invention may include processors, electronic devices, hardware devices, electronic components, logic circuits, memories, software codes, firmware codes, etc., or any combination thereof. In addition, the technical features discussed herein can be implemented by dedicated processor circuits or by executable instructions, and / or combinations thereof.

[0144] As understood by those of ordinary skill in the art, various terms are used only to describe specific embodiments and are not intended to limit the embodiments. For example, the ordinal numbers (such as "first", "second", "third", etc.) used herein are used to modify an element, such as a structure, component, operation, etc. It does not itself indicate the priority or order of the element relative to another element, but is only used to distinguish it from another element with the same name (without these ordinal numbers, elements with the same name cannot be distinguished). The term "coupled" is defined as connected, although not necessarily directly connected, nor necessarily mechanically connected; the two items "coupled" may be integral. "One" is defined as one or more, unless the present disclosure clearly requires otherwise. The term "substantially" means that in most cases it conforms to the specified standard, but not exactly - it covers the specified standard; for example, "substantially 90 degrees" includes 90 degrees, and "substantially parallel" includes parallel. In any disclosed embodiment, the term "substantially" can be replaced by "within a certain percentage", where the percentage includes 0.1%, 1%, 5%, and 10%. The term "almost" can be replaced by "within ten percent". In any disclosed embodiment, "and / or" means inclusive or. For example, A, B, and / or C includes: A alone, B alone, C alone, the combination of A and B, the combination of A and C, the combination of B and C, or the combination of A, B, and C. In other words, the function of "and / or" is as an "or" that includes but is not limited to. In addition, "A, B, C, or a combination thereof" or "A, B, C, or any combination" includes: A alone, B alone, C alone, the combination of A and B, the combination of A and C, the combination of B and C, or the combination of A, B, and C.

[0145] It should be noted that, in this document, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article or method comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, apparatus, article or method. Without further limitation, an element defined by the statement "comprising a..." does not exclude the presence of additional identical elements in the process, apparatus, article or method comprising such element. The implementation of any apparatus, system and method may consist of, or consist essentially of, the described steps, elements and / or features, rather than merely comprising / including / having these steps, elements and / or features.

[0146] In addition, a device or system configured in a certain way is at least configured in that way, but it may also be configured in other ways not specifically described. Certain aspects of one example may be applied to other examples, even if not described or illustrated, unless the nature of the present disclosure or a particular example expressly prohibits it.

[0147] Those skilled in the art will further understand that the various illustrative logical blocks, modules, circuits and algorithmic steps associated with the present disclosure may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the above-described illustrative components, blocks, modules, circuits and steps are generally described in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each particular application, but such implementation decisions should not be construed as causing the technical solution to depart from the scope of this document. Those skilled in the art will also readily recognize that the order or combination of the components, methods or interactions described herein are merely examples, and the components, methods or interactions of the various aspects herein may be combined or performed in a manner different from that illustrated and described herein.

[0148] The various illustrative logical blocks, modules and circuits referred to herein may be implemented or performed by a processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or combinations of these designs to implement the functions described in the present disclosure. The processor may be a microprocessor, but as an alternative, the processor may also be another form of processor, controller, microcontroller or state machine. The processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0149] The steps of the methods or algorithms described in this invention may be embodied directly in hardware, or in software modules executed by a processor, or in a combination of both. The software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disk, removable disk, CD-ROM. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be an integral part of the processor. The processor and the storage medium may be integrated in an application specific integrated circuit (ASIC). The ASIC may be located in a user terminal. Or, the processor and the storage medium may be located in the user terminal as separate components.

[0150] The functions described in one or more exemplary designs may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes all media that facilitate the transfer of a computer program from one location to another, including both computer storage media and communication media. Computer-readable storage media may be any media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and that can be accessed by a computer or a processor. In addition, a connection may also be properly termed a computer-readable medium. For example, if the software is transmitted via a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL), then the coaxial cable, fiber optic cable, twisted pair, or DSL is also included in the definition of the medium. As used herein, "disk" and "optical disk" include CD, laser disk, optical disk, digital versatile disk (DVD), hard disk, solid state disk, and Blu-ray disk, where disks typically reproduce data magnetically, while optical disks reproduce data optically with a laser. The above combinations should also be included within the scope of computer-readable media.

[0151] The foregoing specification and examples provide a complete description of the structure and use of illustrative embodiments. Although some of the above examples have been described in a particular level of detail, or with reference to one or more individual examples, those skilled in the art can make many modifications to the disclosed embodiments without departing from the scope of the present invention. Thus, the various illustrative embodiments of the methods and systems are not limited to the specific forms disclosed. Instead, they include all modifications and alternatives that fall within the scope of the claims, and other examples may incorporate some or all of the features shown in the examples. For example, some elements may be omitted, or they may be combined into a single unit structure, and / or the connecting parts may be replaced. In addition, where appropriate, certain aspects of any of the examples described above may be combined with certain aspects of any of the other examples described, to form further examples with similar or different properties and / or functions, and to solve the same or different problems. Similarly, it should be understood that the benefits and advantages described above may be associated with one embodiment, or with several embodiments.

[0152] Although the various aspects and advantages of the present disclosure have been described in detail, it should be understood that changes, substitutions, and modifications may be made herein without departing from the spirit of the disclosure as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the specific embodiments of the processes, machines, manufactures, compositions of matter, means, methods, and steps described in the specification. As will be readily understood by those of ordinary skill in the art from the present disclosure, processes, machines, manufactures, compositions of matter, means, methods, or steps that are presently existing or that may be developed in the future, which perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein, may be utilized in accordance with the present disclosure. Accordingly, the appended claims are intended to cover such processes, machines, manufactures, compositions of matter, means, methods, or steps within their scope.

Claims

1. A method for processing a private blockchain-based distributed ledger transaction, the method using two UTXO Merkle tree data structures, the method comprising: Persist a smart contract data object, wherein the smart contract data object includes a pending UTXO Merkle tree data structure and a confirmed UTXO Merkle tree data structure; Receive multiple tokens sent from a sender blockchain wallet to a receiver blockchain wallet; Generating a first batch of confirmed UTXOs corresponding to a plurality of tokens and inserting them into the confirmed UTXO Merkle tree data structure; Receiving a transfer request from the sender blockchain wallet, and transferring multiple tokens to the receiver blockchain wallet; Verify the transfer request and the sender blockchain wallet using the first confirmed deregistration token; Upon successful verification of the transfer request, generating a plurality of pending UTXOs and inserting them into the pending UTXO Merkle tree data structure, recording the first confirmed cancellation symbol in the smart contract data object, and destroying the first confirmed UTXOs from the confirmed UTXO Merkle tree data structure, wherein the plurality of pending UTXOs are encrypted using public keys associated with the sender blockchain wallet and the receiver blockchain wallet; receiving a withdrawal request from an owner to withdraw a plurality of the pending UTXOs, wherein the owner is one of the sender blockchain wallet and the receiver blockchain wallet; authenticating the withdrawal request and the owner using a pending deregistration token; After successfully verifying the withdrawal request, extracting a plurality of the pending UTXOs from the pending UTXO Merkle tree data structure, generating a second batch of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, and recording the pending cancellation symbol in the smart contract data object; receiving a withdrawal request from the owner to withdraw a plurality of tokens; Verifying said withdrawal request using a second confirmed deregistration token; Upon successful verification of the withdrawal request, a plurality of the tokens are transferred to the owner, the second confirmed cancellation symbol is recorded in the smart contract data object, and the second batch of confirmed UTXOs are destroyed from the confirmed UTXO Merkle tree data structure.

2. The method according to claim 1, characterized in that The pending cancellation token is generated using a hash function of a pending random number, an elliptic curve Diffie-Hellman (ECDH) shared secret, and the values ​​of multiple tokens.

3. The method according to claim 1, characterized in that The first and second confirmed deregistrants are generated using a hash function of the confirmed random number, the owner's private key, and the value of multiple tokens.

4. The method according to claim 1, characterized in that The verification transfer request includes using zero-knowledge proof and Circom circuit to prove that the first batch of confirmed UTXO exists in the confirmed UTXO Merkle tree data structure, prove that the first confirmed cancellation symbol is mapped to the first batch of confirmed UTXO, prove that the first confirmed cancellation symbol is not recorded in the smart contract data object, prove that the pending UTXO does not exist in the pending UTXO Merkle tree data structure, and that the first batch of confirmed UTXO and the pending UTXO correspond to the same token value.

5. The method according to claim 1, characterized in that The verification extraction request includes using zero-knowledge proof and Circom circuit to prove that the pending UTXO exists in the pending UTXO Merkle tree data structure, proving that the pending cancellation symbol is mapped to multiple pending UTXOs, proving that the pending cancellation symbol is not recorded in the smart contract data object, proving that the second batch of confirmed UTXOs does not exist in the confirmed UTXO Merkle tree data structure, and that multiple pending UTXOs and the second batch of confirmed UTXOs correspond to the same token value.

6. The method according to claim 1, characterized in that The verification withdrawal request includes using zero-knowledge proof and Circom circuit to prove that the second batch of confirmed UTXO exists in the confirmed UTXO Merkle tree data structure, proving that the second confirmed cancellation symbol is mapped to the second batch of confirmed UTXO, and that the second confirmed cancellation symbol is not recorded in the smart contract data object.

7. The method according to claim 1, characterized in that The smart contract data object further includes an event bus, and the recipient blockchain wallet can query the event bus to check the pending UTXO assigned to the recipient blockchain wallet in the pending UTXO Merkle tree data structure.

8. The calculation method according to claim 7, characterized in that: Further including: Set an expiration time limit; as well as When the expiration time limit expires, the plurality of pending UTXOs are automatically extracted from the pending UTXO Merkle tree data structure and the plurality of tokens are returned to the sender blockchain wallet, wherein the plurality of pending UTXOs have not been extracted within the expiration time limit.

9. The calculation method according to claim 1, characterized in that: The receiving blockchain wallet is a custodial wallet that can be accessed by multiple entities to withdraw and consume multiple pending UTXOs in the pending UTXO Merkle tree data structure and the second batch of confirmed UTXOs in the confirmed UTXO Merkle tree data structure, wherein the multiple entities can access the custodial wallet simultaneously through access control.

10. The calculation method according to claim 4, characterized in that: After successfully verifying the transfer request, the smart contract data object generates a UTXO designated for the sender's blockchain wallet as change.

11. A system for processing transactions based on a private blockchain distributed ledger, comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 1 to 10. 12 . A non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform the method of claim 1 .

Images