Method and system for protecting privacy of auditable accounts

Abstract

The present disclosure relates to protecting privacy of auditable accounts. A method for privacy protection of auditable accounts on a blockchain network. The method can include encoding a token associated with the blockchain network. The encoding can include data related to a current epoch, where an epoch is a particular time range. The token can be received from a user for inspection by an auditing entity. The method can include performing an audit check on the encoded token. If the audit check is successful, the auditing entity can submit an audit transaction that verifies that the token was generated in the current epoch and makes the token auditable for a next epoch.

Description

BACKGROUND

[0001] The present disclosure relates generally to the field of blockchain transaction processing, and more specifically to auditing blockchain transactions while preserving privacy of user transactions.

[0002] A blockchain is a distributed ledger comprised of multiple nodes within a peer-to-peer network. Each node has an identical copy of the ledger, making the blockchain a decentralized system as there is no central authority controlling management of the blockchain. Blocks in the blockchain are“transactions” that are recorded by adding additional blocks to the chain of blocks, linked together by cryptographic means. Each block within the 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 the blockchain requires nodes to follow a consensus protocol (e.g., proof-of-work, proof-of-stake, etc.) in order to validate the new block.

[0003] A blockchain can be permissioned or un-permissioned. A permissioned blockchain is a private blockchain where nodes must be validated in some way before it can access the blockchain or make changes to the blockchain. In some permissioned blockchains, parties in the blockchain can be restricted from accessing parts of the blockchain or participating in bi- or multi-directional transactions. Un-permissioned blockchains are generally open source in nature and allow anyone with an internet connection to send transactions and participate in executing consensus protocols. SUMMARY

[0004] Embodiments of the present disclosure include a computer-implemented method, system, and computer program for a privacy-protected auditable account. Embodiments can include generating at least one token, wherein the at least one token is encoded with an owner, a type, a current epoch value, a transferability, a seed, and an r value, wherein an epoch is a specific time range. Further, embodiments can include generating a zero-knowledge proof, wherein the zero-knowledge proof indicates that the owner of the at least one token is a registered user of a blockchain network. Additionally, embodiments can include assembling a first transaction message, wherein the transaction message includes the at least one token, the zero-knowledge proof, and a public key of an issuer. Moreover, embodiments can include signing the first transaction message, wherein the signing is based on a private key associated with the public key of the issuer, and broadcasting the transaction message to the blockchain network.

[0005] The above summary of the present disclosure does not necessarily describe every illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0006] The accompanying drawings, which are included in the disclosure, are incorporated in and form part of the specification and are included for explanatory purposes. They illustrate embodiments of the present disclosure and, together with the general description of the disclosure given above, and the detailed description of the embodiments below, serve to explain the principles of the present disclosure. The drawings are only intended to illustrate certain embodiments of the disclosure and are not intended to limit the disclosure.

[0007] Figure 1A An example blockchain architecture, generally designated 100, in accordance with an embodiment of the present disclosure is shown.

[0008] Figure 1B A blockchain transaction flow, generally designated 150, in accordance with an embodiment of the present disclosure is shown.

[0009] Figure 2 An example system for auditable privacy-protected blockchain transactions, generally designated 200, in accordance with an embodiment of the present disclosure is shown.

[0010] Figure 3 A flow diagram of an example method for auditable privacy-protected blockchain transactions, generally designated 300, in accordance with an embodiment of the present disclosure is shown.

[0011] Figure 4A A cloud computing environment, in accordance with an embodiment of the present disclosure is shown.

[0012] Figure 4B An abstraction model layer, in accordance with an embodiment of the present disclosure is shown.

[0013] Figure 5 A high-level block diagram of an example computer system, generally designated 501, that can be used to implement one or more of the methods, tools, and modules and any related functionality described herein, in accordance with an embodiment of the present disclosure is shown.

[0014] While the embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood however that the description is not intended to be limited to the particular embodiments described. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure. DETAILED DESCRIPTION

[0015] Aspects of the present disclosure generally relate to the field of preserving privacy in blockchain transactions, and more particularly to privacy-protected token exchange with account services via a blockchain. Distributed ledger technology ("DLT") has given rise to decentralized token systems. These systems allow end users to exchange tokens without a central authority. The consistent mechanism underlying DLT guarantees the correctness of data in the ledger and the finality of exchanges. However, decentralization gives rise to privacy concerns: by design, anyone with access to the ledger can read the history of a user's transactions. This has created an active field of research that focuses on obfuscating a user's transactions without sacrificing verifiability. That is, even if the contents of a transaction are hidden, the nodes that maintain the ledger can still verify the transaction.

