GB2623304A

GB2623304A - Economical zero knowledge execution environment

Info

Publication number: GB2623304A
Application number: GB2214799.5A
Authority: GB
Inventors: Sertkaya Isa; Kalkar Oznur; Faltyn Konrad
Original assignee: Silentdao Found
Current assignee: Silentdao Found
Priority date: 2022-10-07
Filing date: 2022-10-07
Publication date: 2024-04-17
Also published as: GB202214799D0

Abstract

A method and system to transfer assets using a Smart Contract. A private environment (PE) Front End receives from a user a transaction request 802A to transfer assets between a first user account and an application on a blockchain, e.g. a decentralised finance (DeFi) platform. The transaction request comprises a transaction amount and an application identifier. The Front End derives a second user account of the user 812A based upon the user’s smart contract-based platform address and the application identifier. This may be by generating private / public keys and a second address. The Front End receives from the Smart Contract, i.e. PE Back End, an anonymity set which comprises an account state of the first user account and an account state of at least one other account of a user that is not involved in the transaction. The Front End generates a proof 826A based upon the anonymity set. The Smart Contract verifies the proof 838A and if verification is successful the assets are transferred between the first and second accounts, 840A. If the account state comprises an encrypted balance, the state may be computed using additive homomorphism of the ElGamal scheme. The proof may be a many-out-of-many proof.

Description

ECONOMICAL ZERO KNOWLEDGE EXECUTION ENVIRONMENT

[1] This specification relates to methods and systems for a new way of applying zero knowledge proofs in order to enable private access to applications on a public blockchain.

BACKGROUND

[2] Web3, also known as Web 3.0 or the decentralized web, promises to provide distributed internet services built on peer-to-peer blockchains removing the requirement for Trusted Third Parties (TTP). A core value proposition offered by any Web3 application, is that a user has full control of their own data.

[3] Smart contracts are programs stored on a blockchain that run when predetermined conditions are met, providing users a method to run secure verifiable computation on a public blockchain. Smart contract systems rely on a form of state-machine replication in which nodes involved in maintaining the smart contract keep a local copy of its state and alter this copy with every request in a sequence of requests. Intuitively, since multiple copies of the state exist, a fault on one node is noticeable as a difference in the state or difference in output from the other nodes. A seemingly inherent limitation of the decentralized computation paradigm is the fact that protocol logic deployed as a smart contract has to be completely non-private. Every node in the blockchain processing a transaction is provided details of every operation, including which program is to be executed, the data that is being passed and who is the caller. Using these details, information relating to the user can be revealed to anyone with access to the public blockchain, which causes major privacy concerns.

[4] Several existing approaches aim to solve these privacy issues on public blockchains and to enable private smart contract computation for users. Existing approaches to private state computation include: on-chain Homomorphism; trust based computation; offline computation, on-chain verification; and global shared state, private local state.

[5] On-chain Homomorphism (On-chain HE) allows a user to provide encrypted inputs for a desired computation, and a zero knowledge proof (ZKP) verifying the conditions on the inputs which get verified and computed on-chain. A ZKP is a method by which one party (known as the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information. Zether is one of the first applications to use on-chain HE to provide transactions in which the input, output alongside, sender and receiver may be hidden from the blockchain ledger; however there is an extensive computational cost for such on-chain computation and verification of the ZKPs.

[6] Trust based computation allows users to shift their entire computation to a trusted hardware that does the computation on the behalf of the users off-chain, with a drawback that any solution implemented on one hardware is incompatible to be run on other hardware.

[7] In Offline Computation, on-chain verification users process computations applied offline on their private plaintext inputs to produce plaintext outputs. The users provide the I/O in an encrypted form alongside a ZKP attesting to the validity of the computation performed, which gets saved and verified on-chain. This framework allows a user to hide how her assets, however it requires a middleman to help parties coordinate and share information about their transactions offline.

[8] The global shared state, private local state design provides an interface that allows users to call operations on public functions anonymously. Aztec connect is one example of such a system, and allows for cheap costs for processing a decentralized finance (DeFi) transaction, but requires the creation of multiple subspaces in order to interact with an application on a blockchain, for example a DeFi protocol, and this impacts value flow and composability. In addition each bridge that is connected to the smart contract shares the same risk unfairly with all the users using the subspace.

[9] Thus, there is a need for improved methods of providing private access to public blockchains.

SUMMARY

[10] According to a first aspect of the invention, a computer implemented method is provided, comprising: receiving, at a computational environment front end, from a primary user, a request for a transaction to transfer assets between a first user account of the primary user and an application on a blockchain, the request to transfer assets comprising a transaction amount and an application identifier of the application. The method further comprises obtaining, by the front end, from a smart contract, an anonymity set comprising an account state of a first user account and at least one other account state, wherein the first user account is derived based on a smart contract-based platform address of the primary user and wherein each of the at least one other account states correspond to a user account of a user not involved in the transaction, deriving, by the front end, a second user account of the primary user, wherein the second user account is derived based on the primary users smart contract-based platform address and the application identifier; computing, by the front end, a state for the first user account, wherein the state for the first user account is computed based at least in part on a first user account state and the transaction amount. The method further comprises the steps of generating, by the front end, a proof, the proof based on the anonymity set; verifying, by the smart contract, the proof; initiating, by the smart contract, as a result of verifying the proof, the transfer of assets between the first and second primary user accounts, and updating, by the smart contract an account state for each account in the anonymity set.

[11] The invention allows for a user of a computational environment -a multi-asset shielded pool -to be able to perform the steps of the method claim to perform transactions securely, while maintaining the user's anonymity since the proofs required are based on the anonymity set derived from the user account and other users not part of the transaction. The result of the method is the transfer of assets and the updated account state which reflects the new account state for the accounts in the anonymity set.

[12] Optionally, deriving a first account comprises generating a first private key (sk), first public key (pk) and a first address and wherein deriving a second account comprises generating a second private key, second public key and second address. Optionally, the derived account state of the first user account corresponds to an account balance; the smart contract comprises a set of rules to operate a multi-asset shielded pool; and the account balance corresponding to the first user account is held within the smart contract governing the multi-asset shielded pool.

[13] Optionally, the request to transfer assets further comprises an asset identifier of a particular asset type and wherein the account state of the first user account further corresponds to the particular asset type.

[14] Optionally, the proof further comprises: proof that a know your customer -(KYC)/anti-money laundering (AML) compliance encryption condition is satisfied.

[15] Optionally, the proof further comprises: proof that the transaction amount > 0. This step ensures that the smart contract is operating on a valid transaction and the computation will not fail.

[16] Optionally, the computed state for the first user account is an updated account state for the first user account.

[17] Optionally, the method further comprises computing, by the user interface/front end, an updated account state for each account state in the anonymity set.

[18] Optionally, the multi-asset shielded pool comprises one or more registries, wherein each registry corresponds to a specific asset type and comprises one or more user account states corresponding to specific asset type.

[19] The anonymity set may comprise 7 other user accounts. Alternatively the anonymity set may comprise 8, 9 10 or any other number of accounts. The anonymity set may be determined based on the asset identifier.

[20] Obtaining the account state may comprise obtaining an encrypted account balance.

[21] The state computed by the front end may be computed using additive homomorphism. 3 [22] For each asset, T, the first user account is stored as a tuple: (Pk To (G1, G2)TA) where pick is the Elgamal public key, pk for asset T corresponding to the private key, ski for a given user A and (C1,C2)TA is the Elgamal ciphertext of the user account balance for asset T. [23] The state computed by the front end may be done using additive homomorphism of Elgamal scheme, and the proof calculated may comprise a many-out-of-many proof. Where a many-out-of-many proof is used, the anonymity set may comprise "I" accounts and the many-out-of-many proof may comprise the steps of: obtaining, an index user account A in anonymity set (inAccSet) accr); computing, a new balance for the account using additive homomorphism of Elgamal scheme according to, (C1, C2 -T aG); randomizing the states of all the accounts to form set anonymity set (outAccSet), (E1, E2)T <-(El rG, rpki), where for each i E....,1], (E1,E)T is the previous state; and providing inAccSet, outAccSet, knowledge of the user index in the anonymity set and random r.

[24] The transfer of assets may be from the first user account to the second user account, and optionally the proof further comprises a step of confirming that the first account balance is greater than or equal to the transaction amount. This part of the method relates to transferring assets towards the stealth or shielded address, explained further below, in the context of moving to an on-chain application.

[25] The transfer of assets may be from the second user account to the first user account, and the method may further comprise obtaining a balance corresponding to the second user account and confirming the balance is greater than the transaction amount.

[26] The anonymity set may comprise each node of a Merkle tree, wherein each node corresponds an amount of an asset provided to a user of the private environment to be held in the smart contract of the private environment. Optionally,computing a state for the first user account comprises computing one or more of a note and a nullifier and wherein updating the account state for each account in the anonymity set comprises one or more of computing a new root node hash corresponding to the computation and adding a nullifier to a global nullifier set. Optionally, this method further comprises computing a commitment for the note, based on the transaction amount, a public key of the first user account and optionally an asset identifier. Computing a nullifier may optionally be based on a node corresponding to the transaction.

