Computer-implemented method, computer system, and computer program for privacy-preserving auditable accounting (privacy-preserving auditable accounting)

Abstract

To solve the problem in which decentralization raises privacy concerns that, by design, anyone accessible to a ledger can read the history of users' transactions.SOLUTION: The invention provides an approach for privacy-preserving auditable accounts on blockchain networks. The approach may include encoding tokens associated with a blockchain network. The encoding may include data relating to the current epoch, where an epoch is a specific time range. The tokens may be received from a user for inspection by an auditing entity. The approach may include performing an audit check on the encoded tokens. If the audit check succeeds, the auditing entity may submit an audit transaction verifying that the tokens were generated in the current epoch and making the tokens auditable for the next epoch.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates generally to the field of blockchain transaction processing, and more particularly to auditing blockchain transactions while maintaining the privacy of users' transactions. [Background technology]

[0002] A blockchain is a distributed ledger consisting of multiple nodes in a peer-to-peer network. A blockchain is a decentralized system because each node has an identical copy of the ledger and there is no central authority controlling the operation of the blockchain. A block in a blockchain is a "transaction" that is recorded by adding an additional block to a chain of blocks linked together by cryptographic means. Each block in a blockchain contains a hash of the previous block, a timestamp, and transaction data up to the genesis block at the beginning of the blockchain. Adding a block to a blockchain requires nodes to follow a consensus protocol (e.g., proof of work, proof of stake, etc.) to validate the new block.

[0003] Blockchains can be permissioned or permissionless. A permissioned blockchain is a private blockchain that must be validated in some fashion before nodes can access or make changes to the blockchain. In some permissioned blockchains, parties within the blockchain may be restricted from accessing parts of the blockchain or from participating in bilateral or multilateral transactions. Permissionless blockchains are typically open source in nature, allowing anyone with an internet connection to submit transactions and participate in the execution of the consensus protocol. Summary of the Invention [Problem to be solved by the invention]

[0004] Decentralization raises privacy concerns as, by design, anyone with access to the ledger can read a user's transaction history. [Means for solving the problem]

[0005] Embodiments of the present disclosure include computer-implemented methods, systems, and computer programs for privacy-preserving auditable accounting. Embodiments may include generating at least one token, where the at least one token is encoded with an owner, a type, a value, a current epoch, transferability, a seed, and an r value, where the epoch is a particular time range. Furthermore, embodiments may include generating a zero-knowledge proof, where the zero-knowledge proof indicates that an owner of the at least one token is a registered user of the blockchain network. Furthermore, embodiments may include assembling a first transaction message, where the transaction message includes the at least one token, the zero-knowledge proof, and an issuer's public key. Also, embodiments may include signing the first transaction message, where the signature is based on a private key associated with the issuer's public key, and broadcasting the transaction message to the blockchain network.

[0006] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]

[0007] The drawings included in this disclosure are incorporated in and constitute a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.

[0008] [Figure 1A] 1 illustrates an exemplary blockchain architecture, generally designated 100, according to an embodiment of the present disclosure.

[0009] [Figure 1B] 1 illustrates a blockchain transaction flow, generally designated 150, according to an embodiment of the present disclosure.

[0010] [Figure 2] 2 illustrates an exemplary system for privacy-preserving and auditable blockchain transactions, generally designated 200, according to an embodiment of the present disclosure.

[0011] [Figure 3] 3 illustrates a flowchart of an exemplary method for privacy-preserving and auditable blockchain transactions, generally designated 300, according to an embodiment of the present disclosure.

[0012] [Figure 4A] 1 illustrates a cloud computing environment according to an embodiment of the present disclosure.

[0013] [Figure 4B] 1 illustrates an abstraction model layer according to an embodiment of the present disclosure.

[0014] [Figure 5] 5 illustrates a high-level block diagram of an exemplary computer system, generally designated 501, that may be used to implement one or more of the methods, tools, and modules, and any associated functionality, described herein, in accordance with embodiments of the present disclosure.

[0015] While the embodiments described herein are susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0016] Aspects of the present disclosure relate generally to the field of maintaining privacy in blockchain transactions, and more particularly to privacy-preserving token exchanges via blockchains using accounting services. Distributed ledger technology ("DLT") has created disintermediated token systems. These systems allow end users to exchange tokens without a central authority. The consensus mechanisms underlying DLT ensure the accuracy of the data in the ledger and the finality of the exchange. However, decentralization, by design, introduces privacy concerns, as anyone with access to the ledger can read a user's transaction history. This has led to an active area of ​​research focused on obfuscating user transactions without sacrificing verifiability. That is, the nodes maintaining the ledger can still validate transactions even when their contents are hidden.

[0017] In one embodiment, zero-knowledge proofs may be used to hide transaction content. Zero-knowledge proofs provide a way to achieve the goal of verifying transactions while hiding the transaction content from unauthorized viewers on the blockchain network. Hiding the transaction content must not prevent authorized parties from auditing and monitoring the transaction. For example, anti-money laundering regulations require banks to inspect suspicious transactions and, if necessary, prevent them from completing.