[0016] In embodiments, a zero-knowledge proof can be used to hide the contents of a transaction. A zero-knowledge proof provides a method to achieve the purpose of verifying a transaction while hiding the transaction contents from unauthorized viewers on the blockchain network. Hiding the transaction contents should not prevent authorized parties from auditing and transaction monitoring. For example, anti-money laundering regulations require banks to check for suspicious transactions and prevent suspicious transactions from finalizing if necessary.

[0017] Embodiments of the present application can provide a method that enables a user to make private transactions on a blockchain network while allowing an auditor or monitoring agent to perform account tasks. More specifically, an authorized party can learn the number of tokens a user receives in an epoch. If the user does not declare all of the tokens it possesses in each epoch, any undeclared tokens will be destroyed and lost.

[0018] Before turning to the drawings, it will be appreciated that the instant components, as described and illustrated herein, can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description, which discloses at least one embodiment of a method, apparatus, computer readable medium, and system, as represented in the drawings, is not intended to limit the scope of the application as claimed, but is merely representative of selected embodiments.

[0019] In one or more embodiments, the instant features, structures, or characteristics, as described throughout this specification, can be combined or removed in any appropriate manner. For example, the use of the phrases “exemplary embodiment,” “some embodiments,” or other similar language throughout this specification is intended to convey that the particular feature, structure, or characteristic being described can be included in at least one embodiment. As such, the phrases “exemplary embodiment,” “in some embodiments,” “in other embodiments,” or other similar language appearing throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any suitable manner in one or more embodiments. In addition, in the drawings, any connection can be permitted to be a unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Also, any device depicted in the drawings can be a different device. For example, if a mobile device is shown as sending information, a wired device can also be used to send the information.

[0020] Furthermore, while the term “message” can have been used in the description of embodiments, the application can apply to many types of networks and data. In addition, while a particular type of connection, message, and signaling can be described in exemplary embodiments, the present application is not limited to a particular type of connection, message, and signaling.

[0021] Detailed herein are methods, systems, and computer program products that utilize specialized blockchain components for privacy-preserving transactions that can be audited on a blockchain network.

[0022] In some embodiments, the methods, systems, and / or computer program products utilize a decentralized database (e.g., a blockchain) as a distributed storage system that includes multiple nodes that communicate with each other. The decentralized database can include an append-only immutable data structure similar to a distributed ledger that is capable of maintaining records between mutually untrusted parties. The mutually untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without agreement among the distributed peers. For example, the peers can execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain on the blocks. For consensus, the process forms a ledger by ordering the storage transactions as needed.

[0023] In various embodiments, permissioned and / or un-permissioned blockchains can be used. In a public or un-permissioned blockchain, anyone can participate without a specific identity (e.g., preserving anonymity). Public blockchains can involve local cryptography and use consensus based on different protocols such as proof-of-work or proof-of-stake. Whereas, a permissioned blockchain database provides secure interactions between a group of entities (such as businesses exchanging funds, goods, (private) information, etc.) that share a common goal but are not fully mutually trusted.

[0024] Further, in some embodiments, the methods, systems, and / or computer program products can utilize a blockchain that operates arbitrary programmable logic tailored for a decentralized storage scheme and is referred to as a“smart contract” or“chaincode.” In some cases, there can be a special chaincode for administrative functions and parameters referred to as system chaincode (such as managing access to different blockchains, bridged blockchain clients, etc.). In some embodiments, the methods, systems, and / or computer program products can further utilize a smart contract, which is a trusted distributed application that utilizes the tamper-proof properties of the blockchain database and the underlying protocol between the nodes, which is referred to as endorsement or endorsement policy.

[0025] The endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes necessary for endorsement. When a client sends a transaction to the peers (e.g., endorsers) specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters an ordering phase, where an ordered sequence of endorsed transactions grouped into blocks is produced using a consensus protocol.

[0026] In some embodiments, the methods, systems, and / or computer program products can utilize nodes that are communication entities of the blockchain system. A "node" can perform logical functions in the sense that different types of multiple nodes can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in different ways. Nodes can include different types, such as clients or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to order service (e.g., order nodes).

[0027] Another type of node is a peer node that can receive transactions submitted by clients, submit those transactions, and maintain a state and copy of a ledger of blockchain transactions. A peer can also have the role of an endorser, although it is not required. An order-service-node or orderer is a node that runs a communication service for all nodes and implements delivery guarantees, such as broadcasting to every peer node in the system when a transaction is submitted / acknowledged and when the world state of the blockchain, which is another name for the initial blockchain transaction, is modified, which typically includes control and setup information.