[27] A computer system is provided, configured to perform a method comprising: receiving, at a computational environment front end, from a primary user, a request for a transaction to transfer assets between a first user account of the primary user and an application on a blockchain, the request to transfer assets comprising a transaction amount and an application identifier of the application. The method further comprises obtaining, by the front end, from a smart contract, an anonymity set comprising an account state of a first user account and at least one other account state, wherein the first user account is derived based on a smart contract-based platform address of the primary user and wherein each of the at least one other account states correspond to a user account of a user not involved in the transaction, deriving, by the front end, a second user account of the primary user, wherein the second user account is derived based on the primary users smart contract-based platform address and the application identifier; computing, by the front end, a state for the first user account, wherein the state for the first user account is computed based at least in part on a first user account state and the transaction amount. The method further comprises the steps of generating, by the front end, a proof, the proof based on the anonymity set; verifying, by the smart contract, the proof; initiating, by the smart contract, as a result of verifying the proof, the transfer of assets between the first and second primary user accounts, and updating, by the smart contract an account state for each account in the anonymity set.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example of a system 100 for transferring assets in accordance with various embodiments.

FIG. 2 is a flow diagram of a method 200 for Private Environment Account Key Generation in accordance with various embodiments.

FIG. 3 is a flow diagram of a method 300 for Stealth Account Key Generation for interacting with an on-chain application in accordance with various embodiments.

FIG. 4A is a flow diagram of a method 400A for depositing an asset into the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 4B is a flow diagram of a method 400B for depositing an asset into the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 5A is a flow diagram of a method 500A for withdrawing an asset from the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 5B is a flow diagram of a method 500B for withdrawing an asset from the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 6A is a flow diagram of a method 600A for transferring an asset within the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 6B is a flow diagram of a method 600B for transferring an asset within the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 7 is diagram of method 700 for transferring assets between a first user account of the primary user and an application on a blockchain.

FIG. 8A is a flow diagram of a method 800A for depositing an asset from the Private Environment Multi-asset shielded pool to an application on a blockchain in accordance with various embodiments.

FIG. 8B is a flow diagram of a method 800B for depositing an asset from the Private Environment Multi-asset shielded pool to an application on a blockchain in accordance with various embodiments.

FIG. 9A is a flow diagram of a method 900A for withdrawing an asset from an application on a blockchain to the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 9B is a flow diagram of a method 900B for withdrawing an asset from an application on a blockchain to the Private Environment Multi-Asset Shielded Pool in accordance with various embodiments.

FIG. 10 is an example of a hardware implementation on which the present methods might be performed.

DETAILED DESCRIPTION OF THE DRAWINGS

[28] FIG.1 is a diagram of an example of a system 100 for transferring assets in accordance with various embodiments. System 100 comprises a private environment 104,106 which provides, and allows a user of user device 102 access to, a multi-asset-shielded pool. The user device 120 may be a personal computer (PC), a tablet computer, a Personal Digital Assistant (PDA), a mobile phone or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine and further comprising a user interface, wherein displaying showing or presenting information to the user device be taken to mean that the information is provided on a display of the user device, presented audibly through a speaker or by any appropriate method.

[29] In addition to providing access to the multi-asset shielded pool, system 100 further allows a user of user device 102 to create access keys through which they make computation calls to applications on the blockchain. System 100 provides a user access to post generic computation to a blockchain anonymously by first transferring assets into the private environment smart contract using a ZKP and then using a stealth address to interact with an on-chain applications anonymously, without creating any ZKPs at this stage.l. In addition to reducing costs by removing the requirement for posting ZKPs, system 100 helps preserve anonymity and removes the requirement for sharing risk with other users when interacting with an application on a blockchain.

[30] The private environment protocol is a computational environment that comprises a front end 104 and a back end 106. The front end 104 controls a user interface (UI) and the back end 106 is a smart contract (SC), referred to herein as the private environment smart contract 106. The terms back end and smart contract may be used interchangeably in the description to refer to 106 of the private environment.

[31] A user of user device 102a can connect to the private environment front end 104 via a user interface and generate a private environment user account via the user interface in order to access the multiasset-shielded pool governed by the private environment smart contract 106. The user interface may be a user interface of an application or browser to which the user of user device 102 has connected a smart wallet. In some embodiments, the user interface is a user interface of an application wherein the application carries additional functionality as a smart wallet, in which case the user of user device 102a may connect to the private environment front end 104 by opening or accessing the application. For example, in some embodiments, a user of user device 102a can generate a private environment user account by the method described below with reference to FIG.2.

[32] A user of user device 102a may deposit or withdraw assets from or into the multi-asset-shielded pool governed by the smart contract 106 of the private environment protocol by interacting with the front end 104 via the Ul using their private environment user account. For example, in some embodiments, a user of user device 102a can deposit assets according to the method described below with reference to FIG.4. For example, in some embodiments, a user of user device 102a can withdraw assets according to the method described below with reference to FIGS. [33] A user of the private environment protocol 104,106 may transfer assets to other users (for example a user of user device 102b) of the private environment protocol using their private environment user account. For example, in some embodiments, a user of user device 102a can transfer assets according to the method described below with reference to FIG.6.

[34] A user of user device 102a may interact with any number of on-chain applications 112a, 112b...112m via a corresponding stealth address 110a, 110b...110m. In some embodiments, system 100 may additionally include a relayer 108. A user of user device 102a can generate a "Stealth", or shielded user account for interacting with a specific on-chain application (the example used is a DeFi app, which is a program that runs on a blockchain network and allows users to trade digital assets) by the method described below with reference to FIG.3 and interact with the application on the blockchain according to the method described below with reference to FIG.7, FIG.8 and FIG. 9. Beneficially, the Stealth user account provides a shielded stealth address which preserves user anonymity and removes the requirement for bridge contracts and hence for sharing risk with other users interacting with an on-chain application. For example an on-chain application, also referred to herein as a blockchain application may be utilised by calling arbitrary encoded function calls embedded within the private environment transactions. In addition, the techniques described herein do not require ZKPs to be posted for verification by blockchain miners for securing and verifying the blockchain ledger transactions, thereby reducing the gross computational cost and consequently the financial cost to the user when interacting with on-chain applications.

[35] For example, in some embodiments, a user of user device 102a can transfer assets from the multi-asset-shielded pool governed by the smart contract 106 to an application on a blockchain 112a, 112b...112m according to the method described below with reference to FIG.8. For example, in some embodiments, a user of user device 102a can transfer assets from an application on a blockchain 112a, 112b...112m to the multi-asset-shielded pool governed by the smart contract 106 according to the method described below with reference to FIG.9.

[36] A user may connect to the private environment protocol by accessing the private environment Ul on a user device. In order for a user to participate in any transaction, withdraw or transfer the user must effectively log on' to the private environment by generating account keys.

[37] Figure 2 is a flow diagram of a method 200 for private environment Account Key generation, method may be performed by new or existing users wishing to interact with the multi-asset shielded pool in any way. For example, in some embodiments, method 200 is initiated by a new user wishing to deposit an asset in the Multi-Asset shielded pool. In some embodiments, method 200 is initiated by a user who already has digital assets in the Multi-Asset shielded pool and wishes to, for example, interact with an on-chain application. Although the operations of the method 200 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 200 may be used in any suitable setting to perform any suitable support operations. Operations are illustrated as occurring once, and occurring in a particular order in FIG. 2, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[38] In step, 202, a user of a user device 102 accesses the private environment user interface (private environment UI) and connects a smart wallet to the private environment front end 104 (private environment FE) via the private environment Ul. The smart wallet may be any digital wallet that allows users to store and manage any blockchain based cryptocurrency or asset. For example, in some embodiments, the smart wallet is a MetaMask wallet. It is, however, understood that any other appropriate smart wallet may be used, including, for example, a Coinbase Wallet, Trust Wallet, MyEtherWallet, ZenGo, SkaedWallet.io, Exodus, Ambire Wallet, MathWallet or WalletConnect. In some embodiments, the private environment user interface, may be the user interface of an application that also [39] At step 204, the private environment FE 104, sends a sign request to the smart wallet of the user of user device 102 and at step 206, the smart wallet notifies the user of user device 102 of the sign request. For example, in some embodiments, the sign request is a message predetermined by the private environment front end 104 that may be approved to create a signature. In such embodiments, the user approves the request, creating a signature on the message using their smart wallet. In some embodiments, the message may comprise additional data, for example transaction data, an asset type.

[40] At step 208, the user signs the request using the smart wallet and at step 210 the signed request is provided to the private environment FE 104.

[41] At step 212, the private environment FE 104 derives, based on the signed request, information indicative of the account state of the user. The way in which account data is associated with a user within the private environment differs in a first and a second embodiment.

[42] In a first embodiment, derived information indicative of the account state of the user may comprise a private environment private key (private environment sk), private environment public key (private environment pk) and one or more private environment Addresses that correspond to a smart contract based platform address of the user. The private environment account keys allow the user to interact with the assets the user holds in the multi-asset-shielded pool governed by the smart contract 106. The account state of the user may therefore be altered by altering a balance of the user.

[43] For example, in the first embodiment, the user's assets may be stored by asset type and encrypted. For example, each asset of the n asset types making up the in the multi-asset shielded pool is stored in a registry t, for that asset type such that sp t2, ...W. Each registry may then maintain the user account balance state for that specific asset such that t, (act', acc, acch) where I, is the number of accounts registered under the asset t,.

[44] The balance for each asset may be stored as an encrypted balance, for example the balance may be encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance of the first embodiment.

[45] For example, for a given user A, the balance belonging to the user of a particular asset, i is stored as a tuple: (131c.4, (C1, C2)f) Equation (1) [46] where picj4 is the Elgamal public key, pk for asset i corresponding to the private key, sk for a given user A and (C1,C2)i4 is the Elgamal ciphertext of the user account balance for asset I, C, rG and C2 bG + rX,i.e, r E Zq is a random scalar,X +-xG is the users public key pk, where xG is a Baby Jubjub curve point.