[0018] Embodiments of the present invention may provide an approach that allows users to transact privately on a blockchain network while also allowing auditors or monitoring agents to perform accounting tasks. More specifically, authorized parties can learn the amount of tokens a user will receive during an epoch. If a user does not declare all of the tokens they own in each epoch, any undeclared tokens will be burned and lost.

[0019] Before turning to the figures, it will be readily appreciated that the components, as generally described herein and illustrated in the figures, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, computer-readable medium, and system, as represented in the accompanying figures, is not intended to limit the scope of the claimed application but is merely representative of selected embodiments.

[0020] The features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrase "exemplary embodiment," "some embodiments," or other similar language throughout this specification indicates that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment. Thus, the appearances of the phrases "exemplary embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements can allow for one-way or two-way communication, or both, even if the connection is shown with a one-way or two-way arrow. Also, any devices shown in the figures can be different devices. For example, where a mobile device is shown transmitting information, a wired device may be used to transmit the information.

[0021] Additionally, while the term "message" may be used in describing the embodiments, the present application may apply to many types of networks and data. Furthermore, although particular types of connections, messages, and signals may be shown in the exemplary embodiments, the present application is not limited to the particular types of connections, messages, and signals.

[0022] Described herein are methods, systems, and computer program products that use specialized blockchain components to enable auditable, privacy-preserving transactions on a blockchain network.

[0023] In some embodiments, a method, system, or computer program product, or combination thereof, uses a decentralized database (e.g., a blockchain) that is a distributed storage system including multiple nodes that communicate with each other. The decentralized database may include an append-only immutable data structure similar to a distributed ledger that can maintain records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and a single peer cannot modify the database record unless consensus is achieved among the distributed peers. For example, peers can run a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain across the blocks. This process forms a ledger by ordering the storage transactions as necessary for consistency.

[0024] In various embodiments, permissioned or permissionless blockchains, or a combination thereof, can be used. In a public, or permissionless, blockchain, anyone can participate without having a specific identity (e.g., while maintaining anonymity). Public blockchains can involve native cryptocurrencies and can use consensus based on various protocols, such as proof-of-work or proof-of-stake. Permissioned blockchain databases, on the other hand, provide secure interactions among a group of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, (private) information, etc.

[0025] Additionally, in some embodiments, a method, system, or computer program product, or combination thereof, may utilize a blockchain to operate arbitrary programmable logic, referred to as a "smart contract" or "chaincode," tailored to a decentralized storage scheme. In some cases, there may be specialized chaincode for managing functions or parameters, referred to as system chaincode (e.g., accessing different blockchains, managing bridging blockchain clients, etc.). In some embodiments, a method, system, or computer program product, or combination thereof, may further utilize smart contracts, which are trusted decentralized applications that utilize the tamper-resistant properties of a blockchain database and underlying agreements between nodes, referred to as authorizations or authorization policies.

[0026] An endorsement policy allows a chaincode to specify the approvers of a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers (e.g., approvers) specified in the endorsement policy, the transaction is executed and validated. After validation, the transaction enters the ordering phase, where a consensus protocol is used to generate an ordered sequence of approved transactions grouped into blocks.

[0027] In some embodiments, a method, system, or computer program product, or a combination thereof, may employ nodes, which are communicating entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of various types may run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submitting client nodes, which submit transaction calls to approvers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node).

[0028] Another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain a ledger state and copy of blockchain transactions. Peers can also have the role of approver, but this is not required. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees such as broadcasting transaction commits / finalizations and modifications to the blockchain world state (another name for the initial blockchain transaction, which usually contains control and setup information) to each of the peer nodes in the system.

[0029] In some embodiments, a method, system, or computer program product, or combination thereof, may employ a ledger, which is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (e.g., transactions, transfers, exchanges, etc.) submitted by participating parties (e.g., client nodes, ordering nodes, validator nodes, peer nodes, etc.). Each participating party (e.g., peer node) may maintain a copy of the ledger. As a result of a transaction, a set of asset key-value pairs may be committed to the ledger as one or more operands, such as a create, update, delete, etc. The ledger includes a blockchain (also known as a chain) used to store immutable, sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0030] In some embodiments, the methods, systems, or computer program products described herein, or combinations thereof, can use a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is equal to or greater than 1. A block header contains a hash of the block's transactions as well as a hash of the header of the previous block. In this way, all transactions on the ledger can be sequenced together and cryptographically linked. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that came before it, ensuring that all peer nodes are in a consistent and trusted state. The chain is stored in the peer node file system (e.g., locally, on attached storage, in the cloud, etc.), allowing for efficient support of append-only blockchain workloads.

[0031] The current state of the immutable ledger represents the most recent values ​​for all keys contained in the chain transaction log. The current state is sometimes referred to as the world state, as it represents the most recent key values ​​known to the channel. Chaincode invocations execute transactions against the ledger's current state data. To make these chaincode interactions efficient, the most recent values ​​for keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log, and therefore can be regenerated from the chain at any time. The state database may be automatically recovered (or generated) when a peer node starts up or before accepting transactions.