[0028] In some embodiments, the methods, systems, and / or computer program products can utilize a ledger that is a tamper-resistant record of the ordering of all state transitions of a blockchain. State transitions can be caused by chaincode calls (e.g., transactions, transfers, exchanges, etc.) submitted by participants (e.g., client nodes, order nodes, endorser nodes, peer nodes, etc.). Each participant, such as a peer node, can maintain a copy of the ledger. A transaction can cause a set of asset key-value pairs to be submitted to the ledger as one or more operations (such as create, update, delete, etc.). The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0029] In some embodiments, the methods, systems, and / or computer program products described herein can utilize a chain that is a journal of transactions structured as a hash-linked block and each block contains a sequence of N transactions, where N is greater than or equal to one. A block header includes a hash of the transactions of the block and a hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. As such, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that has occurred before the chain, thereby enabling assurance that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), thereby effectively supporting the append-only nature of blockchain workloads.

[0030] The current state representation of the immutable ledger includes the latest values of all keys included in the chain transaction log. Because the current state representation is known to the channel of the latest key values, it is sometimes referred to as the world state. Chain invocations execute transactions against the current state data of the ledger. In order for these chain interactions to be valid, the latest values of the keys can be stored in a state database. The state database can simply be an indexed view into the chain's transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated) at peer startup and before accepting transactions.

[0031] Some benefits of the instant solutions described and depicted herein include a method, system, and computer program product for implementing a new, novel blockchain component that leverages zero-knowledge proofs to protect user privacy while allowing for the auditing of transactions on a blockchain network. The exemplary embodiments address the problem of protecting user privacy while allowing an auditing or monitoring agent to perform necessary tasks.

[0032] Note that a blockchain differs from a traditional database in that a blockchain is not a centrally stored, but rather a decentralized, immutable, and secure storage in which nodes can share changes to records in storage. Some properties inherent in a blockchain and that contribute to the implementation of a blockchain include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like, further described herein. According to different aspects, the systems described herein are implemented due to the immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, consensus, and accessibility that are inherent and unique to a blockchain.

[0033] In particular, these exemplary embodiments provide a number of benefits over traditional databases. For example, through a blockchain, the embodiments provide the immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, consensus, and accessibility that are inherent and unique to a blockchain.

[0034] At the same time, a traditional database cannot be used to implement the example embodiments because it does not bring all parties on the network, it does not create trusted collaboration, and it does not provide for the valid submission of transactions involving verifiable credentials. If an asset exchange is interrupted, a traditional database does not provide tamper-proof storage, and it does not provide for the preservation of asset-related costs (e.g., computational costs, such as processing power, fees, and the like). As such, the proposed embodiments described herein that leverage a blockchain network cannot be implemented by a traditional database.

[0035] Turning now to Figure 1A, showing a blockchain architecture 100 in accordance with embodiments of the present disclosure. In some embodiments, the blockchain architecture 100 can include certain blockchain elements, such as a set of blockchain nodes 102. The blockchain nodes 102 can include one or more blockchain nodes, such as peers 104-110 (these four nodes are depicted by way of example only). These nodes participate in a number of activities, such as blockchain transaction addition and validation processes (consensus). One or more of the peers 104-110 can endorse and / or recommend transactions based on an endorsement policy, and can provide ordering services for all of the blockchain nodes 102 in the blockchain architecture 100. The blockchain nodes can initiate blockchain authentication and attempt to write to a blockchain immutable ledger stored in a blockchain layer 116, a copy of which can also be stored on supporting physical infrastructure 114. The blockchain configuration can include one or more applications 124 that link to an application programming interface (API) 122 to access and execute stored program / application code 120 (e.g., chaincode, smart contracts, etc.), which can be created according to a custom configuration sought by a participant and can maintain its own state, control its own assets, and receive external information. This can be deployed as a transaction and installed on all of the blockchain nodes 104-110 via addition to the distributed ledger.

[0036] The blockchain base or platform 112 can include different layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 116 can expose an interface that provides access to processing program code and virtual execution environments necessary to participate in the physical infrastructure 114. Cryptographic trust services 118 can be used to validate transactions, such as asset exchange transactions, and keep information private.