[47] In a second embodiment, a Merkle tree is used to represent assets of one or more users of the private environment by recording information about notes created in a transaction. For example, for every transaction provided to a given user to be held in the smart contract of the private environment, a note, associated with the user, and representing the transaction is created. When a user wishes to remove assets stored in the smart contract (spend assets in the smart contract), a nullifier is created and added to a nullifier set. The nullifier indicates that a given note has been spent in the the smart contract, and that the user no longer is able to spend the asset (i.e. it has been transferred away from the user. The information indicative of the account state of the user may comprise account keys for every asset provided to a given private environment user (for example, each asset deposited to or transferred to the user), wherein each instance of an asset being provided to the user is represented by a note on a node in a Merkle tree model, as described above.

[48] In either embodiment, a user may interact with on-chain applications, for example DeFi applications, using a stealth address to provide anonymity, 110 as an alternative to costly known methods (such as Aztec, described above) which use adapter/bridge smart contracts. In some embodiments, an on-chain application identifier may be used in order to provide the same Stealth Address 110 for every given interaction between a user and specific application protocol 112. For example, an on-chain application identifier of an on-chain application may be available on or offchain.

[49] FIG. 3 is a flow diagram of a method 300 for stealth account key generation for interacting with an application on the blockchain, such as a DeFi application, for both the first and second embodiments. The stealth user account keys provides a shielded stealth address which preserves user privacy and removes the requirement for bridge contracts and hence for sharing risk with other users. Although the operations of the method 300 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 300 may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once, and in a particular order in FIG. 3, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable). As per the private environment Account Key Generation method described above in relation to Fig. 2, stealth account key generation may be done using a smart wallet.

[50] At step 302, a user of a device accesses the private environment user interface (private environment UI) and connects, a smart wallet to the private environment front end (private environment FE), for example via the private environment Ul, and indicates that they would like to make an on-chain interaction. The user provides an indication of an on-chain application with which they would like to interact. For example a DeFi which may be identified by a DeFI identifier. As discussed above with reference to FIG.2, the smart wallet can be any appropriate smart wallet, for example, a MetaMask wallet.

[51] At step 304, the private environment FE, sends a sign request to the smart wallet of the user of user device 102 and at step 306, the smart wallet notifies the user of user device 102 of the sign request.

[52] For example, in some embodiments, the sign request is a message predetermined by the private environment FE 104 comprises an identifier of the on-chain application specified by the user, for example a DeFi ID. In such embodiments, the user signs the request by approving it which creates a signature on the message using generated by the smart wallet.

[53] At step 308, the user signs the request comprising the DeFi ID using the smart wallet, and at step 310 the signed request comprising the DeFi ID is provided by the smart wallet to the private environment FE 104.

[54] At step 312, the private environment FE derives, based on the signed message, a stealth private key (stealth sk), stealth public key (stealth pk) and stealth address that correspond to a smart contract based platform address of the user for the specific application on the blockchain corresponding to the DeFi ID.

[55] The user may use the stealth address to anonymously post computation on the blockchain, for example when interacting with on-chain applications.

[56] As well as interacting with on-chain applications, a user may interact with the private environment in a number of different ways, including, depositing a quantity of an asset into the Multi-asset shielded pool.

[57] FIG. 4A is a flow diagram of a method 400A for depositing an asset into the private environment Multi-asset shielded pool according to the first embodiment. Although the operations of the method 400A may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 400A may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once, and in a particular order in FIG. 4A, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable). As per the private environment account key generation method described above in relation to Fig. 2, stealth account key generation may be done using a smart wallet.

[58] At step 402A, a user of device 102, requests to make a deposit and provides a deposit amount to the private environment front end 104, via the user interface. For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be deposited in the multi-asset shielded pool governed by the private environment smart contract 106.

[59] At step 404A, private environment account keys are generated, as discussed above with reference to FIG.2.

[60] At step 406A, the private environment front end 104, requests, from the private environment smart contract 106 the private environment account Balance of the user. For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [61] At step 408A, the private environment Front end 104, receives the balance of the Users private environment account from the private environment smart contract 106. For example, in some embodiments the users balance is requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the user in the smart contract 106 as an encrypted balance. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[62] As discussed above with reference to equation 1, an EIGamal encrypted balance, b, for user A for a particular token type, T is: (CC2)TA [63] where Ci rG and C2 <-bG + rX,i.e, r E Zq is a random scalar and X <-xG is the users public key pk.

[64] At step 410A, private environment account keys are generated at the private environment front end, according to method 200, as discussed above with reference to FIG.2. At step 411A an anonymity set is generated, by requesting, from the private environment smart contract 106, L-1 decoy addresses and their balances" wherein each decoy address corresponds to a user account of a user not involved in the transaction. The anonymity set in the first state(inAccSet), 0 <-tpki,p14 " pki} is therefore made up of L accounts including the user account of the account to be deposited into. For example in some embodiments L=8. The anonymity set is used to create an additional level of privacy for users performing a transaction within the private environment. Therefore, the anonymity set may be generated based on the user account, for example based on the account balance of the user. For example, the anonymity set may comprise a fraction of accounts with a balance of zero and a fraction of accounts where the balance is greater than zero, wherein the fraction of the accounts differs based on the account balance of the user. For example, in an embodiment where the user has an account balance of zero prior to the deposit, a fraction of accounts in the anonymity set may also have a balance of zero.

[65] At step 412A, the private environment front end 104 computes a new account balance, b' for user A, using additive homomorphism of EIGamal scheme where balance b' is: (Cf 1,C' 2+ aG)34 where a is the deposit amount and G is a Babyjubjub elliptic curve group base point.

[66] Step 412A further comprises randomising the states of the other accounts in the anonymity set to form an output anonymity set, in the new state, outAccSet, (E'1rG,E'2+ rXi) where for each i E [1, .... 3], (EI,E)T is the previous state and Xi being the Elgamal public key of the account acci. The initial (inAccSet) and randomised, by r, (outAccSet) formed as a result of using additive homomorphism on each account in the anonymity set provide an additional level of privacy using a many-out-of-many proof according to "Many-out-of-many proofs and applications to anonymous zether, Benjamin E. Diamond, J.P Morgan Al Research, New York, United States, DO/: 10.1109/SP40001.2021.00026".

[67] At step 414A, the inputs of a deposit function in the private environment smart contract 106 are prepared, the inputs of the deposit function in the private environment smart contract 106 comprise any inputs required by the private environment smart contract 106 in order to perform a deposit transaction (referred to as a deposit function in the private environment smart contract 106). The deposit function in the private environment smart contract 106 is used in two cases. In depositing an asset in the Multi-Asset shielded pool of the private environment and when performing a from DeFi interaction.

For example, in some embodiments, a deposit transaction adds an amount X to one of the accounts in the anonymity set and then randomizes all of the accounts in the anonymity set. A user therefore needs to prove that the correct account received the correct amount of funds, that all accounts are randomised with the same randomness in a correct way. The public inputs to the deposit function in the private environment smart contract 106 therefore comprise: Cis in balance ciphertexts (C1,C2) before deposit; C2s in balance ciphertexts (C1,C2) before deposit; Cis in updated balance ciphertexts (C1,C2) after deposit; C2s in updated balance ciphertexts (C1,C2) after deposit; deposit amount, and optionally: y-coordinates of public aml keys in the anonymity set; accumulated signs of y-coordinates of points, y-coordinates of EIGamal encryption of index, and recipient identifier, wherein the balance of Cl and C2 in ciphertext may be obtained taking a y-coordinate.

[68] The private inputs to the deposit function in the private environment smart contract 106 further comprise: recipient's index; random value to randomize the ciphertexts; and random value used for encrypting recipient index and computing recipientHash.

[69] At step 416A, the private environment front end 104 computes a proof and a proof dataset comprising data required to verify the proof. The proof dataset may comprise all or some of the public inputs to the function in the private environment smart contract 106 and may vary depending on where it is provided in the method. The proof may comprise one or more statements that verify that the deposit was correctly performed.

[70] For example, in some embodiments, a deposit transaction proof provides statements that prove an amount X was added to the correct one of the accounts in the anonymity set and randomizes all of the accounts in the anonymity set.

[71] In such embodiments the proof dataset may comprise one or more of: the transaction amount, the token type, the public keys corresponding to each account in the anonymity set, the old and new account states according to the many-out-of-many proof described above, signs, compliances variables, an index of the user account in the anonymity set performing the deposit, random, r.

[72] However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof dependent and may differ depending on the proof.

[73] At step 418A, the private environment front end 104 sends the transaction request which comprises the proof and the proof dataset to the user's smart wallet. At step 420A, the user's smart wallet requests approval of the transaction from the user of user device 102. At step 422A, the user approves the transaction, and a signed transaction is provided to the smart wallet, and at step 424A, the smart wallet sends the signed approval to the private environment smart contract 106.

[74] At steps 426A -430A the private environment smart contract 106 may optionally provide checks to ensure compliance and accuracy.

[75] For example, in embodiments where an anonymity set is used to provide additional anonymity such as when the account is stored as a tuple, at step 426A, the private environment smart contract 106 checks that the account balance of each user in the anonymity set is the actual account balance of each user at the time of transaction i.e. that the inputs provided by the user and the front end are consistent with the balances in the smart contract.

[76] At step 428A, the private environment smart contract 106 checks that the transaction amount does not equal 0 and at step 430A, the private environment smart contract 106 checks asset type is a supported asset. At step 432A, the private environment smart contract 106 verifies the proof, for example, in some embodiments, verifying the proof comprises retrieving states of all the accounts in the anonymity set.

[77] At step 434A, the private environment smart contract 106 initiates transfer of the transaction amount to the user receiving the transaction. In some embodiments, this comprises creating a new account balance of the user of the user device.

[78] At step 436A, the private environment smart contract 106 updates the account states of each user in the anonymity set.

[79] FIG. 4B is a flow diagram of a method 400B for depositing an asset into the Private Environment Multi-asset shielded pool, according to the second embodiment, wherein a Merkle tree is used to store information about notes. Although the operations of the method 400B may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 400A may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once, and in a particular order in FIG. 4B, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[80] At step 4028, a user of device 102, requests to make a deposit and provides a deposit amount to the Private environment Front End 104, via the user interface. For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be deposited in the multi-asset shielded pool governed by the Private environment smart contract 106.

[81] At step 4048, Private environment account keys are generated, as discussed above with reference to FIG.2.

[82] In step 4148, the private environment front end creates a note that holds information about the asset identifier, amount, and the owner. For example, it can be of the form: C = Commitment( deposit amount, asset identifier, users public key of the private environment), where the asset identifier may comprise, for example a token ID.

[83] At step 416B, the Private environment Front End 104 computes a proof and a proof dataset comprising data required to verify the proof. The proof may comprise one or more statements that verify that the deposit was correctly performed. For example, the proof dataset comprises evidence that commitment C is correctly constructed and that the user knows the private key corresponding to the public key of the private environment.

[84] However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof dependent and may differ depending on the nature of the proof that is used.

[85] At step 4188, the Private environment Front End 104 sends the proof and the proof dataset to the user's smart wallet. At step 420B, the user's smart wallet requests approval of the transaction from the user of user device 102. At step 422B, the user approves the transaction by signing and in response, at step 4248, the smart wallet sends the signed approval to the Private environment Smart Contract 106.

[86] At steps 4288 -430B the Private environment smart contract 106 may optionally provide checks to ensure compliance and accuracy. At step 428B, the Private environment smart contract 106 may check that the transaction amount does not equal 0 and at step 4308, the Private environment smart contract 106 may provide any additional optional checks, for example that the asset is a supported asset.

[87] At step 4328, the Private environment smart contract 106 verifies the proof. Verifying the proof may comprise retrieving evidence that the commitment is correctly constructed.

[88] At step 434B, once the proof is verified, the Private environment smart contract 106 initiates transfer of the transaction amount to the user receiving the transaction. In some embodiments, this comprises adding a note corresponding to the user account keys and the deposit amount to the Merkle tree.

[89] Methods 400a and 400b, presented above, pertain to methods of anonymously depositing a transaction amount in the multi-asset shielded pool.

[90] Figure 5A is a flow diagram of a method 500A for withdrawing an asset from the private environment Multi-asset shielded pool according to the first embodiment. Although the operations of the method 500A may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 500A may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once and in a particular order in FIG. 5A, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable). As per the private environment account key generation method described above in relation to Fig. 2, stealth account key generation may be done using a smart wallet.