[0032] Some advantages of the solutions described and presented herein include methods, systems, and computer program products for implementing new and novel blockchain components that use zero-knowledge proofs to maintain user privacy while enabling the auditing of transactions on a blockchain network. Exemplary embodiments solve the problem of maintaining user privacy while enabling auditing or monitoring agents to perform necessary tasks.

[0033] It should be noted that a blockchain differs from a traditional database in that it does not have a central storage, but rather a decentralized, immutable, and secure storage, and nodes may share changes to records in the storage. Some properties that are unique to blockchains and aid in their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, authorization, accessibility, etc., which are further described herein. According to various aspects, the systems described herein are implemented for immutable accountability, security, privacy, permissioned decentralization, smart contract availability, authorization, and accessibility that are unique and inherent to blockchains.

[0034] In particular, the exemplary embodiments provide numerous advantages over traditional databases, including providing, via the blockchain, immutable accountability, security, privacy, permissioned decentralization, smart contract availability, authorization, and accessibility that are inherent and unique to blockchains.

[0035] On the other hand, exemplary embodiments could not be implemented using traditional databases because they do not put all parties on the network, do not create trusted federation, and do not provide efficient commitment of transactions with verifiable credentials. Traditional databases do not provide tamper-proof storage and do not provide for the maintenance of asset-related costs (e.g., computing costs such as processing power, fees, etc.) if an asset exchange is interrupted. Thus, the proposed embodiments described herein using blockchain networks cannot be implemented with traditional databases.

[0036] Referring now to FIG. 1A, a blockchain architecture 100 according to an embodiment of the present disclosure is illustrated. In some embodiments, the blockchain architecture 100 may include a particular blockchain element, such as a group of blockchain nodes 102. The blockchain nodes 102 may include one or more blockchain nodes, such as peers 104-110 (these four nodes are shown merely by way of example). These nodes participate in several activities, such as adding and validating blockchain transactions (consensus). One or more of the peers 104-110 may approve and / or recommend transactions based on approval policies and may provide an ordering service for all blockchain nodes 102 in the blockchain architecture 100. A blockchain node may initiate blockchain validation and attempt to write to a blockchain immutable ledger stored in a blockchain layer 116, a copy of which may be stored in the supporting physical infrastructure 114. A blockchain configuration may include one or more applications 124 linked to an application programming interface (API) 122 for accessing and executing stored program / application code 120 (e.g., chaincode, smart contracts, etc.) that can be created according to customized configurations desired by participants, maintain their state, control their assets, and receive external information, which can be deployed as transactions and installed on all blockchain nodes 104-110 via appends to the distributed ledger.

[0037] The blockchain base or platform 112 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors attempting to access data items. The blockchain layer 116 may present an interface that provides access to the virtual execution environment necessary to process program code and engage the physical infrastructure 114. The cryptographic trust services 118 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0038] The blockchain architecture 100 of FIG. 1A may process and execute program / application code 120 through one or more interfaces exposed and services provided by the blockchain platform 112. The application code 120 may control blockchain assets. For example, the application code 120 may store and transfer data and may be executed by peers 104-110 in the form of smart contracts and associated chaincode with conditions or other code elements that are subject to execution. As a non-limiting example, smart contracts may be created to perform asset / resource transfers, asset / resource creations, etc. The smart contract itself may be used to identify rules associated with authorizations (e.g., asset transfer rules, restrictions, etc.), access requirements (e.g., of data stores, of off-chain data stores, who may participate in transactions, etc.), or ledger usage, or a combination thereof. For example, verifiable credentials 126 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 may include multiple linked shared documents (e.g., each linked shared document recording the issuance of a smart contract for verifiable credentials 126 committed by a selected group of peers based on an asset exchange schema, issuer policies, etc.). In some embodiments, the physical infrastructure 114 may be used to obtain any of the data / information / assets, etc. described herein.

[0039] Smart contracts may be created via high-level applications and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, or replicated on a blockchain (e.g., a decentralized network of blockchain peers), or a combination thereof. A transaction is the execution of smart contract code that may be executed in response to a condition associated with the smart contract being met. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from smart contract execution may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0040] Smart contracts may write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values ​​stored on the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be public, or it can be encrypted and kept private, or both. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and then deleted once the data needed for the blockchain has been identified.

[0041] Chaincode may include a code interpretation of a smart contract along with additional features. As described herein, chaincode may be program code that is deployed on a computing network and executed and validated by a chain validator together during the consensus process. The chaincode receives a hash and retrieves from the blockchain a hash associated with a data template created by using a pre-stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chaincode transmits an authorization key for the requested service. The chaincode can write data associated with cryptographic details to the blockchain (e.g., thereby committing a transaction associated with an asset, etc.).