[0037] Figure 1AThe blockchain architecture 100 can process and execute program / application code 120 via one or more interfaces exposed by the blockchain platform 112 and services provided. The application code 120 can control blockchain assets. For example, the application code 120 can store and transfer data and can be executed by the peers 104-110 in the form of smart contracts and associated chain code, with conditions or other code elements subject to their execution. As a non-limiting example, a smart contract can be generated to perform a transfer of assets / resources, generation of assets / resources, etc. The smart contract itself can be used to identify rules associated with authorization (e.g., asset transfer rules, restrictions, etc.), access requirements (e.g., access requirements for data storage, access requirements for off-chain data storage, access requirements for who can participate in a transaction, etc.), and / or use of the ledger, etc. For example, the verifiable credentials 126 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 can include a plurality of linked shared documents (e.g., each linked shared document records issuance of a smart contract for a verifiable credential 126 submitted by a selected peer group based on an asset exchange pattern, issuer policy, etc.). In some embodiments, the physical infrastructure 114 can be used to retrieve any data / information / assets / etc. described herein.

[0038] A smart contract can be created via a high-level application and programming language and then written to a block in the blockchain. A smart contract can include executable code that is registered, stored, and / or replicated with a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that can be executed in response to conditions associated with the smart contract being satisfied. Execution of a smart contract can trigger a trusted modification to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution can be automatically replicated throughout a distributed network of blockchain peers by one or more consensus protocols.

[0039] A smart contract can write data to a blockchain in the format of key-value pairs. Additionally, smart contract code can read values stored in the blockchain and use them in application operations. Smart contract code can write outputs of different logical operations to the blockchain. 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 and / or can be encrypted and maintained as private. Temporary data used / generated by a smart contract is saved in memory by the supplied execution environment and then deleted once the data needed by the blockchain is identified.

[0040] Chaincode can include code interpretation of a smart contract with additional features. As described herein, chaincode can be program code deployed on a computing network, where the chaincode is executed and validated by chain validators together during a consensus process. The chaincode receives a hash and retrieves from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode can write to the blockchain data associated with the encryption details (e.g., thus committing a transaction associated with an asset, etc.).

[0041] Figure 1B An instance of a blockchain transaction flow 150 between nodes of a blockchain is shown in accordance with example embodiments. Referring to Figure 1B , the transaction flow can include a transaction proposal 191 sent by an application client node 160 to an endorsing peer node 181 (e.g., in some embodiments, the transaction proposal 191 can include a mode specifying a selected set of peers [peer nodes 181-184] to be used for a particular transaction). The endorsing peer node 181 can validate the client signature and execute chaincode functions to initiate the transaction. The output can include chaincode results, a set of key / value versions read in the chaincode (read set), and a set of key / values written in the chaincode (write set). If approved, a proposal response 192 is sent back to the client node 160 along with an endorsement signature. The client node 160 assembles the endorsements into a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then delivers the order transaction as a block on the channel to all peer nodes 181-183. Each peer node 181-183 can validate the transaction before committing to the blockchain. For example, the peers can check the endorsement policy to ensure that the correct allocation of specified peers has signed and authenticated the results for the transaction payload 193 (e.g., all specified peers from the mode have validated and approved the submission of the transaction to the blockchain).

[0042] Referring again to Figure 1B , the client node 160 initiates the transaction proposal 191 by building a request and sending the request to a peer node 181, which in this example is an endorser. The client node 160 can include an application program that utilizes a supported software development kit (SDK) that utilizes available APIs to generate the transaction proposal 191. The proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger. The SDK can reduce the package of the transaction proposal 191 into an appropriate architectural format (e.g., protocol buffers over remote procedure calls (RPCs)), and employ the client’s cryptographic credentials to produce a unique signature of the transaction proposal 191.

[0043] In response, the endorsing peer 181 can verify that (a) the transaction proposal 191 is well-formed, (b) the transaction has not been committed in the past (replay attack protection), (c) the signature is valid, and (d) the committer (in this instance, the client node 160) is properly authorized to perform the proposed operation on the channel. The endorsing peer 181 can input the transaction proposal 191 as an argument to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. At this point, however, no update is made to the ledger. In some embodiments, the value set is passed back to the client node 160's SDK as a proposal response 192 along with the endorsing peer 181's signature, which the SDK parses for the payload that the application consumes.

[0044] In response, the client node 160's application checks / verifies the endorsing peer signature and compares the suggested response to determine if the suggested responses are the same. If the chaincode only queries the ledger, the application will check the query response and will typically not submit the transaction to the ordering service node 184. If the client application intends to submit the transaction to the ordering service node 184 to update the ledger, the application determines whether the specified endorsement policy has been satisfied prior to submission. Here, the client can include only one of the multiple parties to the transaction. In this case, each client can have its own endorsing node, and each endorsing node will need to endorse the transaction. This architecture causes the endorsement policy to be enforced by the peers and upheld in the commit validation phase, even if the application chooses not to check the response or otherwise forward unendorsed transactions.