[91] At step 502A, a user of device 102, requests to make a withdrawal and provides a withdrawal amount to the private environment front end 104, via a user interface. For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be withdrawn from the multi-asset shielded pool governed by the private environment smart contract 106 and an externally owned address relating to the same chain as the multi-asset shielded pool, for example an Ethereum address for a multi-asset shielded pool with a smart contract on the Ethereum blockchain, to which the withdrawal should go.

[92] At step 504A, private environment account keys are generated, as discussed above with reference to FIG.2. At step 506A, the private environment front end 104 requests from the private environment smart contract 106 the private environment account Balance of the user. For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [93] At step 508A, the private environment smart contract 106, receives the balance of the Users private environment account. For example, in embodiments when the users balance is requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the user in the smart contract 106. For example, in some embodiments, an encrypted balance is provided. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[94] As discussed above with reference to equation 1, an EIGamal encrypted balance, b, for user A for a particular token type, T is: (cr,c)TA [95] At step 510A, private environment account keys are generated, as discussed above with reference to FIG.2. At step 512A, the private environment front end 104 decrypts the account balance using the account keys to get the account balance for the particular asset type. " [96] At step 514A, the private environment front end 104 obtains, from the private environment smart contract 106, L-1 decoy addresses, and their balances to form an anonymity set, wherein each decoy address corresponds to a user account of a user not involved in the transaction. The anonymity set (inAccSet), 0 <-0314, p14, plci} is therefore made up of L accounts including the user account of the account being withdrawn from. For example in some embodiments L=8.

[97] At step 516A, the private environment front end 104 computes the value of the user's balance, b' for user A using additive homomorphism of EIGamal where balance b' is: (C,C12 -aG)Ta where a is the withdrawal amount and G is a Babyjubjub elliptic curve group base point. Wherein the withdrawal amount is greater than 0 and less than or equal to the balance, b. after the withdrawal and encrypts this as a new user account balance.

[98] Step 516A further comprises randomising the states of the other accounts in the anonymity set to form an output anonymity set outAccSet,, [99] (E1,E2)- + rG,E1 2+ r X,) where for each i E [1, , 1], E)T is the previous state and Xi being the Elgamal public key of the account accf.

[100] At step 518A, the private environment front end 104 prepares the inputs to the withdraw function in the private environment smart contract 106., the inputs of the withdrawal function in the private environment smart contract 106 comprise any inputs required by the private environment smart contract 106 in order to perform a withdrawal transaction. The withdrawal function in the private environment smart contract 106 is used in two cases. In withdrawing an asset in the Multi-Asset shielded pool of the private environment and when performing a toDeFi interaction.

[101] For example, in some embodiments, for example an embodiment where the account balance for each asset held by the user in the multi-asset shielded pool is a tuple, a withdrawal transaction subtracts an amount X to one of the accounts in the anonymity set and randomizes all of the accounts in the anonymity set. A user therefore needs to prove that the correct account was deducted the correct amount of funds, that all accounts are randomised with the same randomness in a correct way. The public inputs to the deposit function in the private environment smart contract 106 therefore comprise: y-coordinates of C1s in balance ciphertexts (Cl,C2) before withdrawal; y-coordinates of C2s in balance ciphertexts (Cl,C2) before deposit; y-coordinates of Cis in updated balance ciphertexts (Cl C2) after withdrawal; y-coordinates of C2s in updated balance ciphertexts (Cl,C2) after withdrawal; y-coordinates of C2s in updated balance ciphertexts (Cl,C2) after withdrawal; y-coordinates of public aml keys in the anonymity set; accumulated signs of y-coordinates of points, withdrawal amount, y-coordinates of EIGamal encryption of index, recipient identifier. The private inputs to the deposit function in the private environment smart contract 106 further comprise: recipient's index; random value to randomize the ciphertexts; and random value used for encrypting recipient index and computing recipientHash.

[102] At step 520A, the private environment front end 104 computes a proof and a proof dataset comprising data required to verify the proof. The proof dataset may comprise all or some of the public inputs to the function in the private environment smart contract 106 and may vary depending on where it is provided in the method.. The proof may comprise one or more statements that verify that the deposit was correctly performed. For example, in some embodiments, a withdrawal transaction provides statements that prove an amount X was subtracted from the correct one of the accounts in the anonymity set and randomizes all of the accounts in the anonymity set.

[103] For example, in some embodiments, the proof dataset comprises: the transaction amount, the token type, the public keys corresponding to each account in the anonymity set, the old and new account states according to the many-out-of-many proof described above, signs, compliances variables, an index of the user account in the anonymity set performing the withdrawal, random, r and the externally owned address that lives on the same chain as multi-asset shielded pool of the user to which the withdrawn amount is to be provided. However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof-dependent and the above dataset may differ in its composition and constituent parts, depending on the proof.

[104] At step 522A, the private environment front end 104 constructs a message comprising a transaction request which comprises the proof and the proof dataset. At step 524A, the private environment front end 104 sends a sign request to the wallet, the sign request comprising the message to be signed. At step 526A the users Ethereum wallet requests approval of the transaction from the user of user device 102. At step 528A, the user approves the transaction and at step 530A, the smart wallet sends the signed approval to the private environment smart contract 106.

[105] At step 532A, the private environment smart contract 106 optionally checks that the account balance of each user in the anonymity set is the actual account balance of each user at the time of transaction.

[106] At step 534A, the private environment smart contract 106 verifies the proof using the proof dataset. At step 536A, the private environment smart contract 106 initiates the transfer of the transaction amount to the externally owned address that lives on the same chain as multi-asset shielded pool specified by the user and at step 538A, the private environment smart contract 106 updates the account states of each user in the anonymity set.

[107] Methods 500a and 500b pertain to a method of anonymously withdrawing a transaction amount from the multi-asset shielded pool.

[108] FIG. 5B is a flow diagram of a method 500B for withdrawing an asset from the Private environment Multi-asset shielded pool according to second embodiment, wherein a Merkle tree is used to store information about notes. Although the operations of the method 500B may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 500B may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 5B, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[109] At step 502B, a user of device 102, requests to make a withdrawal and provides a withdrawal amount to the Private environment Front End 104, via a user interface. For example, in some embodiments, the user of user device 102 specifies a particular note which holds a balance to be withdrawn from the multi-asset shielded pool governed by the Private environment smart contract 106 and an externally owned address that lives on the same chain as multi-asset shielded pool to which the withdrawal should go.