[0042] FIG. 1B illustrates an example of a blockchain transaction flow 150 between nodes of a blockchain, according to an example embodiment. Referring to FIG. 1B, the transaction flow may include a transaction proposal 191 sent by an application client node 160 to an endorsing peer node 181. (For example, in some embodiments, the transaction proposal 191 may include a schema specifying the selected set of peers [peer nodes 181-184] to be used for a particular transaction.) The endorsing peer node 181 may verify the client signature and execute a chaincode function to initiate the transaction. Outputs may include a chaincode result, a set of key / value versions read in the chaincode (the read set), and a set of key / values ​​written to the chaincode (the write set). A proposal response 192, if approved, is sent back to the client node 160 along with the approval signature. The client node 160 assembles the approval into a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then distributes the ordered transactions as a block to all peer nodes 181-183 on the channel. Before committing to the blockchain, each peer node 181-183 may validate the transaction. For example, a peer may check an endorsement policy to ensure that a properly assigned designated peer has signed the result and authenticated the signature against the transaction payload 193 (e.g., all designated peers from the schema have validated and authorized the commitment of the transaction to the blockchain).

[0043] Referring again to FIG. 1B, client node 160 initiates a transaction proposal 191 by constructing and sending a request to peer node 181, which in this example is the approver. Client node 160 may include an application utilizing a supported software development kit (SDK), which uses available APIs to generate a transaction proposal 191. This proposal is a request to invoke chaincode functions to read data, write data to the ledger, or both. The SDK may reduce the transaction proposal 191 package to a properly structured format (e.g., protocol buffers over remote procedure calls (RPCs)), obtain the client's cryptographic credentials, and generate a unique signature for the transaction proposal 191.

[0044] In response, the endorsing peer node 181 may verify that (a) the transaction proposal 191 is well-formed, (b) the transaction has not already been submitted previously (replay attack protection), (c) the signature is valid, and (d) the submitter (client node 160 in this example) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 181 may obtain the transaction proposal 191 input as an argument to a called chaincode function. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. However, no updates are made to the ledger at this point. In some embodiments, the set of values, along with the endorsing peer node 181's signature, is returned as a proposal response 192 to the client node 160's SDK, which parses the payload for the application to consume.

[0045] In response, the application on the client node 160 checks / verifies the signatures of the endorsing peers and compares the proposal responses to determine whether they are the same. If the chaincode only queried the ledger, the application checks the query response and typically does not submit the transaction to the ordering service node 184. When the client application intends to submit a transaction to the ordering service node 184 to update the ledger, the application determines whether the specified endorsement policy is fulfilled before submission. Here, a client may include only one of multiple parties to a transaction. In this case, each client may have its own endorsing node, and each endorsing node must approve the transaction. The architecture is such that even if the application chooses not to check the response or forwards an otherwise unendorsed transaction, the endorsement policy is still enforced by peers and upheld in the commit validation phase.

[0046] After successful validation, in the transaction payload stage 193, the client node 160 assembles the endorsements into a transaction and broadcasts the transaction proposal 191 and responses in a transaction message to the ordering node 184. The transaction may include a read / write set, the signatures of the endorsing peers, and a channel ID (e.g., if a specific off-chain data store is used). The ordering node 184 does not need to validate the entire contents of the transaction to perform its operations; instead, the ordering node 184 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0047] A block of transactions is distributed from the ordering node 184 to all peer nodes 181-183 on the channel. The transactions 194 in the block are validated to ensure that any authorization policies are enforced and to ensure that no ledger state changes have occurred with respect to the readset variable since transaction execution generated the readset. The transactions in the block are tagged as valid or invalid. Furthermore, in step 195, each peer node 181-183 appends the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. An event is emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as whether the transaction was validated or invalidated.

[0048] Referring now to FIG. 2 , an exemplary blockchain network 200 for maintaining privacy of auditable transactions is illustrated, according to an embodiment of the present disclosure. In some embodiments, the blockchain network includes a private auditable transaction engine 202 operable at peer 1 104. The private auditable transaction engine 202 is a computer program capable of generating and / or executing private auditable transactions operable on a permissioned or permissionless blockchain network. While the private auditable transaction engine 202 is shown operable at peer 1 104, the private auditable transaction engine 202 may be operable at one or more blockchain nodes 102 (e.g., peer 2 106, peer 3 108, and peer 4 110) within the blockchain network. Furthermore, one or more private auditable transaction engines 202 may be located as separate nodes within the blockchain network and within a particular channel of the blockchain network. Each peer within the blockchain network may function in one or more roles in the private auditable transaction service.

[0049] In some embodiments, the private auditable transaction engine 202 sets up epochs and maintains a world clock associated with each epoch. An epoch is a predefined amount of time (e.g., 1 hour, 2 hours, 1 day, etc.) within which transactions may span. For example, one or more nodes may be responsible for maintaining and maintaining the world clock associated with the blockchain network. The world clock may be based on a single time zone or may operate on a 24-hour clock that is initialized at a given time. Additionally, the peer nodes responsible for maintaining the world clock may send notifications when an epoch ends and update the blockchain accordingly.

