WO2023167636A1

WO2023167636A1 - Methods and devices for providing privacy-preserving auditable ledger for managing tokens

Info

Publication number: WO2023167636A1
Application number: PCT/SG2023/050111
Authority: WO
Inventors: Shengjiao CAO; Hui Fang; Weitao YANG
Original assignee: Alipay Labs (singapore) Pte. Ltd.
Priority date: 2022-03-01
Filing date: 2023-02-23
Publication date: 2023-09-07

Abstract

Disclosed herein are methods, devices, and apparatuses, including computer programs stored on computer-readable media, for providing a privacy-preserving auditable ledger for managing tokens. One of the methods includes: receiving a transaction submitted by a first user managing the tokens, the transaction containing information regarding a write hash, a read hash, and a counter; determining whether to accept the transaction; in response to a determination to accept the transaction, updating a write hash WH recorded on a blockchain, a read hash RH recorded on the blockchain, and a counter C recorded on the blockchain based on the information contained in the transaction; and in response to a request from a second user, transmitting the updated write hash WH and the updated read hash RH to the second user to facilitate an auditing of the first user.

Description

METHODS AND DEVICES FOR PROVIDING PRIVACY-PRESERVING

AUDITABLE LEDGER FOR MANAGING TOKENS

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This international application is based upon and claims priority to Singapore Application No. 10202202020T, filed on March 1 , 2022, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] The specification relates generally to computer technologies, and more particularly, to methods and devices for providing a privacy-preserving auditable ledger for managing tokens.

BACKGROUND

[0003] Conventionally, a fungible asset is generally composed of units that can be interchanged, and a non-fungible asset may not be interchanged because it has unique properties. Both types of assets may exist in the digital world, and may be bought and sold like their physical counterparts.

[0004] A non-fungible token (NFT) may be a unit of data utilized to certify that an asset is unique and not interchangeable (i.e., the asset is non-fungible). NFTs may be utilized to certify items such as artworks, photos, videos, audio files, transactions, records, real properties, personal properties, and other types of non-fungible assets. For example, while traditional works of art such as paintings and the like are one of a kind, digital artworks can be easily and repeatedly duplicated. Using NFTs, a digital artwork (or other types of assets) may be “tokenized” to create a digital certificate of ownership to certify that the digital artwork is unique and not interchangeable.

[0005] NFTs may be bought and sold, and may be stored on a digital ledger, which may be implemented using a blockchain system. Blockchain systems, also known as distributed ledger systems (DLSs) or consensus systems, may enable participating parties to store data securely and immutably. Blockchain systems may include any DLSs, without referencing any particular use case, and may be used for public, private, and consortium blockchain networks. A public blockchain network is open for all entities to use the system and participate in the consensus process. A private blockchain network is provided for a particular entity, which centrally controls read and write permissions. A consortium blockchain network is provided for a select group of entities, which control the consensus process, and includes an access control layer.

[0006] A blockchain system is implemented using a peer-to-peer (P2P) network, in which the nodes communicate directly with each other, e.g., without the need of a fixed, central server. Each node in the P2P network may initiate communication with another node in the P2P network. A blockchain system maintains one or more blockchains. A blockchain is a data structure for storing data, such as transactions, that may prevent tampering and manipulation of the data by malicious parties.

[0007] Users of a blockchain system may utilize the blockchain system to record various types of information, including, e.g., information regarding NFTs. Currently, many NFT applications have been made available on various blockchain platforms, including, e.g., Ethereum, Binance Smart Chain, and the like. Many types of NFTs have been minted and traded on these blockchain platforms, including, e.g., artworks, music, domain names, trading cards, collectibles, and the like. Other types of assets, including invoices and purchase orders, real properties, personal properties, and the like, may also be represented using non-fungible tokens and traded on such blockchain platforms. However, little work has been done with respect to improving efficiency and protecting privacy of the NFTs recorded on blockchains.

SUMMARY

[0008] In one aspect, a computer-implemented method for providing a privacypreserving auditable ledger for managing tokens includes receiving a transaction submitted by a first user managing the tokens, the transaction containing information regarding a write hash, a read hash, and a counter; determining whether to accept the transaction; in response to a determination to accept the transaction, updating a write hash WH recorded on a blockchain, a read hash RH recorded on the blockchain, and a counter C recorded on the blockchain based on the information contained in the transaction; and in response to a request from a second user, transmitting the updated write hash WH and the updated read hash RH to the second user to facilitate an auditing of the first user.

[0009] In another aspect, a computer-implemented method for providing a privacypreserving auditable ledger for managing tokens includes accessing, by a first user, the privacy-preserving auditable ledger; calculating, by the first user, at least one of: a write hash when the first user writes to the privacy-preserving auditable ledger; and a read hash when the first user reads from the privacy-preserving auditable ledger; submitting, by the first user, a transaction to a blockchain for recordation, the transaction containing information regarding the write hash, the read hash, and a counter; and in response to a request from a second user, providing, by the first user, a snapshot of the privacypreserving auditable ledger to the second user to facilitate an auditing of the first user by the second user.

[0010] In another aspect, a computer-implemented method for providing a privacypreserving auditable ledger for managing tokens includes receiving, from a first user, a snapshot of the privacy-preserving auditable ledger; reading, by a second user, the snapshot; calculating, by the second user, an incremental read hash for having read the snapshot; retrieving, by the second user, a write hash and a read hash recorded on a blockchain, the write hash and the read hash being recorded based on a transaction submitted by the first user, the transaction containing information regarding the write hash, the read hash, and a counter; and verifying, by the second user, whether the first user passes an audit based on the recorded write hash, the recorded read hash, and the calculated incremental read hash.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description, which refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise represented.

[0012] FIG. 1 is a schematic diagram of a blockchain system, according to an embodiment.

[0013] FIG. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment. [0014] FIG. 3 is a flow chart of a method for providing a privacy-preserving auditable ledger for managing tokens, according to an embodiment.

[0015] FIG. 4 is a flow chart of a method for providing a privacy-preserving auditable ledger for managing tokens, according to an embodiment.

[0016] FIG. 5 is a block diagram of an apparatus for providing a privacy-preserving auditable ledger for managing tokens, according to an embodiment.

DETAILED DESCRIPTION

[0017] Embodiments of the specification provide methods and devices for providing a privacy-preserving auditable ledger for managing tokens. The methods and devices may provide a set of operations to be performed by a user (e.g., a custodian entrusted to manage tokens on behalf of other users) each time the user accesses a data record (e.g., a ledger), which may be maintained by the user and not recorded on a blockchain system. The user may access (e.g., read from or write to) the ledger and perform operations such as minting (creating) tokens, burning (invalidating or removing) tokens, or transferring tokens. Each time the user reads from or writes to the ledger, the methods and devices may utilize a multiset hash function to calculate a read hash value or a write hash value. The methods and devices may also utilize a blockchain system to record the calculated read and write hash values. In this manner, the methods and devices can utilize the hash values recorded on the blockchain system to facilitate an audit process that can determine whether the user performed its operations correctly.