[110] In some embodiments, the account balance of user of user device 102 is comprises two or more notes, wherein each note corresponds to an amount of balance for an asset, in which case, the private environment front end may optimise which nots to spend or the user may choose which note to spend. For example, a user balance of 7 tokens might be stored as a "4" token note and a "3" token note. In some examples, the user may choose to withdraw a fraction of a note, for example "2" tokens of the "4" token note. The user may withdraw a fraction of the note using the methods described herein, for example, the user may follow the withdrawal process described below for the entire note and then may follow the deposit process described above with reference to FIG. 4B, to deposit the remaining tokens as a new note. The transaction may alternatively comprise different inputs and outputs wherein the may outputs comprise a note that contains the remaining amount (i.e. the change).

[111] At step 504B, private environment account keys are generated, as discussed above with reference to FIG.2. At step 506B, the private environment Front End 104 requests from the private environment Smart Contract 106 the Private environment account balance of the user. For example, in some embodiments, where the account balance is stored as one or more notes, the step 506B of requesting the balance comprises scanning through the entire transaction history, finding the one or more notes corresponding to the user, and then leaving out the spent notes [112] At step 508B, the Private environment front end 104, receives the balance of the Users Private environment account from the smart contract 106 in the form of one or more identified notes. The identified notes are then compared to the nullifier set, wherein the nullifier set comprises nullifiers, each nullifier marks the corresponding note in the Merkle tree as spent.

[113] At step 510B, Private environment account keys are generated, as discussed above with reference to FIG.2.

[114] At step 518B, the Private environment Front End 104 prepares the inputs to the withdraw function in the private environment smart contract 106, wherein the inputs to the withdrawal function in the private environment smart contract 106 comprise a proof of inclusion of the note in the Merkle tree, ownership of the note and correct computation of the nullifier corresponding to the note and further comprise any variables that need to be provided to the private environment smart contract 106 in order for the smart contract to make the withdrawal.

[115] At step 520B, the Private environment Front End 104 computes a proof and a proof dataset comprising data required to verify the proof. For example, in some embodiments, the proof dataset comprises a proof that the user owns the note, and the note is included in the Merkle tree. The proof dataset may further comprise proof that the nullifier was correctly determined.

[116] At step 522B, the Private environment Front End 104 constructs a message comprising the proof and the proof dataset [117] At step 524B, the Private environment Front End 104 sends a sign request to the wallet, the sign request comprising the message created in the preceding step, to be signed.

[118] At step 526B the user's smart wallet requests approval of the transaction from the user of user device 102.

[119] At step 528B, the user approves the transaction and at step 530B, the smart wallet sends the signed approval to the Private environment Smart Contract 106.

[120] At step 532B, the Private environment Smart Contract 106 checks that the specified nullifier corresponding to note is not in the nullifier list.

[121] At step 534B, the Private environment Smart Contract 106 verifies the proof using the proof dataset.

[122] At step 536B, the Private environment Smart Contract 106 initiates the transfer of the transaction amount to the externally owned address that lives on the same chain as multi-asset shielded pool specified by the user and [123] At step 538B, the Private environment Smart Contract 106 adds the nullifier to the nullifier set.. In the example where a fraction of a note was withdrawn, the private environment smart contract 106 may also add a note corresponding to the unspent fraction to the Merkle tree.

[124] FIG. 6A is a flow diagram of a method 600A for transferring an asset within the private environment Multi-asset shielded pool according to the first embodiment. Although the operations of the method 600A may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 600A may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 6, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable.

[125] At step 602A, a user of device 102, requests a transfer and provides, to the private environment front end 104, via the user interface, a transaction amount and a private environment Address of the receiver of the transaction amount. For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be transferred from the first user account to the receiver user account also within the multi-asset shielded pool governed by the private environment smart contract 106.

[126] At step 604A, private environment account keys are generated, as discussed above with reference to FIG.2. At step 606A, the private environment front end 104 requests from the private environment smart contract 106 the private environment account Balance of the user sending the transaction amount (the sender). For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [127] At step 608A, the private environment smart contract 106, receives the balance of the sender's private environment account. For example, in embodiments when the senders balance is requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the sender in the smart contract 106. For example, in some embodiments, an encrypted balance is provided. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[128] As discussed above with reference to equation 1, an EIGamal encrypted balance, b, for sender A for a particular token type, T is: (Cr,CT 2)A [129] At step 610A, the private environment front end 104 requests from the private environment smart contract 106 the private environment account Balance of the user receiving the transaction amount (the receiver). For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [130] At step 612A, the private environment smart contract 106, receives the balance of the receiver's private environment account. For example, in embodiments when the receivers balance is requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the receiver in the smart contract 106. For example, in some embodiments, an encrypted balance is provided. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[131] As discussed above with reference to equation 1, an EIGamal encrypted balance, b, for receiver B for a particular token type, T is: [132] At step 614A, private environment account keys of the sender are generated, as discussed above with reference to FIG.2.

[133] At step 616A, the private environment front end 104, computes the balance of the sender using the generated account keys.

[134] At step 618A" the private environment front end 104 obtains, from the private environment smart contract 106, L-2 decoy addresses, and their encrypted balances to form an anonymity set. , wherein each decoy address corresponds to a user account of a user not involved in the transaction. The anonymity set, inAccSet 0 <-tpicf, pk, , pkt} is therefore made up of L accounts, including the user account of the sender and the receiver.

[135] At step 620A, the private environment front end 104, computes a new sender and receiver balance after transfer using additive homomorphism on the encrypted balances of each account balance corresponding to each account in the anonymity set, to form outAccSet according to the many-out-ofmany proof [136] At step 622A, the private environment front end 104 prepares the inputs to the transfer function in the private environment smart contract 106, the inputs of the transfer function in the private environment smart contract 106 comprise any inputs required by the private environment smart contract 106 in order to perform a transfer transaction, for example the inAccSet and outAccSet.

[137] At step 624A, the private environment front end 104 computes a proof and a proof dataset comprising data required to verify the proof. For example, in some embodiments, the proof dataset may comprise: the transaction amount, the token type, the public keys corresponding to each account in the anonymity set, the old and new account states according to the many-out-of-many proof described above, signs, compliances variables, an index of both the user accounts in the anonymity set involved in the transaction, random, r.

[138] At step 626A the private environment front end 104 constructs a message comprising the transaction request which comprises the proof and the proof dataset and sends a sign request to the wallet, the sign request comprising the message to be signed to the sender's smart wallet.

[139] At step 628A, the user's smart wallet requests approval of the transaction from the user of user device 102 and at step 630 the user of user device 102 approves the transaction request.

[140] At step 632A, the smart wallet sends the signed transaction to the private environment smart contract 106.

[141] At step 634A, the private environment smart contract 106 optionally checks that the account balance of each user in the anonymity set is the actual account balance of each user at the time of transaction.

[142] At step 636A, the private environment smart contract 106, verifies the proof using the proof dataset. At step 638A the private environment smart contract 106 initiates the transfer of the transaction amount from the sender to the receiver and at step 640A, the private environment smart contract 106 updates the account states of each user in the anonymity set.

[143] FIG. 6B is a flow diagram of a method 600B for transferring an asset within the private environment Multi-asset shielded pool, according to the second embodiment, wherein a Merkle tree is used to store information about notes. Although the operations of the method 600B may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 600B may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 6B, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable.

[144] At step 602B, a user of device 102, requests a transfer and provides, to the private environment front end 104, via the user interface, a transaction amount and a private environment Address of the receiver of the transaction amount. The sender may specify a particular note or notes to transfer to the receiver. For example, in some embodiments, the account balance of the sender is stored two or more notes, wherein each note corresponds to an amount of balance for an asset, in which case, the sender additionally specifies which of the two or more notes that they wish to use to make a transfer. In some examples, the user may choose to transfer a fraction of a note, for example 2 tokens of the 4 token note. The user may transfer a fraction of the note using the methods described herein, for example, by creating two notes, one corresponding to the recipient and one corresponding to the sender.

[145] At step 604A, private environment account keys corresponding to the sender are generated, as discussed above with reference to FIG.2.

[146] At step 606A, the private environment front end 104 requests from the private environment smart contract 106 the private environment account balance of the user sending the transaction amount (the sender). For example, in some embodiments, where the account balance is stored as one or more notes, the step 506B of requesting the balance comprises scanning through the entire transaction history in a Merkle tree, finding the one or more notes corresponding to the user, and then removing the spent notes by computing the corresponding nullifiers and checking if they are included in the nullifier set.

[147] At step 608A, the private environment front end 104, receives the balance of the Users Private environment account in the form of one or more identified notes. The identified notes are then compared to the nullifier, wherein the nullifier set comprises nullifiers, each nullifier corresponding a spent note.

[148] At step 622B, the private environment front end 104 prepares the inputs to the transfer function in the private environment smart contract 106. The inputs of the transfer function in the private environment smart contract 106 comprise any inputs required by the private environment smart contract 106 in order to perform a transfer transaction.

[149] At step 624B, the private environment front end 104 computes a proof and a proof dataset comprising data required to verify the proof. For example, in some embodiments, the proof dataset comprises a proof that the sender owns the note and the note is included in the Merkle tree.. The proof dataset may further comprise proof that the nullifier was correctly determined for the note the sender has identified and any input or output notes are correctly computed. The proof may comprise one or more statements that verify evidence that commitment C is correctly constructed for the note to be provided to the receiver.

[150] At step 626B the private environment front end 104 constructs a message comprising the proof and the proof dataset and sends a sign request to the wallet, the sign request comprising the message to be signed to the sender's smart wallet.

[151] At step 6288, the user's smart wallet requests approval of the transaction from the user of user device 102 and at step 630 the user of user device 102 approves the transaction request.

[152] At step 632B, the smart wallet sends the signed approval to the private environment smart contract 106.