[0050] In some embodiments, the private auditable transaction engine 202 can generate tokens associated with a transaction. Tokens generated within a transaction can hide the owner of the token in a manner based on unspent transaction outputs. For example, an input token can be a set of tokens from a recipient block. The input token must be traceable to a previous transaction. The input token must be of the same type as the output token generated by the private auditable transaction engine 202. The total value of the input token must be the same as the generated output token. The owner of the input token must provide a private key to sign off the transaction. The input token must not have been spent in a previous transaction.

[0051] In one embodiment, the private auditable transaction engine 202 may generate an output token in the following manner: Note that the following example, for convenience, refers to only one output token from one input token. More than one token may be generated by the private auditable transaction engine 202 during a transaction. A token may be a portion of data that includes: Tok=commit(owner,type,value,e,transferrable,seed,r) where commit is a hidden component, e is the identifier of the current epoch, Transferable is a Boolean term indicating whether the token is transferable or not, Seed is a random seed used to generate the token's serial number, and r is a blinding factor.

[0052] In one embodiment, the private auditable transaction engine 202 may audit the token. One or more nodes in the blockchain network may act as auditors (e.g., peer 2 106, peer 3 108). For example, at the end of each epoch, users submit the tokens they received during each epoch. The auditor may check the freshness of the token. Freshness is an indicator of whether the token was generated in the most recent closed epoch. In the example above, the auditor checks the e in the token. If the auditor determines that the token is fresh, the auditor may update the token's status to transferable. If the auditor determines that the token is not fresh, the auditor may update the token's status to non-transferable. In some cases, non-transferable tokens are essentially useless and are therefore burned.

[0053] In one embodiment, the private auditable transaction engine 202 can generate a zero-knowledge proof to show that the owner is registered and the token encodes the appropriate information. For example, the issuer can be a node in a blockchain network that issues a zero-knowledge proof ψ that shows that the token encodes the owner, a token type, a value e, false, and r.

[0054] In one embodiment, the private auditable transaction engine 202 may be configured to allow an issuer to add a signature to a message and submit the signed transaction. For example, a message may contain tok, type, ψ, and pk I may include (pk I refers to the issuer's public key). So a signed transaction could be: Tx=(issue, tok, owner, type, value, ψ, pkI, σ). In one embodiment, the private auditable transaction engine 202 checks whether 1) the issue is within the permission range to create a token of that "type" and 2) σ is the public key pk Iand 3) whether ψ is a valid zero-knowledge proof.

[0055] In one embodiment, the private auditable transaction engine 202 may be configured to generate transactions that transfer ownership of a token. For example, the input token may be the output token from a previous transaction where the input token has been re-randomized. For example, the original token without an associated epoch may be as follows: Tok = commit(owner, type, value, true, --, seed, r), and the original token may be re-randomized in the following manner: tok' = commit(owner', type, value, false, e, seed', r'). If the owner is a new owner, e is the current epoch seed' and r' is a random number. Additionally, the private auditable transaction engine 202 may generate a new serial number for the randomized token. For example, the token serial number may be as follows: sn = VRF(sk, seed), where VRF is a verifiable pseudorandom function and sk is the owner's private key. The VRF provides publicly verifiable proof of the correctness of the output.

[0056] In one embodiment, the private auditable transaction engine 202 may be configured to generate a zero-knowledge proof by the owner of the token. The zero-knowledge proof may include one or more of the following: Tok" is a valid token randomization, tok' is correctly generated (i.e., maintains the token type and value, transferable is set to false, and epoch is the current epoch), the owner is a registered user of the blockchain network, and Sn is correctly computed (i.e., sn is computed using the owner's private key and the seed encoded in tok").

[0057] In one embodiment, the private auditable transaction engine 202 may be configured to allow the owner of a token to generate an anonymous signature that indicates that the signer knows the owner of the token's private key. For example, let the anonymous signature be σ on the message (sn, tok", tok', ψ), where σ indicates that the signer knows the owner's private key in tok". A transfer transaction would correspond to the following: Tx=(transfer, sn, tok". tok', ψ, σ).

[0058] In one embodiment, the private auditable transaction engine 202 may be configured to allow a user to report tokens at the end of an epoch. For example, for each token the user owns, the user may provide the following to the auditor: owner, value, type, e, seed, and r. The auditor can check whether the owner is the user and whether the token is a valid transaction output that matches the provided data. If the provided data is valid, the auditor can mark the token as verified.

[0059] In one embodiment, the private auditable transaction engine 202 may be configured to allow an auditor to modify data in an inspected token. For example, the auditor may modify a presented token from tok=commit(owner, value, type, e, false, seed, r) to tok'=commit(owner, value, type, --, true, seed, r'), where an epoch is not associated with the token and a Boolean value indicating whether the token can be transferred to another user is set to true. Furthermore, the entire accounting transaction may be as follows: tx=(account, tok, tok', ψ, σ), where ψ is a zero-knowledge proof that tok' encodes the same information as tok except that it is transferable and its epoch has been redacted, and σ is the auditor's signature on the message (account, tok, tok', ψ).