[0018] Embodiments disclosed in the specification have one or more technical effects. In some embodiments, the methods and devices may allow the user to maintain a data record (e.g., a ledger) off the blockchain system. This allows the user to implement the ledger in a manner suitable to the user, including, e.g., implementing a plaintext ledger without exposing the ledger to other users participating in the blockchain system. In some embodiments, the methods and devices may utilize a multiset hash function that is defined to be incremental, meaning that when a new member is added to the multiset, the new hash value of the multiset can be calculated incrementally. This allows the methods and devices to quickly calculate the hash values that need to be recorded on the blockchain system, therefore reducing any potential latency that may be introduced. In some embodiments, the methods and devices may require the user to submit proofs to validate the hash values provided for recordation on the blockchain system. This allows the methods and devices to detect and prevent fraudulent attempts by the user or other malicious parties to record invalid hash values. In some embodiments, the methods and devices may provide an audit process that can be performed after any number of operations, making the audit process more efficient because it does not need to be performed after every update. In some embodiments, the methods and devices may only need to record two hash values and a counter on the blockchain system to facilitate the audit process. This allows the methods and devices to preserve user privacy while also reduce storage consumption. In addition, because the amount of data to be recorded on the blockchain system is reduced, the cost associated with recording data on the blockchain system can also be reduced. Furthermore, in some embodiments, the user may record updates to the hash values and the counter recorded on the blockchain system after accessing the ledger a predetermined number of times, further reducing the amount of data that need to be recorded on the blockchain system while still allowing the user to be audited based on data recorded on the blockchain system.

[0019] A blockchain is a data structure that stores data, e.g., transactions, in a way that may prevent tampering and manipulation of the data by malicious parties. The transactions stored in this manner may be immutable and subsequently verified. A blockchain includes one or more blocks. Each block is linked to a previous block immediately before it in the blockchain by including a cryptographic hash of the previous block. Each block also may include a timestamp, its own cryptographic hash, and one or more transactions. The transactions, which generally have already been verified by the nodes of the blockchain system, may be hashed and encoded into a data structure, such as a Merkle tree. In a Merkle tree, data at leaf nodes of the tree is hashed, and all hashes in each branch of the tree may be concatenated at a root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all data in the tree. A hash purporting to be of a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

[0020] A blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, numerous entities, such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, and each of the entities operates at least one node in the public blockchain network. Accordingly, the public blockchain network can be considered a public network with respect to the participating entities. Sometimes, a majority of entities (nodes) must sign every block for the block to be valid and added to the blockchain of the blockchain network. Examples of public blockchain networks include particular peer-to-peer payment networks that leverage a distributed ledger, referred to as blockchain.

[0021] In general, a public blockchain network may support public transactions. A public transaction is shared with all of the nodes in the public blockchain network, and is stored in a global blockchain. A global blockchain is a blockchain replicated across all nodes, and all nodes are in perfect state consensus with respect to the global blockchain. To achieve consensus (e.g., agreement to the addition of a block to a blockchain), a consensus protocol is implemented in the public blockchain network. Examples of consensus protocols include proof-of-work (POW) (e.g., implemented in the some cryptocurrency networks), proof-of-stake (POS), and proof-of-authority (POA).

[0022] In general, a private blockchain network may be provided for a particular entity, which centrally controls read and write permissions. The entity controls which nodes are able to participate in the blockchain network. Consequently, private blockchain networks are generally referred to as permissioned networks that place restrictions on who is allowed to participate in the network, and on their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, a regulatory authority can control admission).

[0023] In general, a consortium blockchain network may be private among the participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (e.g., a financial institution, insurance company). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, each of which operates at least one node in the consortium blockchain network. Accordingly, the consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign every block in order for the block to be valid, and added to the blockchain. In some examples, at least a sub-set of entities (nodes) (e.g., at least 7 entities) must sign every block in order for the block to be valid, and added to the blockchain.

[0024] FIG. 1 illustrates a schematic diagram of a blockchain system 100, according to an embodiment. Referring to FIG. 1 , the blockchain system 100 may include a plurality of nodes, e.g., nodes 102-110, configured to operate on a blockchain 120. The nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each of the nodes 102-1 10 may be a computing device, such as a computer or a computer system, configured to store a copy of the blockchain 120, or may be software running on the computing device, such as a process or an application. Each of the nodes 102-110 may have a unique identifier.

[0025] The blockchain 120 may include a growing list of records in the form of data blocks, such as blocks B1 -B5 in FIG. 1. Each of the blocks B1 -B5 may include a timestamp, a cryptographic hash of a previous block, and data of the present block, which may be transactions such as monetary transactions. For example, as illustrated in FIG. 1 , block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data of block B5. Also, for example, a hashing operation may be performed on the previous block to generate the cryptographic hash of the previous block. The hashing operation may convert inputs of various lengths into cryptographic outputs of a fixed length through a hash algorithm, such as SHA-256.

[0026] The nodes 102-110 may be configured to perform an operation on the blockchain 120. For example, when a node, e.g., the node 102, wants to store new data onto the blockchain 120, that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112. Based on legitimacy of the new block, e.g., validity of its signature and transactions, the other nodes may determine to accept the new block, such that the node 102 and the other nodes may add the new block to their respective copies of the blockchain 120. As this process repeats, more and more blocks of data may be added to the blockchain 120.

[0027] FIG. 2 illustrates a schematic diagram of a computing device 200 for implementing a node, e.g., the node 102 (FIG. 1 ), in a blockchain system, according to an embodiment. Referring to FIG. 2, the computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

[0028] The communication interface 202 may facilitate communications between the computing device 200 and devices implementing other nodes, e.g., nodes 104-110 (FIG. 1 ), in the network. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as an Internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, etc. In some embodiments, the communication interface 202 may include one or more of a Local Area Network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP) based communication device, or other communication devices for wired and/or wireless communications. In some embodiments, the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure.

[0029] The processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled with the memory 206 and is configured to execute instructions stored in the memory 206.

[0030] The memory 206 may store processor-executable instructions and data, such as a copy of the blockchain 120 (FIG. 1 ). The memory 206 may include any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random-access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, or a magnetic or optical disk. When the instructions in the memory 206 are executed by the processor 204, the computing device 200 may perform an operation on the blockchain 120.

[0031] Users of a blockchain system, e.g., the blockchain system 100, may utilize the blockchain system 100 to record various types of information. For example, in some embodiments, users may utilize the blockchain system 100 to record information regarding assets owned, managed, or traded by them. The assets may include, e.g., artworks, music, domain names, trading cards, collectibles, invoices, purchase orders, monetary assets, personal properties, real properties, intellectual properties, contracts, and the like.

[0032] In some embodiments, information regarding an asset may be represented by an identifier and a metadata field. The identifier and the metadata field may form a unit of data represented as, e.g., {ID-. Metadata} , referred to as a token. In some embodiments, the Metadata may include a set of attributes and their corresponding values. For example, if the asset represented is an artwork, the attributes may include, e.g., the name of the artist who created the artwork, the date of creation, a thumbprint of the artwork, an Interplanetary File System (IPFS) link of the artwork, and the like. In some embodiments, the asset represented may be unique and not interchangeable (i.e. , a non-fungible asset). In such embodiments, the token representing the asset may be referred to as a non-fungible token (NFT).

[0033] There may be instances where a user, e.g., the owner of a token, may want to record information about the token on the blockchain system 100 while keeping the plaintext values of ID and Metadata hidden from other users of the blockchain system 100. In some embodiments, to protect the plaintext values of the tokens, owners of the tokens may let a trusted third party manage their tokens off the blockchain system 100, and request the trusted third party to record certain information about their tokens on the blockchain system 100 without revealing any plaintext values associated with the tokens. For illustrated purposes, the trusted third party may be referred to as a clearinghouse or a custodian.