[153] At step 634B, the private environment smart contract 106 checks that the nullifier corresponding to the note transferred by the sender is not in the nullifier set.

[154] At step 636B, the private environment smart contract 106, verifies the proof using the proof dataset. At step 638B the private environment smart contract 106 initiates the transfer of the transaction amount from the sender to the receiver and at step 640, the private environment smart contract 106 adds a nullifier corresponding to the note used in the transaction to the nullifier set and adds a note corresponding toe the transaction amount and the receiver (an output note of the transaction) to the Merkle tree.

[155] Methods 600a and 600b pertain to a method of anonymously performing a transaction within the multi-asset shielded pool.

[156] FIG.7 depicts a method 700 for transferring assets between first user account of the primary user and an application on a blockchain, for example, a DeFi application. Although the operations of the method 700 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1 and/or the example of a hardware implantation on which the present methods might be performed. the method 700 may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 7, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[157] Step 702 comprises receiving a request for a transaction to transfer assets between a first user account of a primary user and an application on a blockchain. In some embodiments, the request to transfer assets comprises a transaction amount and an application identifier of the application. In some embodiments, the request to transfer assets further comprises an asset type. For example, in embodiment 1, the primary user, may have an existing quantity of an asset type in their private environment account and may make a request to transfer a particular asset type to an application on a blockchain. Alternatively, the primary user may make a request to transfer a particular asset type from an application on a blockchain into their private environment account, wherein in both cases deriving the private environment account comprises deriving a first private key (sk), first public key (pk) and a first address.

[158] For example, in embodiment 2, the request comprises a request to transfer to an on-chain application, the request to transfer assets comprises a note or notes to transfer.

[159] Step 704 comprises obtaining, an anonymity set comprising a first user account state of the primary user and at least one other account state corresponding to a different user of the private environment protocol.

[160] For example, in embodiment 1, an anonymity set of 1 accounts states, 0, pkj,} [161] is obtained by retrieving 1-1 account states, each state corresponding to a user of the private environment not involved in the transaction.

[162] The account states corresponding to the account balance of each user according to: (pkA. (c1, C2)) [163] where pk is the Elgamal public key, pk for asset i corresponding to the private key, ski., for a given user A and (C1,C2)lA is the Elgamal ciphertext of the user account balance for asset i and where C1 <-rG and C2 bG rX,i.e, r E is a random scalar and X xG is the users public key pk.

[164] For example, in embodiment 2, the anonymity set may be a Merkle tree, wherein each node in the Merkle tree corresponds to a note indicating an amount of an asset transferred into the private environment smart contract and further comprises an identifier of a user.

[165] Step 706 comprises deriving, a second user account of the primary user based platform address and the application identifier. The second user account address is a deterministic address corresponding to a particular primary user, application identifier pair.

[166] For example, in embodiment 1, step 706 is performed according to the method 300 described above with reference to FIG. 3., wherein the deriving of the second user account comprises deriving a second private key (sk), second public key (pk) and a second address.

[167] For example, in embodiment 2, step 706 is performed according to the method 300 described above with reference to FIG. 3., wherein the deriving of the second user account comprises deriving a second private key (sk), second public key (pk) and a second address [168] Step 708 comprises computing, a state for the first user account based at least in part on a first user account state and the transaction amount, for example, a state may be anything indicative of an account balance, for example, an encrypted balance, or a route or address to an account balance or an offset to an account balance such as a note, nullifier or homomorphic manipulation of an account balance [169] For example, in embodiment 1, the computed state for the first user account is an updated account state for the first user account. Wherein step 708 further comprises computing an updated account state for each account in the anonymity set according to the many-out-of-many proof using Elgamal.

[170] For example, in embodiment 2, when the request comprises a transfer to an on-chain application, step 708 comprises computing one or more nullifiers corresponding to the one or more notes to be transferred. Alternatively, when the request comprises a transfer from an on-chain application, step 708 comprises creating one or more notes corresponding to the transaction amount.

[171] Step 710 comprises generating, a proof based on the anonymity set. For example, in embodiment 1, the generated proof comprises at least that the correct account transferred or received the correct amount of funds and that all accounts are randomised with the same randomness in a correct way.

[172] For example, in embodiment 2, generating the proof based on the Merkle tree comprises proving that the note is included in the Merkle tress, the user owns the note and the nullifier corresponding to the note is correctly computed.

[173] Step 712 comprises verifying, the proof. For example, in embodiment 1, verifying the proof comprises verifying at least that the correct account transferred or received the correct amount of funds and that all accounts are randomised with the same randomness in a correct way.

[174] For example, in embodiment 2, verifying the proof may further comprises verifying that the provided nullifier is not in the nullifier set or that a given root for a Merkle tree is a valid root.

[175] Step 714, comprises initiating, the transfer of assets between the first and second primary user accounts. For example, in embodiment 1, the transfer of assets is between a balance of a particular asset held by a user in the private environment and an on-chain application. For example, in embodiment 2" this requires moving assets from or to the second primary user account by providing the transfer amount to the second primary user account or withdrawing the transfer amount from the second primary user account; assets held within the second primary user account (also referred to as a Stealth account herein) are not held within the private environment smart contract.

[176] Step 716 comprises updating, the account states for each account in the anonymity set. For example, in embodiment 1, the account states are updated upon verification of the many-out-of-many proof. For example, in embodiment 2, this requires computing a new root node for the Merkle tree in response to the transaction.

[177] Using the stealth account keys generation for interacting with an application on the blockchain, such as a DeFi application, a user is provided a shielded stealth address which preserves user privacy and removes the requirement for bridge contracts and hence, also the need for sharing risk with other users. In combination with the techniques described herein for depositing to and withdrawing from the private environment with anonymously, a user may interact with on-chain applications whilst minimising cost and preserving anonymity.

[178] FIG. 8A is a flow diagram of a method 800A for transferring an asset from the private environment Multi-asset shielded pool to an application on a blockchain/protocol according to the first embodiment. Although the operations of the method 800 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 800A may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once and in a particular order in FIG. 8A, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[179] At step 802A, a user of device 102, requests, to the private environment front end 104, via a user interface, a toDeFi interaction, the interaction comprising an amount and a DeFi identifier.

[180] For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be transferred from the first user account within the multi-asset shielded pool governed by the private environment smart contract 106 to the chosen DeFl.

[181] At step 804A, private environment account keys are generated, according to the method 200 as discussed above with reference to FIG.2.

[182] At step 806A, the private environment front end 104 requests from the private environment smart contract 106 the private environment account Balance of the user. For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [183] At step 808A, the private environment front end 104, receives the balance of the user's private environment account from the private environment smart contract 106. For example, in embodiments when the senders balance was requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the sender in the smart contract 106. For example, in some embodiments, an encrypted balance is provided. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[184] At step 810, the private environment Smart front end 104, decrypts the account balance. At step 812A, stealth account keys are generated, according to the method 300 discussed above with reference to FIG.3.

[185] At step 814A, the private environment front end 104, requests, from the DeFi, using the stealth Address, the balance of the users DeFi. At step 816A, the private environment front end 104 obtains the balance associated with the users stealth Address and at step 818A, the User interface shows the users stealth account balance to the user of user device 102.

[186] At steps 820A, 822A and 824A, an anonymity set is obtained and new account states are determined for each account in the anonymity set according to steps 512A and 514A before the inputs to the withdraw function in the private environment smart contract 106 are prepared according to 516A in the withdrawal method 500A.

[187] At step 826A, the private environment front end 104 computes a proof and a proof dataset comprising data that may be used to verify the proof For example, in some embodiments, the proof dataset comprises: the transaction amount, the token type, the public keys corresponding to each account in the anonymity set, the old and new account states according to the many-out-of-many proof using additive homomorphism described above, signs, compliances variables, an index of the user account in the anonymity set performing the deposit, random, r, DeFi address and stealth address. However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof dependent and may differ depending on the proof.

[188] At step 828A, the private environment front end 104 constructs a message comprising the transaction request which comprises the proof and proof dataset. At step 830A, the private environment front end 104, stealth account keys are generated, as discussed above with reference to FIG.3. At step 832A, the private environment front end 104 requests approval of the transaction from the user of user device 102 and at step 833A, the user approves the transaction and the smart wallet sigs the transaction.

[189] At step 834A, the smart wallet provides that signed transaction request for toDeFi to the smart contract. For example, in some embodiments, the request to comprises the proof and the proof dataset. At step 836A, the private environment smart contract 106 checks that the account balance of each user in the anonymity set is the actual account balance of each user at the time of transaction, [190] At step 838A the private environment smart contract 106 verifies the proof and at step 840A, upon verification of the proof, the private environment smart contract 106 initiates a transfer of the transaction from the private environment smart contract Address to the stealth Address. At step 842A, the private environment smart contract 106 updates the public key states/account states in the anonymity set.

[191] FIG. 8B is a flow diagram of a method 800B for transferring an asset from the private environment Multi-asset shielded pool to an application on a blockchain/protocol according to the second embodiment, wherein a Merkle tree is used to store information about notes made into the private environment smart contract 106. Although the operations of the method 800 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 800B may be used in any suitable setting to perform any suitable support operations. Operations are each illustrated once and in a particular order in FIG. 8B, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[192] At step 802B, a user of device 102, requests, to the private environment front end 104, via a user interface, a "toDeFi" interaction, the interaction comprising an amount and an identifier of an on-chain application, such as a DeFi identifier, wherein a DeFi identifier may comprise a smart contract address of the DeFi. For example, in some embodiments, the user of user device 102 specifies a particular note which holds a balance to be transferred to a specific on-chain application.