[0060] In one embodiment, the private auditable transaction engine 202 may be configured to allow merging and splitting tokens without changing token ownership. For example, an auditor may monitor the last time a user participated in an account session in the current epoch. In this example, the Boolean transferable may be removed or inferred from the presence of the epoch field. If the epoch field is set by the auditor, the token cannot be spent, but if the epoch field is null, the token can be spent. Additionally, the private auditable transaction engine 202 may be configured to allow the auditor to monitor and batch multiple tokens in a single account transaction, allowing multilateral transactions to occur in sequence.

[0061] In one embodiment, the private auditable transaction engine 202 may be configured to merge and split transactions and tokens. For example, a user can hide the number of transactions they have participated in in the current epoch by merging or splitting transactions or tokens. Transactions may have the following properties: transferrable Boolean set to false, the owner at the output is the same as the input, and the epoch at the output is the same as the input. Thus, data associated with any tokens and transactions is hidden from auditors and other participants in the network, as they only appear as if the user previously owned them.

[0062] Note that as embodied and implemented in FIG. 2 and throughout this specification, the presented novelty is multiplicative.

[0063] 3, a flowchart of an example method 300 for privacy-preserving, auditable blockchain transactions is shown. In some embodiments, method 300 may be performed by a processor, a node, or a peer node, or a combination thereof, in a blockchain network (such as blockchain network 200 of FIG. 2).

[0064] In some embodiments, the method 300 proceeds to stage 302, where a processor encodes a token in the current epoch via a peer (e.g., peer 1 104, peer 2 106, peer 3 108, peer 4 110) in the blockchain architecture 100. For example, the private auditable transaction engine 202 may enable a user to encode an input token received in the current epoch into an output token indicating that it was received in the current epoch.

[0065] In some embodiments, method 300 proceeds to step 304, where one or more tokens are received for inspection via a peer in blockchain architecture 100. For example, private auditable transaction engine 202 may be configured to allow an auditor node to receive tokens from users of the blockchain network.

[0066] In some embodiments, method 300 proceeds to step 306, where an audit node performs an audit check on the received token. For example, the private auditable transaction engine 202 may be configured to enable an audit node in the blockchain network to perform an audit check on the received token, where the audit node can check to determine whether the token is transferable and was generated in the most recent epoch.

[0067] In some embodiments, method 300 proceeds to step 308, where the private auditable transaction engine 202 may be configured to determine whether the audit check by the audit node is successful. For example, the audit check may be determined to be successful if the audit node determines that the encoded token is from a valid transaction (e.g., the token is transferable and was generated in the most recent epoch). Additionally, the audit node may determine whether the user is the owner of the token via the zero-knowledge proof encoded by the user in step 302.

[0068] In some embodiments, method 300 proceeds to step 310, where the private auditable transaction engine 202 may be configured to submit an audit check. For example, the audit node may provide a signature for the audit check to enable the token to be included in a transaction that may be appended to the ledger of the blockchain network.

[0069] In some embodiments described below, one or more operations of method 300 are not shown for the sake of brevity.

[0070] Although this disclosure includes detailed descriptions related to cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.

[0071] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0072] The characteristics are as follows:

[0073] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without requiring human interaction with the provider of the service.

[0074] Wide network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, and PDAs).

[0075] Resource Pool: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers typically have no control or knowledge over the exact portion of resources provided, although there is a sense of partial independence in that they may be able to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0076] Rapid Flexibility: Capabilities can be provisioned quickly and flexibly, sometimes automatically, to scale out quickly, release quickly and scale in quickly. To the consumer, the capabilities available for provisioning often seem unlimited, and can be purchased at any time and in any quantity.

[0077] Measured Services: Cloud systems automatically control and optimize resource usage by utilizing metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services used.

[0078] The service model is as follows:

[0079] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0080] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration.

[0081] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0082] The deployment model is as follows:

[0083] Private Cloud: Cloud infrastructure operated solely for an organization. It may be managed by the organization or a third party and may exist on-premise or off-premise.

[0084] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0085] Public Cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0086] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting to load balance between clouds).

[0087] Cloud computing environments are service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0088] 4A illustrates a cloud computing environment 410. As illustrated, the cloud computing environment 410 includes one or more cloud computing nodes 400, which may communicate with local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cell phone 400A, a desktop computer 400B, a laptop computer 400C, or an automobile computer system 400N, or combinations thereof. The nodes 400 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above.

[0089] This enables the cloud computing environment 410 to provide infrastructure, platform, and / or software as a service without requiring cloud consumers to maintain resources on local computing devices. It will be understood that the types of computing devices 400A-N shown in Figure 4A are intended to be exemplary only, and that computing nodes 400 and cloud computing environment 410 can communicate with any type of computerized device over any type of network or network-addressable connection or both (e.g., using a web browser).

[0090] Figure 4B illustrates a set of functional abstraction layers provided by cloud computing environment 410 (Figure 4A). It should be understood in advance that the components, layers, and functions illustrated in Figure 4B are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. The following layers and corresponding functions are provided as follows:

[0091] Hardware and software layer 415 includes hardware and software components. Examples of hardware components include mainframe 402, RISC (Reduced Instruction Set Computer) architecture-based server 404, server 406, blade server 408, storage device 411, and network and networking components 412. In some embodiments, software components include network application server software 414 and database software 416.

[0092] The virtualization layer 420 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 422, virtual storage 424, virtual networks 426 including virtual private networks, virtual applications and operating systems 428, and virtual clients 430.

[0093] In one example, management layer 440 may provide the following functions: Resource provisioning 442 provides dynamic procurement of computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 444 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 446 provides consumers and system administrators with access to the cloud computing environment. Service level management 448 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 450 provides pre-configuration and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

[0094] Workload layer 460 provides examples of functions for which a cloud computing environment may be used. Examples of workloads and functions that may be provided from this layer include mapping and navigation 462, software development and lifecycle management 464, virtual classroom instructional delivery 466, data analytics processing 468, transaction processing 470, and privacy-preserving, auditable blockchain transactions 472.

[0095] 5 illustrates a high-level block diagram of an exemplary computer system 501 that may be used to implement (e.g., using one or more processor circuits of a computer or computer processor) one or more of the methods, tools, and modules described herein, and any associated functionality, according to embodiments of the present disclosure. In some embodiments, major components of computer system 501 may include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 516, an I / O (input / output) device interface 514, and a network interface 518, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0096] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, collectively referred to herein as CPUs 502. In some embodiments, computer system 501 may include multiple processors typical of larger systems. However, in other embodiments, computer system 501 may alternatively be a single-CPU system. Each CPU 502 may execute instructions stored in memory subsystem 504 and may include one or more levels of on-board cache.

[0097] The system memory 504 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 522 or cache memory 524. The computer system 501 may also include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, the storage system 526 may be provided to read from and write to a non-removable, non-volatile magnetic medium, such as a “hard drive.” Although not shown, a magnetic disk drive may be provided to read from or write to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive may be provided to read from and write to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. Additionally, the memory 504 may include flash memory, such as a flash memory stick drive or flash drive. Memory devices may be connected to the memory bus 503 by one or more data medium interfaces. The memory 504 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments.

[0098] One or more programs / utilities 528, each having at least one set of program modules 530, may be stored in memory 504. The programs / utilities 528 may include a hypervisor (also known as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networking environment. The programs 528 or program modules 530, or combinations thereof, generally perform the functions or methods of the various embodiments.

[0099] 5 as a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510, memory bus 503 may, in some embodiments, include multiple different buses or communication paths that may be arranged in any of a variety of forms, such as hierarchical, star, or web configurations, multiple hierarchical buses, parallel redundant paths, or point-to-point links in any other suitable type of configuration. Additionally, while I / O bus interface 510 and I / O bus 508 are shown as single respective units, computer system 501 may, in some embodiments, include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Additionally, while multiple I / O interface units are shown isolating I / O bus 508 from the various communication paths leading to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0100] In some embodiments, computer system 501 may be a multi-user mainframe computer system, a single-user system, or a server computer, or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 501 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0101] It should be noted that Figure 5 is intended to illustrate representative major components of an exemplary computer system 501. However, in some embodiments, individual components may be more or less complex than depicted in Figure 5, components other than or in addition to those depicted in Figure 5 may be present, and the number, type, and configuration of such components may vary.

[0102] As described in more detail herein, it is contemplated that some or all of the operations of some of the method embodiments described herein may be performed in an alternate order, or not performed at all, and further, operations may be performed simultaneously or as an integral part of a larger process.

[0103] The present disclosure may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium or media having computer-readable program instructions that cause a processor to perform aspects of the present disclosure.

[0104] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but 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 computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0105] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0106] The computer-readable program instructions for performing the operations of the present disclosure may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions using the state information of the computer readable program instructions to personalize the electronic circuitry to carry out aspects of the present disclosure.

[0107] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present 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-readable program instructions.

[0108] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to create a machine, such that the instructions, executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or any combination thereof. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or any combination thereof, to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein constitutes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or any combination thereof.

[0109] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to execute a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or a combination thereof.

[0110] The flowcharts 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 of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement a specified logical function. 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 actually be realized as a single step, or may be executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of a block diagram or flowchart illustration, or combinations thereof, and combinations of blocks in block diagrams or flowchart illustrations, or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or a combination of special-purpose hardware and computer instructions.

[0111] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art that do not depart from the scope and spirit of the described embodiments. The terminology used in this specification has been selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0112] While the present disclosure has been described with reference to specific embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications as fall within the true spirit and scope of the present disclosure.

Claims