[0045] After successful checking, in a transaction payload step 193, the client node 160 assembles the endorsements into a transaction and broadcasts the transaction proposal 191 and response within the transaction message to the ordering node 184. The transaction can contain the read / write set, the endorsing peer signatures, and the channel ID (e.g., if a specific [off-chain] data store is to be used). The ordering node 184 need not check the full contents of the transaction in order to perform its operations, rather, the ordering node 184 can simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions per channel.

[0046] The block of transactions is delivered from the ordering node 184 to all peer nodes 181-183 on the channel. The transactions 194 within the block are validated to ensure that any endorsement policy is satisfied and to ensure that the ledger state for read sets variables has not changed as the read sets are generated by the transaction execution. The transactions in the block are marked as valid or invalid. Further, in step 195, each peer node 181-183 appends the block to the chain of the channel and, for each valid transaction, the write sets are committed to the current state database. An event is emitted to notify the client application that the transaction (call) has been immutably appended to the chain and whether the transaction was validated or invalidated.

[0047] Referring now to Figure 2 An example blockchain network 200 for privacy protection of auditable transactions according to embodiments of the present disclosure is shown. In some embodiments, the blockchain network includes a private auditable transaction engine 202 operating on a peer 1104. The private auditable transaction engine 202 is a computer program that can generate and / or execute private auditable transactions operating on a permissioned or un-permissioned blockchain network. While the private auditable transaction engine 202 is shown as operating on a peer 1104, the private auditable transaction engine 202 can operate on one or more blockchain nodes 102 (e.g., peer 2 106, peer 3 108, and peer 4 110) within the blockchain network. Further, one or more private auditable transaction engines 202 can reside as separate nodes within the blockchain network and within a particular channel of the blockchain network. Each peer within the blockchain network can act in one or more roles within the private auditable transaction service.

[0048] In some embodiments, the private auditable transaction engine 202 establishes epochs and maintains a world clock associated with each epoch. An epoch is a predetermined amount of time (e.g., one hour, two hours, one day, etc.) that a transaction can fall within. For example, one or more nodes can be responsible for maintaining and updating a world clock associated with the blockchain network. The world clock can be based on a single time zone or a running 24-hour clock initialized at a given time. Further, the peer node responsible for maintaining the world clock can emit a notification at the end of an epoch and update the blockchain accordingly.

[0049] In some embodiments, the private auditable transaction engine 202 can generate a token associated with a transaction. The token generated within a transaction can conceal the owner of the token in methods based on non-pending transaction outputs. For example, a set of tokens from a payee block can be input tokens. The input tokens must be traceable to a previous transaction. The input tokens must be of the same type as the output token to be generated by the private auditable transaction engine 202. The total value of the input tokens must be the same as the output token to be generated. The owner of the input tokens must provide a private key to sign the transaction. The input tokens cannot be spent in a previous transaction.

[0050] In embodiments, the private auditable transaction engine 202 can generate an output token in the following manner. Note that the following example refers to only one output token from one input token for simplicity. More than one token can be generated by the private auditable transaction engine 202 during a transaction. The token can be a piece of data containing the following:

[0051] Token = Commit (owner, type, value, e, transferrable, seed, r)

[0052] where Commit is a concealment component, e is an identifier of the current epoch. Transferrable is a boolean item indicating whether the token is transferrable. Seed is a random seed used to generate a serial number of the token, and r is a blinding factor.

[0053] In embodiments, the private auditable transaction engine 202 can audit tokens. One or more nodes within the blockchain network can assume the role of an auditor (e.g., peer 2 106, peer 3 108). For example, at the end of each epoch, the current token of a user received during each epoch is received. The auditor can check the freshness of the token. Freshness is an indication of whether the token was generated in the most recent epoch that closed. In the direct example above, the auditor will check e in the token. If the auditor determines that the token is fresh, it can update the status of the token to be transferrable. If the auditor determines that the token is not new, it can update the status of the token to be non-transferrable. In some cases, a non-transferrable token is essentially useless and is therefore destroyed.

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

[0055] In embodiments, the private auditable transaction engine 202 can be configured to allow an issuer to add a signature to a message and submit the signed transaction. For example, the message can contain the token, the type, ψ, and pk I (pkI is the public key of the issuer). Thus, a signed transaction can be as follows:

[0056] Tx = (issue, token, owner, type, value, ψ, pk I , σ)

[0057] In embodiments, the private auditable transaction engine 202 can be configured to allow an auditor to verify a transaction by checking that: 1) the issuer is within its permissions to create a "type" token; 2) σ is valid under the public key pk I ; and 3) ψ is a valid zero-knowledge proof.