[193] In some embodiments, the account balance of user of user device 102 is stored two or more notes, wherein each note corresponds to an amount of balance for an asset, in which case, the user additionally specifies which of the two or more notes that they wish to use to make a withdrawal. In some examples, the user may choose to withdraw a fraction of a note, for example 2 tokens of the 4 token note. The user may withdraw a fraction of the note using the methods described herein, for example, the user may follow the transfer process described below for the entire note and then follows the withdraw process described above with reference to FIG. 4B to deposit the remaining tokens as a new note.

[194] At step 804B, private environment account keys are generated, according to the method 200 as discussed above with reference to FIG.2.

[195] At step 806B, the Private environment Front End 104 requests from the Private environment Smart Contract 106 the Private environment account balance of the user. For example, in some embodiments, where the account balance is stored as one or more notes, the step 806B of requesting the balance comprises scanning through the entire transaction history, finding the one or more notes corresponding to the user, and then leaving out the spent notes.

[196] At step 808B, the Private environment front end 104, receives the balance of the Users Private environment account from the private environment smart contract 106 in the form of one or more identified notes. The identified notes are then compared to the nullifier set, wherein the nullifier set comprises nullifiers, each nullifier marks the note in the Merkle tree as spent.

[197] At step 812B, stealth account keys are generated at the private environment front end 104, according to the method 300 discussed above with reference to FIG.3.

[198] At step 814B, the private environment front end 104, requests, from the DeFi, using the stealth Address, the balance that the user' holds for the asset at the on-chain application (for example the DeFi application). At step 816B, the private environment front end 104 obtains the balance associated with the users stealth Address and at step 818B, the User interface displays the users stealth account balance to the user of user device 102.

[199] At step 824B the Private environment Front End 104 prepares the inputs to the withdraw function in the private environment smart contract 106, wherein the inputs to the withdrawal function in the private environment smart contract 106 comprise a Merkle root, a path to the note, private keys required to prove ownership of the note, a nullifier corresponding to the note and further comprise any variables that need to be provided to the private environment smart contract 106 in order for the smart contract to make the withdrawal.

[200] At step 826B, the private environment front end 104 computes a proof and a proof dataset comprising data that may be used to verify the proof For example, in some embodiments, the proof dataset comprises a proof that the user owns the note, for example, the user may provide a private key corresponding to the public key comprising part of the commitment corresponding to the one or more notes they wish to withdraw. The proof dataset may further comprise proof that the nullifier was correctly determined.

[201] At step 828B, the private environment front end 104 constructs a message using the proof and proof dataset. At step 830B, the private environment front end 104, stealth account keys are generated, as discussed above with reference to FIG.3. At step 832B, the private environment front end 104 [202] requests approval of the transaction from the user of user device 102 and at step 833A, the user approves the transaction and the smart wallet sigs the transaction.

[203] At step 834B, the smart wallet provides that signed transaction request for toDeFi to the smart contract [204] At step 838B the private environment smart contract 106 verifies the proof and at step 840B, upon verification of the proof, the private environment smart contract 106 initiates a transfer of the transaction from the private environment smart contract Address to the stealth Address. At step 842B, the private environment smart contract 106 adds the nullifier or nullifiers to the global nullifier set. In the example where a fraction of a note was withdrawn, the private environment smart contract 106 may also add a note corresponding to the unspent fraction to the Merkle tree.

[205] Methods 800a and 800b pertain to a method of anonymously interacting with an on-chain application which avoids the need to use bridge contracts, and maintains user anonymity.

[206] FIG. 9A is a flow diagram of a method 900 A for transferring an asset from an application on a blockchain to the private environment Multi-asset shielded pool according to the first embodiment. Although the operations of the method 900 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 900 A may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 9 A, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[207] At step 902 A, a user of device 102, requests, to the private environment front end 104, via a user interface, a fromDeFi interaction, the interaction comprising an amount and an identifier of the application on the blockchain DeFi identifier.

[208] For example, in some embodiments, the user of user device 102 specifies an asset type, for example by specifying a token type or token ID corresponding to the transaction amount to be transferred from the chosen DeFI to the first user account within the multi-asset shielded pool governed by the private environment smart contract 106.

[209] At step 904 A, stealth account keys are generated, according to the method 300 discussed above with reference to FIG.3.

[210] At step 906 A, the private environment front end 104, requests, from the DeFi, the balance of associated with the stealth Address and optionally an asset type.

[211] At step 908 A, the private environment front end 104 receives the balance associated with the stealth Address and optionally an asset type.

[212] At step 910 A, the user provides, to the private environment front end 104 an amount and private environment account to which the transaction is to be sent to. For example, in some embodiments the user may also provide an asset type, Tin the form of a token type or token ID.

[213] At step 912 A, the private environment front end 104, requests from the private environment smart contract 106 the private environment account Balance of the corresponding to the private environment Address. For example, in some embodiments, the private environment front end 104 requests the balance associated with the Users private environment account for a given asset type, T. [214] At step 914 A, the private environment front end 104, receives the balance of the user's private environment account. For example, in embodiments when the senders balance was requested for a particular asset, T, the private environment smart contract 106 provides the balance of asset T held by the sender in the smart contract 106. For example, in some embodiments, an encrypted balance is provided. In one embodiment, the balance is encrypted using Elgamal scheme (as shown in equation 1), however, it should be understood that any appropriate homomorphic encryption scheme may be used in order to provide an encrypted balance.

[215] At step 916 A, the private environment front end 104, computes a new balance for corresponding to the transaction amount. For example, in some embodiments where the account balance is encrypted, the front end 104 computes a new balance using additive homomorphism.

[216] At steps 916A, 918A and 920A, an anonymity set is obtained and new account states are determined for each account in the anonymity set according to steps 411A and 412A before the inputs to the deposit function in the private environment smart contract 106 are prepared according to 414A in the deposit method 400A.

[217] At step 922 A, the private environment front end 104 computes the proof and a proof dataset comprising data that may be used to verify the proof. For example, in some embodiments, the proof dataset comprises: the transaction amount, the token type, the public keys corresponding to each account in the anonymity set, the old and new account states according to the many-out-of-many proof described above, signs, compliances variables, an index of the user account in the anonymity set performing the deposit, random, r, DeFi address and stealth address. However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof dependent and may differ depending on the proof.

[218] At step 924A, the private environment front end 104 constructs a message comprising the transaction request which comprises the proof and proof dataset.

[219] At step 926A, the private environment front end 104 generates stealth account keys according to the method 300 as discussed above with reference to FIG.3. At step 928, the private environment front end 104 signs the transaction payload with the stealth private key and at step 930, the private environment front end 104 sends the proof and proof dataset to the private environment smart contract 106.

[220] At steps 932A-936A the private environment smart contract 106 provides checks to ensure compliance and accuracy.

[221] For example, in some embodiments, at step 932A, the smart contract 106 checks that the account balance of each user in the anonymity set is the actual account balance of each user at the time of transaction i.e. that the inputs provided by the user and the front end are consistent with the balances in the smart contract 106, at step 934A, the private environment smart contract 106 checks that the transaction amount does not equal 0 and at step 936A, the private environment smart contract 106 checks asset type is a supported asset. At step 938A the private environment smart contract 106 verifies the proof by retrieving states of all the account states. At step 940A the private environment smart contract 106 initiates the transfer from the stealth Address to private environment smart contract 106 and at step 942A the private environment smart contract 106 updates the account states of each user in the anonymity set.

[222] FIG. 9B is a flow diagram of a method 900B for transferring an asset from an application on a blockchain to the private environment Multi-asset shielded pool according to the second embodiment, wherein a Merkle tree is used to store information about notes. Although the operations of the method 900 may be illustrated with reference to particular embodiments disclosed herein (e.g., the system 100 discussed herein with reference to FIG. 1), the method 900 A may be used in any suitable setting to perform any suitable support operations. Operations are illustrated once each and in a particular order in FIG. 9B, but the operations may be reordered and/or repeated as desired and appropriate (e.g., operations may be performed in parallel, as suitable).

[223] At step 902B, a user of device 102, requests, to the private environment front end 104, via a user interface, a fromDeFi interaction, the interaction comprising an amount and an identifier of the application on the blockchain DeFi identifier.

[224] At step 9048, stealth account keys are generated, according to the method 300 discussed above with reference to FIGS. [225] At step 906B, the private environment front end 104, requests, from the DeFi, the balance of associated with the stealth Address.

[226] At step 908B, the private environment front end 104 receives the balance associated with the stealth Address.

[227] At step 910B, the user provides, to the private environment front end 104 an amount and private environment account keys corresponding to the user to which the transaction is to be sent to.

[228] At step 920B a deposit function in the private environment smart contract 106 is implemented, the 33 private environment front end 104 creates a note that holds information about the asset identifier, amount, and the owner, at the private environment front end 104, of the deposit amount in the form: C = Commitment( deposit amount, asset identifier, user public key of the PE), [229] where the asset identifier may comprise, for example a token ID.

[230] At step 922B, the private environment front end 104 computes the proof and a proof dataset comprising data that may be used to verify the proof. . For example, the proof dataset comprises evidence that commitment C is correctly constructed, for example, the variables used to create the commitment and that the user knows the corresponding secret key. However, it is understood that since the proof dataset simply comprises any data necessary for verifying the proof, it is proof dependent and may differ depending on the proof.

[231] At step 924B, the private environment front end 104 constructs a message using the proof and proof dataset.