1. 1. A computer-implemented method for privacy-preserving auditable accounting, comprising: generating at least one token, the at least one token encoded with an owner, a type, a value, a current epoch, a Boolean value indicating whether the token is transferable, a seed, and an r value, where the epoch is a particular time range; generating a zero-knowledge proof, the zero-knowledge proof indicating that the owner of the at least one token is a registered user of a blockchain network; assembling a first transaction message, the first transaction message including the at least one token, a zero-knowledge proof, and an issuer public key; signing the first transaction message, the signature being based on a private key associated with the issuer's public key; broadcasting the first transaction message to the blockchain network; 1. A computer-implemented method comprising:

2. verifying the first transaction message; The computer-implemented method of claim 1 further comprising:

3. Verification is determining whether the issuer is authorized to create tokens of the type corresponding to the token in the first transaction message; determining whether the issuer's signature is valid, the signature being checked against the public key in the first transaction message; determining whether the zero-knowledge proof is valid; The computer-implemented method of claim 2 , comprising:

4. marking the encoded token as non-transferable in response to determining that the audit check is not valid. The computer-implemented method of claim 2 or 3, further comprising:

5. marking the encoded token as transferable in response to verifying that the audit check is successful. The computer-implemented method of claim 2 or 3, further comprising:

6. transferring ownership of one or more tokens, the transfer comprising consuming the token to be transferred and creating one or more tokens having the same value and type as the token and encoding the current epoch, second seed and second r values, a new owner, and bits indicating that they are not yet transferable; generating a token serial number for each of the one or more input tokens; generating a second zero-knowledge proof indicating that the one or more input tokens are transferable and that the newly created token is not transferable; generating a second anonymous signature for the first transaction message, the second anonymous signature verifying that a signer knows a private key of the owner of the one or more input tokens; The computer-implemented method of claim 5 further comprising:

7. The transfer is assembling a second transaction message that includes the token serial number, the second zero-knowledge proof, and the newly created one or more tokens; signing the second transaction message; The computer-implemented method of claim 6 further comprising:

8. validating the second transaction message, the validation being based at least in part on determining whether the one or more newly created tokens in the second transaction message are encoded with the current epoch and are not already transferable. The computer-implemented method of claim 7 further comprising:

9. and issuing a second account transaction in response to validating the second transaction message, the second account transaction marking the one or more created tokens as transferable; Account transactions consist of zero-knowledge proofs and auditor signatures.

9. The computer-implemented method of claim 8.

10. 1. A computer system for privacy-preserving auditable accounting, comprising: Memory and a processor in communication with said memory; Equipped with The processor: generating at least one token, the at least one token being encoded with an owner, a type, a value, a current epoch, a Boolean value indicating whether the token is transferable, a seed, and an r value, where the epoch is a particular time range; generating a zero-knowledge proof, the zero-knowledge proof indicating that the owner of the at least one token is a registered user of a blockchain network; assembling a first transaction message, the first transaction message including the at least one token, a zero-knowledge proof, and an issuer public key; signing the first transaction message, the signature being based on a private key associated with the issuer's public key; broadcasting the first transaction message to the blockchain network; 1. A computer system configured to perform operations comprising:

11. an operation of verifying the first transaction message; The computer system of claim 10 further comprising:

12. The verifying operation includes: determining whether the issuer is authorized to create tokens of the type corresponding to the token in the first transaction message; determining whether the issuer's signature is valid, wherein the signature is checked against the public key in the first transaction message; a step of determining whether the zero-knowledge proof is valid; 12. The computer system of claim 11, comprising:

13. and marking the encoded token as non-transferable in response to determining that the audit check is not valid.

13. The computer system of claim 10, further comprising:

14. and marking the encoded token as transferable in response to verifying that the audit check is successful.

13. The computer system of claim 10, further comprising:

15. 1. A computer program for privacy-preserving auditable accounting, comprising: The processor generating at least one token, the at least one token being encoded with an owner, a type, a value, a current epoch, a Boolean value indicating whether the token is transferable, a seed, and an r value, where the epoch is a particular time range; generating a zero-knowledge proof, the zero-knowledge proof indicating that the owner of the at least one token is a registered user of a blockchain network; assembling a first transaction message, the first transaction message including the at least one token, a zero-knowledge proof, and an issuer public key; signing the first transaction message, the signature being based on a private key associated with the issuer's public key; broadcasting the first transaction message to the blockchain network; A computer program for executing

16. the processor, verifying the first transaction message; The computer program of claim 15 , further comprising:

17. The verifying step comprises: determining whether the issuer is authorized to create tokens of the type corresponding to the token in the first transaction message; determining whether the issuer's signature is valid, wherein the signature is checked against the public key in the first transaction message; a step of determining whether the zero-knowledge proof is valid; 17. The computer program of claim 16, comprising:

18. the processor, marking the encoded token as non-transferable in response to determining that the audit check is not valid.

18. A computer program according to any one of claims 15 to 17, further comprising:

19. the processor, marking the encoded token as transferable in response to verifying that the audit check is successful.

18. A computer program according to any one of claims 15 to 17, further comprising:

20. The transfer is assembling a second transaction message including the token serial number, the second zero-knowledge proof, and the re-randomized token or tokens; signing the second transaction message; 20. The computer program of claim 19, comprising:

Images