[0058] In embodiments, the private auditable transaction engine 202 can be configured to generate a transaction that transfers ownership of a token. For example, an input token can be an output token from a previous transaction, where the input token has been re-randomized. For example, an original token without an associated epoch can be as follows: token = commit (owner, type, value, true, —, seed, r), and the original token can be re-randomized as follows: token' = commit (owner', type, value, false, e, seed', r'). In the case where the owner is a new owner, e is the current epoch seed' and r' is a random number. Further, the private auditable transaction engine 202 can generate a new serial number for the randomized token. For example, a token serial number can be as follows: sn = VRF (sk, seed), where VRF is a verifiable pseudo-random function and sk is the owner's key. VRF provides a publicly verifiable proof of correctness of the output.

[0059] In embodiments, the private auditable transaction engine 202 can be configured to generate a zero-knowledge proof by the owner of a token. The zero-knowledge proof can include one or more of the following. token" is a randomization of a valid token, token' was generated correctly (i.e., it preserves the type and value of the token and transferable is set to false, the epoch is the current epoch). owner is a registered user of the blockchain network. sn has been computed correctly (i.e., using the owner's key and the seed encoded in token" to compute sn).

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

[0061] In embodiments, the private auditable transaction engine 202 can be configured to allow a user to account a token at the end of the epoch. For example, for each token owned by the user, it can provide the following to the auditor: owner, value, type, e, seed, and r. The auditor can check that the owner is the user and that the token is the output of a valid transaction that matches the provided data. If the provided data is valid, the auditor can mark the token as checked.

[0062] In embodiments, the private auditable transaction engine 202 can be configured to allow the auditor to change data within a checked token. For example, the auditor can change the presented token from token = submit(owner, value, type, e, false, seed, r) to token' = submit(owner, value, type, —, true, seed, r'), where the epoch is not associated with the token and the Boolean value of whether the token can be transferred to another user is set to true. Additionally, the overall transaction that is accounted for can be as follows: tx = (account, token, token', ψ, σ). Hereby, ψ is a zero-knowledge proof that shows that token" encodes the same information as the token except that it is transferrable and its epoch is edited, and σ is the auditor's signature on the message (account, token, token", ψ).

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

[0064] In embodiments, the private auditable transaction engine 202 can be configured to merge and split transactions and tokens. For example, a user can hide the number of transactions participated in during the current epoch by merging or splitting transactions or tokens. The transaction can have the following properties: the Boolean transferable is set to false, the owner in the output is the same as the input, and the epoch in the output is the same as the input. Hereby, the data associated with any token and transaction will be hidden from the auditor and other participants of the network, as it will only appear as if it was previously owned by the user.

[0065] It should be noted that, as embodied in Figure 2 embodied, the novelty presented is multiplicative.

[0066] Reference is now made to Figure 3, a flowchart of an example method 300 of privacy-protected auditable blockchain transactions is shown. In some embodiments, the method 300 can be performed by a processor, node, and / or peer in a blockchain network, such as the blockchain network 200 of Figure 2 FIG. 1.

[0067] In some embodiments, the method 300 proceeds to step 302, in which the processor encodes a token within a current epoch via a peer (e.g., peer 1 104, peer 2 106, peer 3 108, peer 4 110) within the blockchain architecture 100. For example, the private auditable transaction engine 202 can allow a user to encode an input token received within a current epoch as an output token representing a token received within the current epoch.

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

[0069] In some embodiments, the method 300 proceeds to step 306, in which the auditor node performs an audit check of the received token. For example, the private auditable transaction engine 202 can be configured to allow an auditor node within the blockchain network to perform an audit check of the received token, in which the auditor node can check to determine whether the token is transferable and was generated in a recent epoch.

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

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

[0072] In some embodiments, there is one or more operations of the method 300 that are not depicted for the sake of brevity, as discussed below.

[0073] It should be appreciated that while the present disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present disclosure are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0074] Cloud computing is a model of service delivery 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 a provider of the service. This cloud model can be composed of at least five characteristics, at least three service models, and at least four deployment models.

[0075] Features include the following:

[0076] Broad network access: capabilities are available over a network that is met by a variety of thin or thick client platforms (e.g., mobile phones, laptops, PDAs) that are interconnected via a robust network access mechanism, for example, standard

[0077] Broad network access: capabilities are available over a network that is met by a variety of thin or thick client platforms (e.g., mobile phones, laptops, PDAs) that are interconnected via a robust network access mechanism, for example, standard

[0078] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but can be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0079] Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. Where different consumers potentially share compute resources, the provider's ability to provision and release capabilities is possibly faster than a typical IT department.

[0080] Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability 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 providing transparency for both the provider and consumer of the