[232] At step 9268, the private environment front end 104 generates stealth account keys according to the method 300 as discussed above with reference to FIG.3. At step 928B, the private environment front end 104 signs the transaction payload with the stealth private key and at step 930B, the private environment front end 104 sends the proof and proof dataset to the private environment smart contract 106.

[233] At step 934B, the private environment smart contract 106 checks that the transaction amount does not equal 0 and at step 936, the private environment smart contract 106 checks asset type is a supported asset. At step 938B the private environment smart contract 106 verifies the proof by retrieving states of all the account states. At step 940B the private environment smart contract 106 initiates the transfer from the stealth Address to private environment smart contract 106 and at step 9428 the smart contract adds a note corresponding to the user account keys and the transaction amount to the Merkle tree.

[234] Methods 900a and 900b pertain to a method of anonymously interacting with an on-chain application without using bridge contracts.

Example Hardware Implementation [235] FIG. 10 illustrates a block diagram of one implementation of a computing device 1000 within which a set of instructions, for causing the computing device to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the computing device may be connected (e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The computing device may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The computing device may be a personal computer (PC), a tablet computer, a set-top box (SIB), a Personal Digital Assistant (FDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[236] The example computing device 1000 includes a processing device 1002, a main memory 1004 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 1006 (e.g., flash memory, static random access memory (SRAM), etc.), and a secondary memory (e.g., a data storage device 1018), which communicate with each other via a bus 1030.

[237] Processing device 1002 represents one or more general-purpose processors such as a microprocessor, central processing unit, or the like. More particularly, the processing device 1002 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIVV) microprocessor, processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 1002 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processing device 1002 is configured to execute the processing logic (instructions 1022) for performing the operations and steps discussed herein.

[238] The computing device 1000 may further include a network interface device 1008. The computing device 1000 also may include a video display unit 1010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1012 (e.g., a keyboard or touchscreen), a cursor control device 1014 (e.g., a mouse or touchscreen), and an audio device 1016 (e.g., a speaker).

[239] The data storage device 1018 may include one or more machine-readable storage media (or more specifically one or more non-transitory computer-readable storage media) 1028 on which is stored one or more sets of instructions 1022 embodying any one or more of the methodologies or functions described herein. The instructions 1022 may also reside, completely or at least partially, within the main memory 1004 and/or within the processing device 1002 during execution thereof by the computer system 1000, the main memory 1004 and the processing device 1002 also constituting computer-readable storage media.

[240] The various methods described above may be implemented by a computer program. The computer program may include computer code arranged to instruct a computer to perform the functions of one or more of the various methods described above. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer, on one or more computer readable media or, more generally, a computer program product. The computer readable media may be transitory or non-transitory. The one or more computer readable media could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. Alternatively, the one or more computer readable media could take the form of one or more physical computer readable media such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-RNV or DVD.

[241] In an implementation, the modules, components and other features described herein can be implemented as discrete components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices.

[242] A "hardware component" is a tangible (e.g., non-transitory) physical component (e.g., a set of one or more processors) capable of performing certain operations and may be configured or arranged in a certain physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may be or include a special-purpose processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations.

[243] Accordingly, the phrase "hardware component" should be understood to encompass a tangible entity that may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein.

[244] In addition, the modules and components can be implemented as firmware or functional circuitry within hardware devices. Further, the modules and components can be implemented in any combination of hardware devices and software components, or only in software (e.g., code stored or otherwise embodied in a machine-readable medium or in a transmission medium).

[245] Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "receiving", "determining", "comparing "enabling", "maintaining," "identifying", "providing", "applying", "training" or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[246] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to specific example implementations, it will be recognized that the disclosure is not limited to the implementations described but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[247] A method is provided comprising: receiving, from a primary user of a smart wallet, a request to transfer assets between a first user account of the primary user and an application on a blockchain, the request to transfer assets comprising a transaction amount and an application identifier; obtaining by a computational environment front end, from a smart contract, an anonymity set, the anonymity set comprising an account balance of a first user account and at least one other account balance, wherein the first user account is derived based on the primary user's smart contract based platform address and wherein each of the at least one other encrypted account balances correspond to a respective user account of a respective user not involved in the transaction; obtaining, by the front end, a balance corresponding to a second user account of the primary user, wherein the second user account is derived based on the primary user's smart contract based platform address and the application identifier; computing, by the front end, using additive homomorphism of EIGamal scheme, an updated first user account balance based on the transaction amount; generating, by the front end, a proof based on the anonymity set, the method further comprising, by the smart contract: verifying the proof; initiating, as a result of verifying the proof, the transfer of assets between the first and second primary user accounts; updating the account states for each account in the anonymity set.

[275] As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the block(s) of the flowchart illustrations and/or block diagrams. The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device provide processes for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams. The flowchart illustrations and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Claims

CLAIMS1. A computer implemented method comprising: receiving, at a computational environment front end, from a primary user, a request for a transaction to transfer assets between a first user account of the primary user and an application on a blockchain, the request to transfer assets comprising a transaction amount and an application identifier of the application; obtaining, at afront end, from a smart contract, an anonymity set, the anonymity set comprising an account state of a first user account and at least one other account state, wherein the first user account is derived based on a smart contract-based platform address of the primary user and wherein each of the at least one other account states correspond to a user account of a user not involved in the transaction; deriving, at a front end, a second user account of the primary user, wherein the second user account is derived based on the primary user's smart contract-based platform address and the application identifier; computing, at a front end, a state for the first user account, wherein the state forthe first user account is computed based at least in part on a first user account state and the transaction amount; generating, at a front end, a proof, the proof based on the anonymity set; verifying, by the smart contract, the proof; initiating, by the smart contract, as a result of verifying the proof, the transfer of assets between the first and second primary user accounts; updating, by the smart contract an account state for each account in the anonymity set.
2. The method of claim 1, wherein deriving a first account comprises generating a first private key (sk), first public key (pk) and a first address and wherein deriving a second account comprises generating a second private key, second public key and second address.
3 The method of any preceding claim, wherein: the account state of the first user account corresponds to an account balance; the smart contract comprises a set of rules to operate a multi-asset shielded pool; and wherein the account balance corresponding to the first user account is held within the smart contract governing the multi-asset shielded pool.
4. The method of any preceding claim, wherein the request to transfer assets further comprises an asset identifier of a particular asset type and wherein the account state of the first user account further corresponds to the particular asset type.
5. The method of any preceding claim wherein the proof further comprises: proof that a KYC/AML compliance encryption condition is satisfied.
6. The method of any preceding claim wherein the proof further comprises: proof that the transaction amount > 0.
7. The method of any preceding claim, wherein the computed state for the first user account is an updated account state for the first user account.
8. The method of claim 7, further comprising computing, by the user interface/front end, an updated account state for each account state in the anonymity set
9. The method of claims 3 to 8 wherein the multi-asset shielded pool comprises one or more registries, wherein each registry corresponds to a specific asset type and comprises one or more user account states corresponding to specific asset type.
10. The method of any preceding claim, wherein the anonymity set comprises 7 other user accounts.
11. The method of claim 9 or claim 10 dependent on claim 9, wherein the anonymity set is determined based on the asset identifier.
12. The method of any preceding claim wherein obtaining the account state comprises obtaining an encrypted account balance.
13. The method of claim 12, wherein the state is computed using additive homomorphism wherein optionally the new account state is computed using additive homomorphism of Elgamal scheme.
14. The method of any preceding claim wherein for an asset, T, the first user account is stored as a tuple: (p", (C1, C2)3.4) where pici is the Elgamal public key, pk for asset T corresponding to the private key, ski for a given user A and (C1,G2)7,:i is the Elgamal ciphertext of the user account balance for asset T.
15. The method of any claims 11-14 wherein the proof comprises: a many-out-of-many proof
16. The method of claim 15, wherein the anonymity set comprises "I" accounts and the many-out-ofmany proof comprises steps of: obtaining, an index user account A in anonymity set (inAccSet){accriaccl,...., acc7}; computing, a new balance for the account using additive homomorphism of Elgamal scheme according to,(C1,C2 -T aG); randomizing the states of all the accounts to form set anonymity set (outAccSet), (E1,E2)T (El + rG, E + rpki), where for each i E [1, ...., (El, EDT is the previous state; and providing inAccSet, outAccSet, knowledge of the user index in the anonymity set and random r.
17. The method of any preceding claim wherein the transfer of assets is from the first user account to the second user account.
18. The method of claim 17 wherein the proof further comprises: a step of confirming that the first account balance is greater than or equal to the transaction amount.
19. The method of any of claims 1-18 wherein the transfer of assets is from the second user account to the first user account.
20. The method of claim 20 further comprising obtaining a balance corresponding to the second user account and confirming the balance is greater than the transaction amount.
21. The method of claims 1 -6, wherein: the anonymity set comprises each node of a Merkle tree, wherein each node corresponds an amount of an asset provided to a user of the private environment to be held in the smart contract of the private environment.
22. The method of claims 1-6 or 21, wherein computing a state for the first user account comprises computing one or more of a note and a nullifier and wherein updating the account state for each account in the anonymity set comprises one or more of computing a new root node hash corresponding to the computation and adding a nullifier to a global nullifier set.
23. The method of claim 22, further comprising computing a commitment for the note, wherein, computing the commitment for the note is based on one of: the transaction amount, a public key of the first user account and optionally an asset identifier; or the transaction amount, a public key of the first user account and an address corresponding to the second user account, wherein computing a nullifier is based on a node corresponding to the transaction.
24. The method of claims 20 -23 wherein each node is dedicated to be spent by an authorized secondary stealth user account.
25. A system for performing the method of any of claims 1 -24.