[0034] In some embodiments, the custodian may record the tokens in a ledger off the blockchain system 100 and manage the tokens recorded in the ledger. In some embodiments, the custodian may have a complete view of the plaintext values of tokens the custodian recorded on the ledger, and in some embodiments, the custodian may perform various types of operations on the ledger on behalf of the users, including, e.g., creating (or “minting”) tokens that represent assets owned by users and removing (or “burning”) tokens that are no longer owned by certain users. In such embodiments, a user may access that user’s own tokens through the custodian, but that user may not be able to access other tokens managed by the custodian.

[0035] In some embodiments, to ensure that the custodian is managing the tokens properly, the custodian may be required to record, on the blockchain system 100, information regarding the custodian’s access to the ledge. In such embodiments, the information recorded on the blockchain system 100 may be utilized by an auditor to audit the custodian’s operations. In this manner, the custodian may keep the ledger off the blockchain system 100, allowing the custodian to implement the ledger in a manner suitable to the custodian without exposing the ledger to other users participating in the blockchain system 100, thereby preserving the privacy of the users who entrusted the management of their tokens to the custodian.

[0036] FIG. 3 illustrates a flow chart of a method 300 for providing a privacypreserving auditable ledger for managing tokens, according to an embodiment. For illustrative purposes, a Blockchain, e.g., the blockchain 120 (FIG. 1 ), is depicted in FIG. 3. The Blockchain may be implemented to support various types of users, or parties, including, e.g., banks, financial institutions, businesses, individuals, as well as other types of companies, organizations, and the like. In some embodiments, to protect the tokens owned by various users, the users may let a trusted third party, depicted as the Custodian in FIG. 3, to manage their tokens using a ledger, depicted as the Off-Chain Ledge, stored off the Blockchain. In some embodiments, the Custodian may be required to record information about its access to the Ledge on the Blockchain without revealing any plaintext values associated with the tokens managed by the Custodian. The Ledger may be recorded in various data formats and may be stored in a memory device maintained by the Custodian locally or on one or more storage devices accessible to the Custodian.

[0037] At step 302, the Custodian may access the Ledger as needed. For example, the Custodian may access the Ledger to (1 ) initialize the Ledger, (2) update the Ledger when the Custodian mints a token on behalf of a user, (3) update the Ledger when the Custodian burns a token on behalf of a user, or (4) update the Ledger when a token is transferred from one user account managed by the Custodian to another user account managed by the Custodian.

[0038] In some embodiments, the Custodian may maintain a list of tokens for each user account managed by the Custodian. The Custodian may initialize the Ledger shown below by setting the list listi of each account i =

it manages to an empty list []. For illustrative purposes, each account i may be identified by its public key PK but it is to be understood that other types of identifiers may also be utilized to identify the accounts.

[0039] In some embodiments, the Custodian may set a counter c_t for each account. As will be described in detail below, the counters may be updated along with a global counter C recorded on the Blockchain, and their values may be utilized by a multiset hash function Jf() to calculate hash values when the Custodian writes to or reads from the Ledger. In some embodiments, the Custodian may set the counters to 0 initially, and each time the Custodian reads data from an account recorded on the Ledger, the Custodian may utilize the multiset hash function Jf() to calculate a read hash, and, if necessary, update (e.g., increase) the counter associated with that account to indicate that the Custodian has read the data. Similarly, each time the Custodian writes data to an account recorded on the Ledger, the Custodian may utilize the multiset hash function Jf() to calculate a write hash value.

[0040] In some embodiments, the multiset hash function Jf() may implement a multiset hash function disclosed in Dwaine Clarke et al., “Incremental Multiset Hash Functions and Their Application to Memory Integrity Checking,” Advances in Cryptology- -ASIACRYPT 2003, Lecture Notes in Computer Science, vol. 2894, which is herein incorporated by reference in its entirety. In some embodiments, the multiset hash function Jf() may take a multiset as input and map the multiset to a string (hash) of fixed length. In some embodiments, the multiset hash function Jf() may be incremental, meaning that when a new member is added to the multiset, or when a multiset is added to another multiset, the hash of the resulting multiset can be calculated incrementally. In other words, for multisets A and B, there exists an operator © that can efficiently calculate