[0081] Service Models include the following:

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

[0083] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0084] Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include an operating system and / or application. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0085] Deployment models are as follows:

[0086] Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0087] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-oriented business

[0088] Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

[0089] Hybrid cloud: the cloud infrastructure is a composition of two or more types of cloud (private, community, or public) that remain unique entities but are bound together, creating a hybridity and allowing portability of data and applications.

[0090] A cloud computing environment is service-oriented, focusing on stateless, low-coupling, modularity, and semantic interoperability. The core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0091] Figure 4AThe depicted cloud computing environment 410 is shown. As shown, cloud computing environment 410 includes one or more cloud computing nodes 400 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 400A, desktop computer 400B, laptop computer 400C, and / or automobile computer system 400N can communicate. Nodes 400 can communicate with one another. They can be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 410 to offer infrastructure, platforms and / or software as services with

[0092] This permits cloud computing environment 410 to offer infrastructure, platforms and / or software as services with fine Figure 4A The types of computing devices 400A-N shown in FIG. 4 are intended to be illustrative only and computing nodes 400 and cloud computing environment 410 can communicate with any type of computerized devices over any type of network and / or network addressable connection (e.g., using a web browser).

[0093] Figure 4B A set of functional abstraction layers are shown as provided by cloud computing environment 410 (s Figure 4A It should be understood that the components, layers and functions shown in FIG. 4 are intended to be illustrative only and that embodiments of the present disclosure are not limited thereto. As described below, the following layers and corresponding functionality are provided. Figure 4B

[0094] Hardware and software layer 415 includes hardware and software components. Examples of hardware components include: mainframes 402; RISC (Reduced Instruction Set Computer) architecture based servers 404; servers 406; blade servers 408; storage devices 411; and networks and networking components 412. In some embodiments, software components include network application server software 414 and database software 416.

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

[0096] ​In one example, management layer 440 can provide the functions described below. Resource provisioning 442 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 444 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 446 provides access to the cloud computing environment for consumers and system administrators. Service level management 448 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 450 provide pre-arrangement for, and procurement of, cloud computing resources for future requirement in accordance with an SLA.

[0097] Workloads layer 460 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functionality which can be provided from this layer include: mapping and navigation 462; software development and lifecycle management 464; virtual classroom education delivery 466; data analytics processing 468; transaction processing 470; and auditable privacy preserving blockchain transactions 472.

[0098] Figure 5 is a high-level block diagram of an example computer system 501 according to embodiments of the present disclosure, which can be used to implement one or more of the methods, tools, and modules described herein and any related functionality (e.g., using one or more processor circuits or computer processors of a computer). In some embodiments, the primary components of computer system 501 can 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 can 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.

[0099] Computer system 501 can include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, collectively referred to as CPUs 502 herein. In some embodiments, computer system 501 can include a typical plurality of processors for a relatively large system; however, in other embodiments, computer system 501 can instead be a single CPU system. Each CPU 502 can execute instructions stored in memory subsystem 504 and can include one or more on-board caches.

[0100] The system memory 504 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 522 or cache memory 524. Computer system 501 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 526 can be provided for reading from and writing to non-removable, non-volatile magnetic media (such as a "hard drive"). Although not explicitly shown, a magnetic disk drive can also be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be provided for reading from or writing to a removable, non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media). Additionally, memory 504 can include flash memory, such as a flash drive or flash storage. The memory devices can be connected to the memory bus 503 by one or more data media interfaces. The memory 504 can include at least one program product having at least one program module 530 that is configured to carry out the functions of different embodiments.

[0101] One or more program / utility 528, having at least one set of program modules 530, can be stored in memory 504. The program / utility 528 can include, for example, an operating system, 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 some combination thereof, can include an implementation of a networking environment. Program modules 530 generally carry out the functions or methodologies of different embodiments.

[0102] Although the memory bus 503 is shown in Figure 5 as a single bus structure providing a direct communication path between the CPU 502, the memory subsystem 504, and the I / O bus interface 510, in some embodiments the memory bus 503 can comprise multiple different buses or communication paths, which can be arranged in any of a variety of forms, such as point-to-point links in a hierarchy, multiple hierarchical buses, parallel and redundant paths, or any other appropriate type of configuration. Further, while the I / O bus interface 510 and the I / O bus 508 are shown as single respective units, in some embodiments the computer system 501 can include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Further, while a number of I / O interface units are shown connected to the I / O bus 508, in other embodiments some or all of the I / O devices can be connected directly to one or more system I / O buses, rather than being connected over the I / O bus 508.

[0103] In some embodiments, computer system 501 can be a multi-user large

[0104] It is noted that, Figure 5 It is intended to describe representative main components of an exemplary computer system 501. However, in some embodiments, a single component can perform the functions of more than one Figure 5 component shown in FIG. 5, a different number or configuration of components can be present, and / or different component names can be used, and the computer system 501 can be implemented as part of a different type of system. Figure 5 In some embodiments, computer system 501 can be a multi-user large Figure 5 Figure 5 system, a single-user system, or a server computer, or similar device with little or no direct user interface, but receiving requests from other computer systems (clients). Further, in some embodiments, computer system 501 can be implemented as a desktop, portable, or laptop computer, a tablet computer, a pocket computer, a telephone, a smart phone, a network switch or router, or any other appropriate type of electronic device.

[0105] As discussed in greater detail herein, it is contemplated that some or all of the operations of some embodiments of the methods described herein can be performed in alternative orders or can not be performed at all; furthermore, multiple operations can occur simultaneously or as an internal part of a larger process.

[0106] The present disclosure can be a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0107] A computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, semiconductor, or any other suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include 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 or Flash memory), 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. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0108] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0109] Computer readable program instructions for carrying out operations of the present disclosure can be assembly 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 code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and procedural programming languages such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on a user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0110] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0111] These computer readable program instructions can be provided to a processor of a computer, or other programmable data processing apparatus, to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include, without limitation, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other data storage technology. When the computer readable program instructions are executed by the computer, other programmable data processing apparatus, or other device, a result is produced that includes operations specified in the flowchart and / or block diagram block or blocks. This combination of operations specified both in the flowchart and / or block diagram block or blocks can also be embodied as computer readable program instructions.

[0112] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0113] The flow diagrams and the block diagrams in the drawings are meant as illustrative representations of the architectures, functions, and operations of possible implementations of systems, methods and computer program products according to the present disclosure. It will be understood that each block of the flow diagrams and / or block diagrams, and combinations of blocks in the flow diagrams and / or the block diagrams, can be implemented by

[0114] The description of the different embodiments of the disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technology found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0115] While the present disclosure has been described in terms of specific embodiments, it is anticipated that alterations and modifications will be apparent to those skilled in the art. Accordingly, it is intended that the following claims be interpreted as covering all such alterations and modifications as fall within the true spirit and scope of the present disclosure.

Claims

1. A computer-implemented method for a privacy-preserving, auditable account, the method comprising: generating at least one token, wherein the at least one token is encoded with an owner, a type, a value, a current epoch, a transferability, a seed, and an r value, wherein an epoch is a specific time range, and wherein the r value is a blinding factor; generating a zero-knowledge proof, wherein the zero-knowledge proof indicates that the owner of the at least one token is a registered user of a blockchain network; assembling a first transaction message, wherein the first transaction message includes the at least one token, the zero-knowledge proof, and a public key of an issuer; signing the first transaction message, wherein the signing is based on a private key associated with the public key of the issuer; broadcasting the first transaction message to the blockchain network; transferring ownership of one or more input tokens, wherein the transferring includes consuming the input tokens to be transferred and creating one or more newly created tokens having the same value and type as the input tokens, the one or more newly created tokens encoding the current epoch, a second seed, and a second r value, a new owner, and a bit 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 to show that the one or more input tokens are transferable and the one or more newly created tokens are not transferable; and generating a second anonymously signed transaction for the transaction, wherein the second anonymously signed transaction proves that the signer knows the key of the owner of the one or more input tokens.

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

3. The computer-implemented method of claim 2, wherein, validating includes: determining whether the issuer is authorized to create the type of token 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; and determining whether the zero-knowledge proof is valid. transferring further includes:

4. The computer-implemented method of claim 1, wherein, assembling a second transaction message, the second transaction message including the token serial number, the second zero-knowledge proof, and the one or more newly created tokens; and signing the second transaction message.

5. The computer-implemented method of claim 4, further comprising: validating the second transaction message, wherein validating is based at least in part on determining whether the one or more newly created tokens within the second transaction message have been encoded with the current epoch and are still non-transferable.

6. The computer-implemented method of claim 5, further comprising: in response to validating the second transaction message, publishing a second account transaction marking the one or more newly created tokens as transferable; and the second account transaction includes a zero-knowledge proof and a signature of an auditor.

7. A computer system for a privacy-preserving, auditable account, the system comprising: a memory; and a processor in communication with the memory, the processor configured to perform operations in a method as claimed in any one of claims 1-6. ​ ​ 8. A computer program product for privacy preserving auditable accounts, the computer program product comprising program instructions executable by a processor to cause the processor to perform operations in the method of any of claims 1-6.

Images