[0041] In some embodiments, the multiset hash function Jf() may be utilized at step 304 to calculate a write hash when the Custodian writes to the Ledger. In some embodiments, the Custodian may write to the Ledger by invoking a put(account, updatedJisQ operation, which may (1 ) obtain the value of the global counter C (which may be set to 0 initially), (2) update the Ledger by setting the list listaccount associated with account account to updatedjist and the counter c_account associated with account account to C, and (3) calculate an incremental write hash AWH using the multiset hash function HQ. In some embodiments, the incremental write hash AWH may be calculated as AWH = H (account, updatedjist, (Q, which may be used as the initial value of the write hash WH when the Custodian invokes the put(account, updatedJisQ operation for the first time. Subsequently, the write hash WH may be calculated by incrementing the existing write hash WH by AWH. In other words, the write hash WH may be calculated as WH © = AWH each time the Custodian invokes the put(account, updated_lisQ operation.

[0042] In some embodiments, the multiset hash function HQ may also be utilized at step 304 to calculate a read hash when the Custodian reads from the Ledger. In some embodiments, the Custodian may read from the Ledger by invoking a get(accounQ operation, which may (1 ) obtain the values of list_account and c_account associated with account account from the Ledger, (2) set the global counter C to C = max (C, c_account + 1), and (3) calculate an incremental read hash kRH using the multiset hash function HQ. In some embodiments, the incremental read hash hRH may be calculated as hRH = H (account, list_account, c_account), which may be used as the initial value of the read hash RH when the Custodian invokes the get(accounQ operation for the first time. Subsequently, the read hash RH may be calculated by incrementing the existing read hash RH by ARH. In other words, the read hash RH may be calculated as RH © = ARH each time the Custodian invokes the get(accounQ operation.

[0043] Continuing with the example above, to initialize the Ledger, the Custodian may invoke put(PKi, []) for all i = 1, ... , N . According to the definition of the put operation, at the end of the initialization process, the Ledger may be initialized as shown below, the write hash WH may be set to Z ' i₌₁ H(PK_i, [],0), the read hash RH may be set to its initial value, e.g., 0, and the global counter C may be set to its initial values, e.g., 0.

[0044] Subsequently, the Custodian may update the Ledger when the Custodian creates (or mints) a new token on behalf of a user and assign the new token to that user’s account. For illustrative purposes, suppose that the user already has a list of tokens listi = [token^ ..., token_m] in the user’s account P/Q, and further suppose that the new token minted on behalf of the user is token_m+1, then the Custodian may invoke get(PK?) to get the current list listi of account PK_L from the Ledger and invoke put (PKi, list?) to update the Ledger. The updated Ledger may record the new list of list? = append(/istj, token_m+1) = [tokens ..., token_m, token_m+1] for account PKi and update the counter c_t associated with account PK_t to max (C, c_t + 1) , as illustrated below. Accordingly, at the end of the mint process, the write hash WH may be set to increase by AWH = tH(PKi, list? = [token₁, .... token_m, token_m+1], max (C, c₍ + 1)), the read hash RH may be set to increase by ARH = ft(PK_L, list_t = [token₁, ..., token_m], Ci), and the global counter C may be set to C = max (C, c_t + 1).

[0045] Similarly, the Custodian may update the Ledger when the Custodian removes (or bums) a token from a user’s account, which may happen, e.g., if the user no longer owns the token. For illustrative purposes, suppose that the user already has a list of tokens listi = [token!, ..., token_m] in the user’s account P/Q, and further suppose that the token to be burned is token_x, then the Custodian may invoke get(PKi) to get the current list listi of account PKt from the Ledger and invoke put(PKi, list~) to update the Ledger. The updated Ledger may record the new list of list~ = remove(J.isti, token_x) = [token^, token_x-r, token_x+1, token_m] for account PKi and update the counter c₍ associated with account PKi to max (C, c_t + 1), as illustrated below. At the end of the burn process, the write hash WH may be set to increase by hWH = H(PKi, list~ = [token!, ..., token_x_!, token_x+!, ..., token_m], max (C, c₍ + 1)), the read hash RH may be set to increase by ARH = ft(PK_L, listi = [token^ ... , token_m], c?) , and the global counter C may be set to C = max (C, c_t + 1).

[0046] The Custodian may also update the Ledger when a first user having a first account PK_a transfers a token token_t from the first account PK_a to another account, PK_b, which may be associated with the first user or a different user. To process the transfer operations, the Custodian may invoke get(PK_a) to get the current list list_a of account PK_a from the Ledger and invoke put(PK_a, list} = remove (list_a, token})) to update the Ledger, which may record the new list of list} for account PK_a and update the counter c_a associated with account PK_a to max (C, c_a + 1). At this point of the transfer process, the write hash WH may be set to increase by H(PK_a, list}, max (C, c_a + 1)), the read hash RH may be set to increase by J~C(PK_a, list_a, c_a), and the global counter C may be set to C = max(C, c_a + 1) . To complete the transfer, the Custodian may further invoke get(PK_b) to get the current list list_b of account PK_b from the Ledger. The Custodian may then invoke put(PK_b, list_b = append(/ist_&, to/cenj) to update the Ledger, which may record the new list of list} for account PK_b and update the counter c_b associated with account PK_b to max

c_b + 1), as illustrated below. At the end of the transfer process, the write hash WH may be set to increase by a total of AWH = H(PK_a, list}, max (C, c_a + hash RH may be set to increase by a total and the global counter C may be set to

C" = max (£', c_b + 1).

[0047] In some embodiments, the Custodian may require the first user to provide a signature to authenticate the transfer operation. The first user may provide the signature as a = SIGN(SK_a, m = (PK_a, PK_b, tokens nonce)), where SK_a is the first user’s private key and nonce is an arbitrary number that can be used as a transaction identifier to help prevent replay attacks. In some embodiments, the Custodian may refuse to process a transfer request submitted by a user if the user fails to provide a signature required by the Custodian.

[0048] In some embodiments, the Custodian may update the Ledger (and calculate the hashes) as described above, and at step 306, the Custodian may submit a transaction to the Blockchain to record the operation performed. In some embodiments, the transaction may include information regarding the write hash WH, the read hash RH, and the global counter C, which may be received and recorded on the Blockchain.

[0049] Continuing with the example above, if the Custodian initialized the Ledger at step 302, the Custodian may submit an initialization transaction, e.g., tx = (INITIALIZE, WH, RH, C), to the Blockchain at step 306. Upon receiving the transaction, at step 308, the Blockchain may verify whether the transaction is acceptable, and if so, the Blockchain may record the transaction and the values of the write hash WH, the read hash RH, and the global counter C on the Blockchain.

[0050] In another example, if the Custodian performed a mint operation at step 302 and determined that the write hash WH should be increased by WH = J-C(PK_L, list-', max (C, ct + 1)) , the read hash RH should be increased by RH = PKi. listi. Ci) , and the global counter C should be set to C = max (C, c_t + 1) at step 304, the Custodian may submit a mint transaction, e.g., tx = (MINT, WH, RH, C'), to the Blockchain at step 306. Upon receiving the transaction, at step 308, the Blockchain may verify whether the transaction is acceptable, and if so, the Blockchain may record the transaction and update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain. In some embodiments, the Blockchain may update the value of the write hash WH recorded on the Blockchain by setting the new write hash to WH^new = WH ® WH. Likewise, the Blockchain may update the value of the read hash RH recorded on the Blockchain by setting the new read hash to RH^new = RH © RH. The Blockchain may update the global counter C recorded on the Blockchain by setting it to C.

[0051] In an additional example, if the Custodian performed a burn operation at step 302 and determined that the write hash WH should be increased by WH = (PKi, list max (C, c_L + 1)) , the read hash RH should be increased by RH = 3P(PK_L, list_L, c_L) , and the global counter C should be set to C = max (C, c_t + 1) at step 304, the Custodian may submit a burn transaction, e.g., tx = (BURN, hWH, &RH, C'), to the Blockchain at step 306. Upon receiving the transaction, at step 308, the Blockchain may verify whether the transaction is acceptable, and if so, the Blockchain may record the transaction and update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain.

[0052] In still another example, if the Custodian performed a transfer operation at step 302 and determined that the write hash WH should be increased by AWH =

, the read hash RH should be increased by /\RH = J-C(PK_a, list_a, c_a) ® J-C(PK_b, list_b, c_b), and the global counter C should be set to C" = max (C', c_b + 1) at step 304, the Custodian may submit a transfer transaction, e.g., tx = (TRANSFER, AWH. &RH, C"'), to the Blockchain at step 306. Upon receiving the transaction, at step 308, the Blockchain may verify whether the transaction is acceptable, and if so, the Blockchain may record the transaction and update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain.

[0053] In some embodiments, the Blockchain may verify the transactions submitted based on zero-knowledge proofs provided by the Custodian. Zero-knowledge proofs refer to techniques that allow a prover to prove to a verifier that a statement is true without revealing any information beyond the validity of the statement itself. For example, the Custodian (the prover) may prove to the Blockchain (the verifier) that the Custodian knows a secret input w such that for a public input x, a certain relationship between x and w holds true.

[0054] In some embodiments, the prover and the verifier may agree to implement zero-knowledge proof techniques such as Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) or the like, e.g., as disclosed in Gennaro R., Gentry C., Parno B., Raykova M. (2013) Quadratic Span Programs and Succinct NIZKs without PCPs. In: Johansson T., Nguyen P.Q. (eds) Advances in Cryptology - EUROCRYPT 2013. EUROCRYPT 2013. Lecture Notes in Computer Science, vol 7881 . Springer, which is herein incorporated by reference in its entirety. In some embodiments, the prover and the verifier may agree to implement zk-SNARK that includes a key generator algorithm G. The key generator algorithm G may take a secret parameter A and a program C as input and generate two publicly available keys, a proving key pk and a verification key vk, as output. In some embodiments, the proving key pk and the verification key vk may be generated as public parameters that only need to be generated once in a setup phase for a given program C(x, w) , where C(x, w) returns true if the owner provides the correct values of x and w. One of ordinary skill in the art will understand that the setup phase may be executed by a trusted party, or by multiple independent parties collaboratively using a multi-party computation.

[0055] In some embodiments, zk-SNARK may also include a prover algorithm P and a verifier algorithm V. In some embodiments, the prover algorithm P may take the proving key pk, the public input x, and the secret input w as input and generate a zeroknowledge proof n = P(p/c, x, w) that can prove to the verifier that the owner knows the secret input w and that the secret input w makes C(x, w) == true. The verifier algorithm V may take the verification key vk , the public input x, and the proof n as input and compute V(yk, x, n). In some embodiments, V(yk, x, n) may be defined to return true if the proof n is acceptable, which means that the owner knows the secret input w and that the secret input w makes C(x, w) == true. Otherwise, if the proof n is unacceptable, the verifier algorithm V(yk, x, n) may return false.

[0056] Continuing with the example above, in some embodiments, the Custodian may include a zero-knowledge proof n with a mint transaction tx = (MINT, hWH, &RH, C', n) , where the Custodian may set the public input x to x = (AIVH, &RH, C, C') and the secret input

noted that the plaintext values of PK_L, listi, listi , token_m+1, and c_t are not disclosed to the Blockchain to preserve privacy.

[0057] In some embodiments, the Custodian may set the value of x by concatenating (AIV/7, A/?/7, C, C') together and set the value of w by concatenating (PK_L, listi, list-', token_m+1, c_L) together. The Custodian may also define C(x, w) such that C(x, w) returns true if and only if:

A/?H = H(P K_b listi, cd,

LWH = tK{PKi, listt, C), listi' ⁼ append(/istj, token_m+1), and

C' = max (C, Ci + 1).

[0058] In this manner, the Custodian may generate the proof n using the secret and public inputs as well as the proving key to prove to the Blockchain that the Custodian is in possession of the secret input w that makes the above conditions true. For example, if the relationship between the public input x and the secret input w can be defined so that C(x,w), then a proving key pk and a verification key vk may be setup, and the Custodian may generate the proof n using the prover algorithm P to prove to the Blockchain that

, list? = append(/istj, token_m+1), and C' = max (C, c_L + 1).

[0059] In some embodiments, the Blockchain may verify the proof n using the public input x and the verification key at step 308. In some embodiments, a consensus may need to be reached for the Blockchain to accept the proof n as having been properly verified. In some embodiments, the Blockchain may carry out the verification using one or more smart contracts executing on the Blockchain. Smart contracts are computer protocols implemented in the form of computer code that are incorporated into the blockchain, to facilitate, verify, or enforce the negotiation or performance of agreed terms or conditions. For example, users of the Blockchain may program agreed terms into a smart contract using a programming language, such as C++, Java, Solidity, Python, etc., and when the terms are met, the smart contract may be automatically executed on the Blockchain. Also for example, the smart contract may include a plurality of subroutines or functions, each of which may be a sequence of program instructions that performs a specific task. The smart contract may be operational code that is fully or partially executed without human interaction. In some embodiments, the Blockchain, through one or more smart contracts executing on the Blockchain, may receive as input the proof it generated by the Custodian. In this manner, the Blockchain, through one or more smart contracts executing thereon, may perform the verification process.

[0060] Continuing with the example above, the Blockchain may verify the proof using the verifier algorithm V to determine whether V(vk, x, n) returns true, which means the Custodian knows the secret input w and that the secret input w makes C(x,w) == true. Otherwise, if the proof n is unacceptable, the verifier algorithm 7(V/C, X, TT) may return false. In this manner, if C(x, w) == true, the Blockchain may accept the conditions ARH = J-C(PKi, listi, c?) , &WH = J~C(PK_L, list? , C') , list? = append(/istj, token_m+1) , and C = max (C, c_t + 1) as true, which may indicate that the Custodian has correctly processed the mint operation and correctly calculated the incremental values for the read and write hashes. Therefore, if the equation holds true, the Blockchain may accept and record the mint transaction submitted by the Custodian. The Blockchain may also update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain. On the other hand, if the equation does not hold true, the Blockchain may refuse to accept the mint transaction submitted by the Custodian.

[0061] It is to be understood that the equation, the proving key, and the verification key described above are merely presented as examples and are not meant to be limiting. It is contemplated that the relationship between the public input x and the secret input w can be defined using various types of equations, and that the proving key and the verification key may be defined accordingly based on the relationship between the public input x and the secret input w. In some embodiments, the proof may also be translated into sigma protocols, which can be transformed into non-interactive zero-knowledge proofs of knowledge using Fiat-Shamir transform.

[0062] In some embodiments, the Custodian may also include a zero-knowledge proof n with a burn transaction tx = (BURN, &WH, &RH, C'. TI), where the Custodian may set the public input x to x = (&WH, &RH, C, C') and the secret input w to w = (PKi, listi, list~ , token_x, Ci) . The Custodian may also define C(x, w) such that C(x, w) returns true if and only if:

[0063] In this manner, the Custodian may generate the proof n using the secret and public inputs as well as the proving key to prove to the Blockchain that the Custodian is in possession of the secret input w that makes the above conditions true.

[0064] The Blockchain may verify the proof n included in the burn transaction in a manner similar to that described above. For example, the Blockchain may verify the proof using the verifier algorithm V to determine whether V(yk, x, n) returns true, which means the Custodian knows the secret input w and that the secret input w makes C(x,w) == true. Otherwise, if the proof n is unacceptable, the verifier algorithm K(v/c, %, rr) may return false. In this manner, if C(x, w) == true, the Blockchain may accept the conditions RH = J-C(PKi, listi, Ci), WH = J-C(PKi, list~, C'), list~ = remove (listt, token_x), and C = max (C, Ci + 1) as true, which may indicate that the Custodian has correctly processed the burn operation and correctly calculated the incremental values for the read and write hashes. Therefore, if the equation holds true, the Blockchain may accept and record the burn transaction submitted by the Custodian. The Blockchain may also update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain. On the other hand, if the equation does not hold true, the Blockchain may refuse to accept the burn transaction submitted by the Custodian.

[0065] In some embodiments, the Custodian may also include a zero-knowledge proof 7r with a transfer transaction. In some embodiments, the transfer transaction may include additional information, such as the values of both counters C and C" (described above), which may be utilized to help verify the correctness of the transfer transaction. In some embodiments, the transfer transaction may further include a transfer_id, which may be used to identify the transfer and prevent replay attacks. Such transfer transactions may therefore be denoted as tx =

[0066] Furthermore, in some embodiments, the Custodian may require the user making the transfer to sign the transfer. As described above, the user may provide a signature a = SIGN[SK_a, (PK_a, PK_b, token_i, nonce')^>) signed using the user’s private key SK_a, where PK_a is the identifier of the transferring account, PK_b is the identifier of the receiving account, token is the token being transferred, and nonce is an arbitrary number that can be used as transfer_id to help prevent replay attacks.

[0067] In some embodiments, to prove the correctness of the transfer transaction tx = (TRANSFER, kWH, kRH, C , C", trans fer_id, n) , the Custodian may set the public input x to x = (kWH, kRH, C, C, C”) and the secret input w to w = (PK_a, list_a, c_a, PK_b, list_b, c_b, token , cr). The Custodian may also define C(x, w) such that C(x, w) returns true if and only if:

[0068] In this manner, the Custodian may generate the proof it using the secret and public inputs as well as the proving key to prove to the Blockchain that the Custodian is in possession of the secret input w that makes the above conditions true.

[0069] The Blockchain may verify the proof n included in the transfer transaction in a manner similar to that described above. For example, the Blockchain may verify the proof using the verifier algorithm V to determine whether V(yk, x, n) returns true, which means the Custodian knows the secret input w and that the secret input w makes C(x, w) == true . Otherwise, if the proof n is unacceptable, the verifier algorithm F(V/C, X, 7T) may return false. In this manner, if C(x, w) == true, the Blockchain may accept the conditions

EWH = , list^ = remove (list_a, token) , list_b =

append(/ist_&, token), C' = max (C, c_a + 1), and C" = max (£', c_b + 1) as true, which may indicate that the Custodian has correctly processed the transfer operation and correctly calculated the incremental values for the read and write hashes. Therefore, if the equation holds true, the Blockchain may accept and record the transfer transaction submitted by the Custodian. The Blockchain may also update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain. On the other hand, if the equation does not hold true, the Blockchain may refuse to accept the transfer transaction submitted by the Custodian.

[0070] In some embodiments, the Custodian may further prove to the Blockchain to that the Custodian has the user’s signature on a transfer request, which may in turn prove that the Custodian did not forge the request. For example, the Custodian may include an additional condition, e.g., VERIFY(PK_a, a, (PK_a, PK_b, token, transf erjd)^ = true, for C(x, w) == true to be true. It is noted that the VERIFYQ function refers to a digital signature verification scheme that can be used to verify a digital signature signed using the SIGNQ function mentioned above.

[0071 ] In some embodiments, the Custodian may follow the steps described above when the Custodian accesses the Ledger to (1 ) initialize the Ledger, (2) update the Ledger when the Custodian mints a token on behalf of a user, (3) update the Ledger when the Custodian burns a token on behalf of a user, or (4) update the Ledger when a token is transferred from one user account managed by the Custodian to another user account managed by the Custodian. In this manner, the Custodian may read from and write to the Ledger off the Blockchain, but every time the Custodian reads from or writes to the Ledger, the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain for the Custodian may be updated. In this manner, the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain can be utilized by an Auditor to audit the operations of the Custodian.

[0072] Two use cases are described below to illustrate the audit process. In the first use case, suppose that the Custodian properly performed the following operations in sequence: (0) initialize /V accounts, (1 ) mint a new token token_new on behalf of a user who has an account identified as PK_a, (2) transfer the token token_new from account PK_a to account PK_b, and (3) burn token_new from account PK_b (e.g., when the user who owns account PK_b later sells or otherwise destroys token_new). Using the processes described above, at the end of operation (0), the Custodian may record the following on the Ledger:

[0073] The Custodian may also submit an initialization transaction, and upon verification, the Blockchain may record:

C° = 0 on the Blockchain.

[0074] Subsequently, at the end of operation (1 ), mint a new token token_new on behalf of a user who has an account identified as PK_a, the Custodian may record the following on the Ledger:

[0075] The Custodian may also submit a mint transaction, and upon verification, the Blockchain may update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain to:

[0076] Subsequently, at the end of operation (2), transfer the token token_new from account PK_a to account PK_b, the Custodian may record the following on the Ledger:

[0077] The Custodian may also submit a transfer transaction, and upon verification, the Blockchain may update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain to:

WH² =

[0078] Subsequently, at the end of operation (3), burn token_new from account PK_b, the Custodian may record the following on the Ledger:

[0079] The Custodian may also submit a burn transaction, and upon verification, the Blockchain may update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain to:

WH³

® H(PK_b, 0,3),

RH³ =

J~C(PK_a, [],0) © J~C(PK_a, [token_new],i) © J~C(PK_b, [],0) © J~C(PK_b, [token_new],2), and C³ = 3.

[0080] Suppose that the Auditor now decides to audit the Custodian. At step 310, the Auditor may request the Custodian to provide a snapshot of the current Ledger. At step 312, the Custodian may provide the requested snapshot, which may include the current list and counter associated with each account managed by the Custodian. In some embodiments, the Custodian may provide the requested snapshot in an encrypted form, which may be decrypted by the Auditor upon receipt. At step 314, the Auditor may read the snapshot by invoking get(PKi) for all i =

identified in the snapshot. The Auditor may also calculate an incremental read hash &RH^audlt for having invoked get(PKi) for all i = 1, ..., N . According to the definition of the get operation, the incremental read hash &RH^audlt may be calculated as:

[0081] At step 316, the Auditor may retrieve the most recent values of the write hash WH and the read hash RH recorded on the Blockchain. Continuing with the use case described above, the most recent value of the write hash is WH³ and the most recent value of the read hash is RH³. The Auditor may receive the write hash WH³ and the read hash RH³ from the Blockchain at step 318, and at step 320, the Auditor may verify whether WH³ = RH³® &RH^audlt. In this use case, WH³ = RH³® &RH^audlt, so the Auditor may determine that the Custodian has passed the audit. Otherwise, as will be shown in the second use case below, if WH³ #= RH³® &RH^audlt , the Auditor may determine that the Custodian has failed the audit.

[0082] In the second use case, suppose again that the Custodian performed the following operations in sequence: (0) initialize N accounts, (1 ) mint a new token token^ on behalf of a user who has an account identified as PK_a, (2) transfer the token token_new from account PK_a to account PK_b, and (3) burn token_new from account PK_b. And for illustrative purposes, further suppose that the Custodian performed the operations (0) through (2) in the same manner as described in the first use case. However, in performing operation (3), instead of getting [token_new] as the token list for account PK_b , the Custodian incorrectly got [token_x , token_new] as the token list for account PK_b. Therefore, at the end of operation (3), after removing token_new from [token_x , token_new] , the Custodian may record the following on the Ledger: Account PKi ... PK_& ... PKN

List [] [] [token_x ] []

Counter 0 2 3 0

[0083] The Custodian may then submit a burn transaction, and upon verification, the Blockchain may update the values of the write hash WH, the read hash RH, and the global counter C recorded on the Blockchain to:

[0084] Suppose that the Auditor now decides to audit the Custodian. The Auditor may follow the same steps 310 through 314 as described above and calculate an incremental read hash &RH^audlt for having invoked get(PKi) for all i = 1, ..., N . According to the definition of the get operation, the incremental read hash &RH^audlt may be calculated as:

[0085] The Auditor may continue to follow the same steps 316 through 320 to verify whether WH³ = RH³® &RH^audlt. In this case, after removing the equivalent hash values on both sides of the equation, J-c(PK_b, [token_new],2) still remains on the left hand side and Because the Auditor may

determine that the Custodian has failed the audit. In some embodiments, the Auditor may impose sanctions and/or indicate to the Blockchain that transactions submitted by the Custodian should be rejected.

[0086] It is to be understood that the two use cases depicted above are merely presented as examples and are not meant to be limiting. It is to be understood that the types of operations performed by the Custodian, and the number of such operations performed, may be different from the use cases depicted above, but the most recent write hash WH recorded on the Blockchain should always equal to the most recent read hash RH © the incremental read hash RH^audlt calculated by the Auditor. In other words, WH = RH ® RH^audlt should always be true. In this manner, the Auditor can use the audit process described above to detect and prevent substitution (e.g., using a substituted value instead of a value written to the Ledger) and replay (e.g., using a stale value instead of the value that is most recently written to the Ledger) attacks by the Custodian or other malicious parties.

[0087] It is also to be understood that the audit process described above can be performed after any number of operations, making the audit process more efficient because it no longer needs to be performed after every update. Also, it is noted that only the write hash WH, the read hash RH, and the global counter C need to be recorded on the Blockchain to facilitate the audit process, effectively preserving user privacy and reducing storage consumption. In addition, because the amount of data to be recorded on the Blockchain is reduced, the cost associated with recording data on the Blockchain can also be reduced. Furthermore, in some embodiments, users may agree to allow the Custodian to record updates to the write hash WH, the read hash RH, and the global counter C on the Blockchain after accessing the ledger a predetermined number of times, further reducing the amount of data that need to be recorded on the Blockchain while still allowing the Auditor to carry out meaningful audit based on data recorded on the Blockchain.

[0088] FIG. 4 illustrates a flow chart of a method 400 for providing a privacypreserving auditable ledger for managing tokens, according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system, e.g., the nodes 102-1 10 in the blockchain system 100 (FIG. 1 ). The nodes 102-110 in the blockchain system 100 may perform operations on a blockchain, e.g., the blockchain 120 (FIG. 1 ). The blockchain 120 may be implemented as the Blockchain in the examples described above.

[0089] At step 402, a node, e.g., the node 102, may receive a transaction submitted by a first user. The first user may be, e.g., the Custodian (FIG. 3) entrusted to manage the tokens, and the transaction submitted by the first user may include an initialization transaction, a mint transaction, a burn transaction, or a transfer transaction. In some embodiments, the transaction may include information regarding a write hash WH, a read hash RH, and a global counter C. In some embodiments, the first user may provide the information regarding the write hash WH, the read hash RH, and the global counter C for recordation on the blockchain 120 to facilitate an audit process.

[0090] In some embodiments, the first user may submit the transaction after performing a corresponding operation off the blockchain 120. For example, the first user may submit an initialization transaction after performing an initialization operation to initialize a data record, e.g., the Ledger (FIG. 3), maintained off the blockchain 120. The first user may also submit a mint transaction after performing a mint operation. Likewise, the first user may submit a burn transaction after performing a burn operation and submit a transfer transaction after performing a transfer operation.

[0091] As described above, the first user may perform an initialization operation by invoking put(PKi, []) for all i = 1, ... , N. The first user may perform a mint operation by invoking get(PKi) and put(PK_i, listi'^>). The first user may perform a burn operation by invoking get(PKi) and put(PKi, list~) . The first user may also perform a transfer operation by invoking get(PK_a~), put(PK_a, lista = remove (list_a, tokeni}), get(PK_b), and put(PK_b, list_b = append(/ist_&, tokens)) . In some embodiments, the put (account, update d_list) operation, when invoked, may (1 ) obtain the value of a global counter C (which may be set to 0 initially), (2) update the data record, e.g., the Ledger, by setting the list list_account associated with account account to updated_list and the counter c_account associated with account account to C, and (3) calculate an incremental write hash hWH using the multiset hash function Jf() . The get(account) operation, when invoked, may (1 ) obtain the values of list_account and c_account associated with account account from the data record, (2) set the global counter C to C = max (C, c_account + 1), and (3) calculate an incremental read hash kRH using the multiset hash function Jf().

[0092] In some embodiments, the first user may submit an initialization transaction, e.g., tx = (INITIALIZE, WH, RH, C) as described above, after initializing the data record maintained off the blockchain 120. Upon receiving the initialization transaction at step 402, the node 102 may verify, at step 404, whether to accept the transaction. In some embodiments, the blockchain system 100 may require all authorized custodians to register with the blockchain system 100. In such embodiments, the node 102 may verify whether to accept the transaction based on whether the transaction was submitted by an authorized custodian. If the node 102 determines that the transaction was submitted by an authorized custodian, the node 102 may, at step 406, record the initialization transaction and the values of WH, RH, and C on the blockchain 120.

[0093] In some embodiments, the first user may submit a mint transaction, e.g., tx = (MINT, AWH, &RH, C'} as described above, after performing a mint operation off the blockchain 120. In some embodiments, the first user may also include a zero-knowledge proof n with the mint transaction tx = (MINT, hWH, &RH, C',n). Similarly, the first user may submit a burn transaction, e.g., tx = (BURN, AIVH, ARH, C') as described above, after performing a burn operation off the blockchain 120. In some embodiments, the first user may also include a zero-knowledge proof n with the burn transaction tx = (BURN, AIVH, ARH, C , it). Furthermore, the first user may submit a transfer transaction, tx = (TRANSFER, AWH. &RH, C") as described above, after performing a transfer operation off the blockchain 120. In some embodiments, the first user may also include additional information, including, e.g., a zero-knowledge proof n, values of counters C and C" , and an identifier transfer_id , with the transfer transaction tx = (TRANSFER, AWH, &RH, C , C" , trans f er _id, TI).

[0094] In some embodiments, if the transaction received at step 402 includes a zero-knowledge proof s, the node 102 may verify, at step 404, whether the proof n is acceptable. In some embodiments, the node 102 may verify whether the proof n is acceptable using the verification process described above. If the node 102 determines that the proof it is not acceptable, the node 102 may refuse to accept the transaction. On the other hand, if the node 102 determines that the proof it is acceptable (or if the node 102 does not require the first user to provide a zero-knowledge proof id), the node 102 may, at step 406, record the transaction and update the values of WH , RH , and C recorded on the blockchain 120 based the values of AWH, ARH, and C contained in the transaction, respectively. For example, in some embodiments, the node 102 may update the value of WH recorded on the blockchain 120 by incrementing the value of the most recent WH by AVER, i.e., setting the new write hash to WH^new = WH © AVER. Likewise, the node 102 may update the value of RH recorded on the blockchain 120 by incrementing the value of the most recent RH by ARH, i.e., setting the new read hash to RH^new = RH © &RH. The node 102 may also update the global counter C recorded on the blockchain 120 by setting it to C' for mint or burn transactions, or C" for transfer transaction.

[0095] At step 408, the node 102 may transmit the most recent (updated) values of WH, RH, and C recorded on the blockchain 120 to a second user upon receiving a request from the second user. The second user may be, e.g., the Auditor (FIG. 3), who may use the most recent values of WH, RH, and C recorded on the blockchain 120 to verify if the first user has updated the data record correctly. In some embodiments, the second user may invoke get(PKi) for all i =

and calculate an incremental read hash &RH^audlt for having invoked get(PKi) for all i = 1,

The second user may then verify whether the most recent value of WH recorded on the blockchain 120 equals to the most recent value otRH recorded on the blockchain 120 incremented by the incremental read hash &RH^audit, i.e., whether WH = RH © &RH^audit. If WH = RH © &RH^audit, the second user may determine that the first user has updated the data record correctly. On the other hand, if WH³ #= RH³@ &RH^audlt, the second user may determine that the first user has failed the audit. In some embodiments, the second user may impose sanctions and/or indicate to the node 102 that transactions submitted by the first user should be rejected. In some embodiments, the node 102 may record an entry on the blockchain 120 indicating the failure. The node 102 may also temporarily stop accepting further transactions submitted by the first user until the failure has been properly addressed.

[0096] It is to be understood that while the examples above depicted auditing of a custodian’s handling of tokens managed by the custodian, such depictions are merely provided as examples and are not meant to be limiting. The method 400 may be utilized to provide privacy-preserving audit processes for other types of asset management in similar manners as described above. Furthermore, it is to be understood that the declarations of the functions, variables, and transactions described above are merely presented as examples and are not meant to be limiting. For instance, the examples above used the public key PKi associated with each account i to identify the account, but it is to be understood that other types of identifiers may also be utilized to identify the accounts.

[0097] FIG. 5 is a block diagram of an apparatus 500 for providing a privacypreserving auditable ledger for managing tokens, according to an embodiment. The apparatus 500 may be an implementation of a software process, and may correspond to the method 400 (FIG. 4). Referring to FIG. 5, the apparatus 500 may include a receiving module 502, a verification module 504, a recording module 506, and a transmitting module 508.

[0098] The receiving module 502 may receive a transaction submitted by a first user. In some embodiments, the transaction submitted may include an initialization transaction, a mint transaction, a burn transaction, or a transfer transaction. In some embodiments, the transaction may include information regarding a write hash WH, a read hash RH, and a global counter C. In some embodiments, the receiving module 502 may provide the received transaction to the verification module 504 for verification.

[0099] The verification module 504 may verify whether to accept the transaction. In some embodiments, the verification module 504 may verify whether to accept the transaction based on whether the transaction was submitted by an authorized user. In some embodiments, the verification module 504 may verify whether to accept the transaction based on a proof included in the transaction. If the verification module 504 determines that the proof is unacceptable, the verification module 504 may request the transmitting module 508 to transmit an error and/or record an indicator indicating that the transaction is invalid. Otherwise, the verification module 504 may request the recording module 506 to record the transaction and update the values of WH, RH, and C based on the information included in the transaction.

[00100] In some embodiments, the receiving module 502 may also receive a request from a second user. The second user may request the values of the most recent WH, RH, and C recorded by the recording module 506. Upon receiving the request, the receiving module 502 may request the transmitting module 508 to transmit the most recent values of WH, RH, and C recorded by the recording module 506 to the second user. In this manner, the second user may use the values of WH, RH, and C to audit the operations performed by the first user, as described above.

[00101 ] Each of the above-described modules may be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above described modules may be implemented using a processor executing instructions stored in a memory. Also, for example, each the above described modules may be implemented with one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components, for performing the described methods. Further for example, each of the above described modules may be implemented by using a computer chip or an entity, or implemented by using a product having a certain function. In one embodiment, the apparatus 500 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[00102] For an implementation process of functions and roles of each module in the apparatus 500, references can be made to corresponding steps in the abovedescribed methods. Details are omitted here for simplicity.

[00103] In some embodiments, a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to carry out the above-described methods.

[00104] The computer-readable storage medium may be a tangible device that can store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.

[00105] The computer-readable program instructions for carrying out the above-described methods may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. The computer-readable program instructions may execute entirely on a computing device as a stand-alone software package, or partly on a first computing device and partly on a second computing device remote from the first computing device. In the latter scenario, the second, remote computing device may be connected to the first computing device through any type of network, including a local area network (LAN) or a wide area network (WAN).

[00106] The computer-readable program instructions may be provided to a processor of a general-purpose or 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 above-described methods.

[00107] The flow charts and diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the specification. In this regard, a block in the flow charts or diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing specific functions. It should also be noted that, in some alternative implementations, the functions noted in the blocks 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 diagrams and/or flow charts, and combinations of blocks in the diagrams and flow charts, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[00108] It is appreciated that certain features of the specification, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the specification, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the specification. Certain features described in the context of various embodiments are not essential features of those embodiments, unless noted as such.

[00109] Although the specification has been described in conjunction with specific embodiments, many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the following claims embrace all such alternatives, modifications and variations that fall within the terms of the claims.

Claims

What Is Claimed Is:

1. A computer-implemented method for providing a privacy-preserving auditable ledger for managing tokens, the method comprising: receiving a transaction submitted by a first user managing the tokens, the transaction containing information regarding a write hash, a read hash, and a counter; determining whether to accept the transaction; in response to a determination to accept the transaction, updating a write hash WH recorded on a blockchain, a read hash RH recorded on the blockchain, and a counter C recorded on the blockchain based on the information contained in the transaction; and in response to a request from a second user, transmitting the updated write hash WH and the updated read hash RH to the second user to facilitate an auditing of the first user.

2. A computer-implemented method for providing a privacy-preserving auditable ledger for managing tokens, the method comprising: accessing, by a first user, the privacy-preserving auditable ledger; calculating, by the first user, at least one of: a write hash when the first user writes to the privacy-preserving auditable ledger; and a read hash when the first user reads from the privacy-preserving auditable ledger; submitting, by the first user, a transaction to a blockchain for recordation, the transaction containing information regarding the write hash, the read hash, and a counter; and in response to a request from a second user, providing, by the first user, a snapshot of the privacy-preserving auditable ledger to the second user to facilitate an auditing of the first user by the second user.

3. A computer-implemented method for providing a privacy-preserving auditable ledger for managing tokens, the method comprising: receiving, from a first user, a snapshot of the privacy-preserving auditable ledger; reading, by a second user, the snapshot; calculating, by the second user, an incremental read hash for having read the snapshot; retrieving, by the second user, a write hash and a read hash recorded on a blockchain, the write hash and the read hash being recorded based on a transaction submitted by the first user, the transaction containing information regarding the write hash, the read hash, and a counter; and verifying, by the second user, whether the first user passes an audit based on the recorded write hash, the recorded read hash, and the calculated incremental read hash.

4. The method of claim 1 , wherein the method is performed by one or more nodes in a blockchain system implemented to operate the blockchain.

5. The method of any preceding claim, wherein the transaction further comprises a proof prepared by the first user, and determining whether to accept the transaction further comprises: determining whether the proof is acceptable.

6. The method of claim 5, wherein the proof is a zero-knowledge proof.

7. The method of any preceding claim, wherein the information regarding the counter contained in the transaction is configured to facilitate calculations of the write hash and the read hash.

8. The method of any preceding claim, wherein the information contained in the transaction comprises an incremental write hash WH calculated utilizing an incremental multiset hash function and an incremental read hash RH calculated utilizing the incremental multiset hash function.

9. The method of claim 8, wherein the incremental multiset hash function calculates the incremental write hash WH by taking as input information comprising an identifier of an account associated with the transaction and an updated list of tokens to be recorded for the account associated with the transaction.

10. The method of claim 8, wherein the incremental multiset hash function calculates the incremental read hash RH by taking as input information comprising an identifier of an account associated with the transaction and a current list of tokens recorded for the account associated with the transaction.

11 . The method of claim 8, wherein the updating the write hash WH recorded on the blockchain comprises incrementing the write hash WH recorded on the blockchain by the incremental write hash WH , and the updating the read hash RH recorded on the blockchain comprises incrementing the read hash RH recorded on the blockchain by the incremental read hash RH.

12. The method of any preceding claim, wherein the tokens comprise at least one non- fungible token.

13. The method of any one of claims 1 -3, wherein the write hash and the read hash are calculated based on an account managed by the first user, the tokens associated with the account managed by the first user, and a counter configured to facilitate calculations of the write hash and the read hash.

14. The method of any one of claims 1 and 3, wherein the write hash is calculated utilizing a multiset hash function when the first user writes to the privacy-preserving auditable ledger, the read hash is calculated utilizing the multiset hash function when the first user reads from the privacy-preserving auditable ledger, and the counter is configured to facilitate calculations of the write hash and the read hash.

15. The method of any one of claims 2 and 3, wherein the snapshot comprises an account managed by the first user, the tokens associated with the account managed by the first user, and the counter.

16. A device for providing a privacy-preserving auditable ledger for managing tokens, comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1 to 15.

17. An apparatus for providing a privacy-preserving auditable ledger for managing tokens, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 15.

18. A non-transitory computer-readable medium having stored therein instructions that, when executed by a processor of a device, cause the device to perform the method of any of claims 1 to 15.