Apparatus, method and computer program (selective audit process for privacy-preserving blockchain)

Abstract

To provide a selective audit process for a privacy-preserving blockchain.SOLUTION: An example operation may include: identifying at least one first blockchain transaction stored in a blockchain ledger based on a first identifier of a user that has submitted the first blockchain transaction; retrieving a secret key shared between an auditor node and the user; decrypting, via the auditor node, ciphertexts included in the first blockchain transaction based on the secret key; recovering a second user identifier of the user, and identifying, via the auditor node, a second blockchain transaction including the second user identifier of the user stored in the blockchain ledger.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] A centralized platform stores and maintains data in a single location. This location is often a central computer, such as a cloud computing environment, web server, mainframe computer, or similar. Information stored on a centralized platform is typically accessible from multiple different points. Multiple users or client workstations can work on the centralized platform simultaneously, for example, based on a client / server configuration. Because a centralized platform is in a single location, it is easy to manage, maintain, and control, especially for security purposes. Within a centralized platform, storing all data in a single location also means that there is only one primary record for a given set of data, thus minimizing data redundancy. [Overview of the Initiative] [Problems that the invention aims to solve]

[0002] [Means for solving the problem]

[0003] One exemplary embodiment provides a device comprising a processor configured to identify one or more first blockchain transactions stored in the blockchain ledger based on a first user identifier of a user who submitted a first blockchain transaction, to obtain a private key shared between an audit node and the user, to decrypt the ciphertext contained in the first blockchain transaction based on the private key via the audit node, to recover the user's second user identifier, and to identify a second blockchain transaction containing the user's second user identifier stored in the blockchain ledger via the audit node.

[0004] Another exemplary embodiment provides a method comprising the steps of: identifying one or more first blockchain transactions stored in the blockchain ledger based on a first identifier of a user who submitted a first blockchain transaction; obtaining a private key shared between an audit node and the user; decrypting ciphertext contained in the first blockchain transaction based on the private key via the audit node; recovering a second user identifier of the user; and identifying a second blockchain transaction containing the second user identifier of the user stored in the blockchain ledger via the audit node.

[0005] Another exemplary embodiment provides a computer-readable storage medium that, when read by the processor, causes the processor to perform the following steps: identify one or more first blockchain transactions stored in the blockchain ledger based on a first identifier of a user who submitted a first blockchain transaction; obtain a private key shared between an audit node and the user; decrypt the ciphertext contained in the first blockchain transaction based on the private key via the audit node; and recover a second user identifier of the user and, via the audit node, identify a second blockchain transaction containing the second user identifier of the user stored in the blockchain ledger. [Brief explanation of the drawing]

[0006] [Figure 1] This figure shows a blockchain computing environment including an anonymous blockchain ledger that can be selectively audited, according to an exemplary embodiment.

[0007] [Figure 2A] This figure shows an exemplary blockchain architecture configuration according to an exemplary embodiment. [Figure 2B] This diagram shows the blockchain transaction flow between nodes according to an exemplary embodiment.

[0008] [Figure 3A] A diagram showing an authorized network according to an exemplary embodiment.

[0009] [Figure 3B] A diagram showing another authorized network according to an exemplary embodiment.

[0010] [Figure 3C] A diagram showing an unauthorized network according to an exemplary embodiment.

[0011] [Figure 4A] A diagram showing a process for selectively auditing a user's transactions on a blockchain ledger according to an exemplary embodiment. [Figure 4B] A diagram showing a process for selectively auditing a user's transactions on a blockchain ledger according to an exemplary embodiment. [Figure 4C] A diagram showing a process for selectively auditing a user's transactions on a blockchain ledger according to an exemplary embodiment.

[0012] [Figure 5] A diagram showing a method for selectively auditing a user's transactions on a blockchain ledger according to an exemplary embodiment.

[0013] [Figure 6A] A diagram showing an exemplary system configured to perform one or more operations described herein according to an exemplary embodiment.

[0014] [Figure 6B] A diagram showing another exemplary system configured to perform one or more operations described herein according to an exemplary embodiment.

[0015] [Figure 6C]This figure shows another exemplary system configured to utilize smart contracts, according to an exemplary embodiment.

[0016] [Figure 6D] This figure shows yet another exemplary system configured to utilize blockchain, according to an exemplary embodiment.

[0017] [Figure 7A] This figure illustrates the process of adding a new block to a distributed ledger, according to an exemplary embodiment.

[0018] [Figure 7B] This figure shows the data content of a new data block according to an exemplary embodiment.

[0019] [Figure 7C] This figure shows a blockchain for digital content according to an exemplary embodiment.

[0020] [Figure 7D] This figure shows a block that may represent the structure of a block in a blockchain, according to an exemplary embodiment.

[0021] [Figure 8A] This figure shows an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an exemplary embodiment.

[0022] [Figure 8B] This figure shows an exemplary quantum-secure blockchain according to an exemplary embodiment.

[0023] [Figure 9] This figure shows an exemplary system supporting one or more of the exemplary embodiments. [Modes for carrying out the invention]

[0024] It will be readily apparent that the components described herein and shown in the drawings can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-temporary computer-readable media, and systems, as shown in the accompanying drawings, is not intended to limit the scope of the claimed application, but merely represents selected embodiments.

[0025] The features, structures, or characteristics described throughout this specification may be combined or omitted in any preferred manner in one or more embodiments. For example, the use of the phrases “exemplary embodiments,” “some embodiments,” or other similar wording throughout this specification means that certain features, structures, or characteristics described in relation to an embodiment may be included in at least one embodiment. Thus, the appearance of “exemplary embodiments,” “some embodiments,” “other embodiments,” or other similar wording throughout this specification does not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or omitted in any preferred manner in one or more embodiments. Furthermore, any connection between elements in the figures may allow unidirectional communication, bidirectional communication, or both, even if the indicated connection is represented by a unidirectional or bidirectional arrow. Also, any device shown in the drawings may be a different device. For example, if it is shown that a mobile device is transmitting information, a wired device may also be used to transmit the information.

[0026] Furthermore, while the term “message” may be used in the description of embodiments, this application can be applied to many types of networks and data. Additionally, while certain types of connections, messages, and signaling may be shown in exemplary embodiments, this application is not limited to specific types of connections, messages, and signaling.

[0027] Exemplary embodiments provide methods, systems, components, non-temporary computer-readable media, devices or networks, or combinations thereof, relating to an auditable distributed ledger, and in some embodiments, an auditable blockchain ledger where transaction content is encrypted (e.g., anonymous, confidential, etc.). According to various embodiments, a unique identification scheme can be incorporated into the blockchain network / software and can be used to create a unique (i.e., different) user identifier for each user each time the user submits another blockchain transaction to the blockchain ledger. The unique user identifier can be used as the transaction ID for the blockchain transaction. Thus, the unique user identifier does not need to be encrypted while the transaction content (e.g., payment, exchange, transfer, etc.) is encrypted. As a non-limiting example, the unique user identifier may be stored in the header of an unencrypted blockchain block, while the content of the blockchain transaction may be stored in the data section of an encrypted blockchain block.

[0028] In various embodiments, a user may first create their own user identifier and submit it to a blockchain, for example, an audit registration service that assigns audit nodes to users / clients. In this example, the blockchain network may contain multiple audit nodes, and each user may be assigned one of the audit nodes as an auditor. For example, a user may create an initial user identifier based on a random number, but embodiments are not limited to this. The initial user identifier may be shared with off-chain audit nodes. When a user generates a first transaction, the user can use the initial user identifier as the identifier for the first blockchain transaction.

[0029] Furthermore, the user may also generate the next user identifier to be used based on the randomization (or pseudo-randomization) of the initial user identifier based on some randomization scheme previously agreed upon between the user and the audit node. Thus, the next user identifier will be different from the initial user identifier, but the audit node can further prove that this is the correct next user identifier for the user by performing a pseudo-randomization of the initial user identifier in parallel. The next user identifier may also be stored along with the blockchain transaction labeled with the initial user identifier. In other words, the user may leak the next / successor user identifier of a subsequent blockchain transaction (i.e., submitted later in time) within the current blockchain transaction (i.e., submitted before the subsequent blockchain transaction).

[0030] In one embodiment, the application utilizes a distributed database (such as a blockchain), which is a distributed storage system, comprising multiple nodes communicating with one another. The distributed database includes an append-only immutable data structure similar to a distributed ledger, which allows for the maintenance of records among parties who do not trust each other. These 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 reaching a consensus among the distributed peers. For example, a peer may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain on the blocks. This process, in order as necessary to maintain consistency, forms a ledger. In various embodiments, permissioned blockchains, permissionless blockchains, or both can be used. In public blockchains or permissionless blockchains, anyone can participate without a specific identity. Public blockchains may include native cryptocurrencies and can use consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide secure transactions between groups of entities that share a common purpose, such as businesses exchanging funds, goods, information, and similar items, but do not fully trust each other.

[0031] This application is adapted to a distributed storage scheme and can utilize a blockchain to run arbitrary programmable logic called "smart contracts" or "chaincode." In some cases, there may be specialized chaincode for management functions and parameters, called system chaincode. This application can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof properties of the blockchain database and the basic agreement between nodes called endorsements or endorsement policies. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, while unendorsed transactions are ignored. An endorsement policy allows the chaincode to specify endorsers of a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed and verified. After verification, the transaction enters an ordering phase, where an ordered sequence of endorsed transactions, grouped into blocks, is generated using a consensus protocol.

[0032] This application utilizes nodes, which are communication entities in a blockchain system. A “node” can perform logical functions, meaning that multiple nodes of different types can run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control the nodes in various ways. Nodes may include different types, such as client nodes or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node that receives transactions submitted by clients, commits the transactions, and maintains the state and copies of the blockchain transaction ledger. Peers can also act as endorsers, but this is not a requirement. An ordering service node, or orderer, is a node that performs communication services for all nodes, commits transactions, and implements delivery guarantees such as broadcasting to each of the peer nodes in the system when modifying the blockchain's world state, which is typically another name for the initial blockchain transaction containing control and setup information.

[0033] This application utilizes a ledger, which is an ordered, fraud-proof record of all state transitions in a blockchain. State transitions can arise from chaincode calls (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (e.g., peer nodes) can maintain a copy of the ledger. Transactions may result in a set of asset key-value pairs committed to the ledger as one or more operands, such as create, update, delete, and so on. The ledger comprises a blockchain (also called a chain) used to store immutable, ordered records within blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0034] This application utilizes 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. The block header contains the hash of the block's transactions, as well as the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered 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 that occurred on the chain before it, making it possible to ensure that all peer nodes are in a consistent and trustworthy state. The chain can be stored in a peer node file system (i.e., local, connected storage, cloud, etc.) and efficiently support the append-only nature of the blockchain workload.

[0035] The current state of the immutable ledger represents the most recent values ​​of all keys contained in the chain transaction log. Because the current state represents the most recent key values ​​known in the channel, it is sometimes called the world state. Chaincode calls execute transactions against the current state data of the ledger. To streamline these interactions between chaincodes, the most recent key values ​​may be stored in a state database. The state database can simply be an indexed view into the chain's transaction log and can therefore be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) when a peer node starts up and before any transactions are accepted.

[0036] In exemplary embodiments, a blockchain network may be able to protect the privacy of its users without disclosing the keys to decrypt such a blockchain ledger by implementing an encrypted blockchain ledger. However, a privacy-protected blockchain ledger can be selectively decrypted and audited by an audit node based on a unique identification scheme described herein. That is, even if the basic content of a blockchain transaction can be kept secret from other users and blockchain peers on the blockchain ledger, an authorized auditor can still audit the transaction content in a selective manner, decrypting only the transactions of a specific user without having to decrypt the entire blockchain ledger. Thus, auditors can save considerable time and computational resources by selectively performing the decryption process to identify only the transactions associated with a specific user, rather than decrypting the entire blockchain ledger.

[0037] Figure 1 shows a blockchain computing environment 100 including a selectively auditable blockchain ledger 110, according to an exemplary embodiment. Referring to Figure 1, the blockchain ledger 110 may be a public blockchain available to all users, or a permissioned blockchain where users need to obtain permission to access it. The blockchain ledger 110 may be anonymous in that transaction content may be encrypted, and anonymous signatures may be used instead of traditional signatures to sign blockchain transactions.

[0038] The blockchain ledger 110 may be managed by a network of multiple blockchain peers (not shown) that can store distributed copies of the blockchain ledger 110 among themselves. Blockchain peers may be implemented via web servers, virtual machines, cloud platforms, databases, user devices, and similar. Users may transact with each other to transfer digital values ​​via the blockchain ledger 110. In the example in Figure 1, user 112 participated in two transactions, including a first blockchain transaction with user 114 and a second blockchain transaction with user 116. Both the first and second blockchain transactions may be stored in the blockchain ledger 110 in an anonymous manner so that neither user involved in each transaction can be identified.

[0039] In an exemplary embodiment, the blockchain computing environment 100 also includes a registration service 120 for registering new users to an audit process performed by one or more audit nodes 130. In some cases, the blockchain computing environment 100 may include multiple audit nodes 130. In this case, the registration service 120 may assign one audit node to each user, for example, assigning audit node 132 to user 112.

[0040] Audits can be performed at any time by the audit node 132 on blockchain transactions submitted by user 112 and stored in the anonymous blockchain ledger 110. When performing an audit, the audit node 132 may obtain the initial user identifier of user 112 registered with the registration service 120. Here, the initial user identifier can be used as the transaction ID of the initial blockchain transaction generated by the user and submitted to the anonymous blockchain 110 by user 112. In this case, the initial user identifier may not be encrypted, but the transaction content is encrypted. Thus, instead of decrypting the entire ledger and scanning the entire ledger for such identifiers, the audit node 132 can easily discover blockchain transactions based on identifiers (e.g., from a state database, index, dictionary, etc.).

[0041] In this example, the initial transaction submitted by user 112 is the transfer of digital assets from user 112 to user 114. According to various embodiments, the initial blockchain transaction may include ciphertext containing encrypted data, which is encrypted based on a private key shared between user 112 and audit node 132, for example, during registration to registration service 120. In this example, audit node 132 may decrypt the ciphertext of the initial blockchain transaction to reveal various attributes of the blockchain transaction, such as the next user identifier to be used by user 112 when submitting the next blockchain transaction. For example, user 112 may receive the initial user identifier and use a random function or randomization process to create the next user identifier based on randomization. The next user identifier can be encrypted with the private key K shared between audit node 132 and user 112. Thus, audit node 132 may be able to decrypt the ciphertext in the initial blockchain transaction using the shared private key and recover the next user identifier, but other participants on blockchain ledger 110 cannot decrypt the next user identifier.

[0042] By deciphering the initial blockchain transaction, the audit node 132 learns the identifier for the user's next blockchain transaction. In the example in Figure 1, the next blockchain transaction could be the second blockchain transaction submitted to the blockchain ledger 110 by user 112, which involves a transfer of value from user 112 to user 116. This process is then repeated by the audit node 132 with the second blockchain transaction, allowing it to recover the third user identifier from the ciphertext of the second blockchain transaction. Furthermore, this process can be iteratively executed / repeated until the audit node 132 reaches the next user identifier that has not yet been used. This indicates that the audit node 132 has reached the last / most recent blockchain transaction added to the blockchain ledger 110 by user 112. In other words, user 112 can add identifiers pointing to future / subsequent blockchain transactions to each blockchain transaction, thereby providing an audit trail to the anonymous blockchain ledger 110.

[0043] Typically, in privacy-preserving token transfers, the sender's identity is kept secret along with the content (type, value, and recipient). Proof on the blockchain is enabled by zero-knowledge proofs, which help validators verify the accuracy of a transaction / transfer contained within the blockchain transaction content without accessing the content in plaintext or knowing its sender. However, while user privacy is crucial for token transfer applications, the need for auditability is increasing to comply with established regulations and facilitate proper operation on anonymous blockchain networks. Existing methods for auditability require auditors to either actively participate in the formation of transactions (i.e., always be online) or indiscriminately decode all transactions at the time of audit, as auditors do not know which transactions are under audit until they have decoded the ledger and identified all transactions.

[0044] An exemplary embodiment provides an extension to a privacy-preserving token system tailored to permissioned blockchains. This extension allows non-participating auditors to identify transactions under audit during an audit without deciphering all transactions, thanks to the unique identification mechanism described herein. The privacy-preserving token system combines confidential commitments and zero-knowledge proofs to enable blockchain participants to verify transactions without accessing the content. Most notably, it conceals the type and value of the tokens to which sensitive assets are transferred. Nevertheless, the relationship between the sender and receiver is still disclosed.

[0045] There are existing blockchain networks, such as ZEROCASH, that address this problem by using zk-SNARK and Merkle trees in a way that transactions do not reveal any information about their underlying transfers. However, with regard to auditing, the solution is very limited, requiring auditors to either decipher the entire ledger or be constantly online. Both of these options consume considerable resources and time. An exemplary embodiment addresses the problem by providing a narrowed trail on the blockchain through a user of constantly changing, iteratively generated identifiers that allow each transaction to be uniquely identified. Furthermore, each transaction contains an identifier for the next transaction that the user will submit. Thus, a user can disclose a trail through a user identifier that points forward, contained in the transaction content of the current blockchain transaction. In other words, a transaction created using the i-th user identifier may contain ciphertext, which, upon deciphering, reveals the next user identifier (i.e., user identifier i+1). Thus, a user can sequentially reveal the ordering of transaction trails, and audit nodes can selectively and sequentially discover, decipher, and audit only the user's blockchain transactions.

[0046] A Zerocash token is a confidential commitment of the following information (uid, type, value) using a uid, which is an identifier for the value's owner. A Zerocash transaction is UTXO-based, meaning it consists of a set of tokens to be consumed (input) and a set of new tokens to be created (output). A Zerocash transaction is said to be valid if it satisfies the following conditions: (i) the input can be traced back to a valid past transaction, (ii) the type of the input is the same as the type of the output, (iii) the sum of the inputs equals the sum of the outputs, (iv) the owner of the inputs has approved the transaction, and (v) the inputs have not been consumed previously (to prevent double-spending).

[0047] Zerocash uses zk-SNARK to indicate that the aforementioned conditions are met. Specifically, it combines privacy-protected membership proof and serial numbers to ensure that only valid tokens are consumed and to prevent double-spending. Membership proof is implemented using a Merkle tree that stores valid tokens and the zk-SNARK protocol to indicate whether a token belongs to it or not. Meanwhile, the serial number is calculated as a function of a random seed (selected at token creation) and the owner's private key so that tokens always generate the same serial number. Therefore, if a user consumes the same token twice, this is easily detected.

[0048] In an exemplary embodiment, user U in the system is associated with the credentials cred0=commit(uid,pk(u),pksig(u),pk(a),k,id0,r0), where uid is U's unique identifier, (pk(u),pksig(u)) is U's public key, pk(a) is the public key of U's auditor A, k is a private key shared between U and A, and id0 is a unique identifier known only to U and A.

[0049] Here, "user" may refer to user 112 shown in Figure 1, or a similar entity. During registration, the registration authority RA, such as registration service 120 in Figure 1, checks that cred0 is calculated correctly, submits the registration transaction, and adds cred0 to the ledger. Currently, Zerocash transactions have been expanded as follows: • Encrypts the transmitted information using the private key K. • Commitment credi=(uid,pk(u),pksig(u),pk(a),K,idi,ri) Identifier idi-1 • Encrypt the ciphertext of idi under the private key K • A zero-knowledge proof that the ledger contains a commitment credi-1=(uid,pk(u),pksig(u),pk(a),K,idi-1,ri-1) • Zero-knowledge proof that the ciphertext was correctly computed.

[0050] In this example, assuming that user U and auditor A share the private key K and initial identifier id0, auditor A can recognize valid transactions from U.

[0051] In various embodiments, users submit transfer transactions to the blockchain. Each user is assigned an auditor upon registration. The auditor is authorized by the blockchain network to inspect all user transactions and access their contents. The registration authority is a trusted body that registers user credentials. The registration authority ensures that user credentials are unique and that any given auditor is assigned only to users within its jurisdiction.

[0052] In an exemplary embodiment, a registration request from user U may include the following: Unique identifier uid, Two public keys,

number

number

number

number

[0053] Upon receiving such a request from U, the agency RA performs the following checks:

[0054] public key

number

[0055]

number

[0056]

number

[0057] Check whether a zero-knowledge proof is valid.

[0058] If all checks are successful, the latter will be pk (u) and

number

number

[0059] token

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0060] Finally, user U sends a message

number

number

[0061] The resulting transfer transaction is

number

number

number

number

[0062] To examine U's transaction, assigned auditor A is given the shared secret key K and the initial identifier.

number

number

number

number

number

number

[0063] If A's authority to audit user U is revoked, the RA will be able to complete the transaction.

number

number

number

number

number

[0064] Figure 2A shows a blockchain architecture configuration 200 according to an exemplary embodiment. Referring to Figure 2A, the blockchain architecture 200 may include a group of specific blockchain elements, for example, blockchain nodes 202. Blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown for illustrative purposes only). These nodes participate in several activities, such as the process of adding and verifying blockchain transactions (consensus). One or more of the blockchain nodes 204-210 can endorse transactions based on an endorsement policy and can provide ordering services to all blockchain nodes within the architecture 200. Blockchain nodes can initiate blockchain authentication and attempt to write to the immutable ledger of the blockchain stored in the blockchain layer 216, a copy of which may also be stored in the underlying physical infrastructure 214. A blockchain configuration can be created according to a customized configuration requested by the participants and may include one or more applications 224 linked to an Application Programming Interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.) that maintains its own state, controls its own assets, and can receive external information. This can be installed on all blockchain nodes 204-210 by deploying it as a transaction and adding it to the distributed ledger.

[0065] The blockchain-based or platform 212 may include various layers of underlying physical computing infrastructure that can be used to receive and store blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and new transactions, and to provide access to auditors seeking access to data entries. The blockchain layer 216 may expose interfaces that process program code and provide access to the virtual execution environments necessary to engage with the physical infrastructure 214. Cryptographic trust services 218 can be used to prove transactions, such as asset exchange transactions, and to keep information confidential.

[0066] The blockchain architecture configuration in Figure 2A allows for the processing and execution of program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided. Code 220 can control blockchain assets. For example, code 220 can store and transfer data, and nodes 204-210 can execute smart contracts and associated chaincode in the form of other code elements subject to conditional execution or execution. As a non-limiting example, smart contracts can be created to perform reminders, updates or changes, other notifications subject to updates, or a combination thereof. Smart contracts can themselves be used to identify authority and access requirements and rules related to the use of the ledger. For example, a smart contract (or chaincode that executes the logic of a smart contract) can read blockchain data 226 that can be processed by one or more processing entities (e.g., virtual machines) contained in the blockchain layer 216 to generate results 228, including alerts, responsibility decisions, and similar, within a complex service scenario. The data or information described herein can be obtained using the physical infrastructure 214.

[0067] Smart contracts are created through high-level applications and programming languages ​​and can be written to blocks in a blockchain. A smart contract may include executable code, or a combination thereof, that is registered, stored, or replicated on a blockchain (e.g., a decentralized network of blockchain peers). A transaction is the execution of smart contract code that can be executed in response to the fulfillment of conditions associated with the smart contract. Executing a smart contract can trigger a trusted correction to the state of the digital blockchain ledger. Corrections to the blockchain ledger resulting from smart contract execution can be automatically replicated across a decentralized network of blockchain peers through one or more consensus protocols.

[0068] Smart contracts can write data to the blockchain in the form of key-value pairs. Furthermore, 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 into one or more blocks within the blockchain. This code can be used to create temporary data structures on a virtual machine or other computing platform. Data written to the blockchain can be made public, encrypted and kept private, or both. Temporary data used / generated by smart contracts is held in memory by the provided execution environment and deleted once the data required by the blockchain has been identified.

[0069] Chaincode may include code interpretation of smart contracts. For example, chaincode may include a packaged, deployable version of the logic within a smart contract. As described herein, chaincode can be program code deployed on a computing network, executed and validated collectively by chain validators during a consensus process. Chaincode may receive a hash and retrieve a hash from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chaincode sends an authentication key to the requested service. Chaincode may write to blockchain data associated with cryptographic details.

[0070] Figure 2B shows an example of a blockchain transaction flow 250 between nodes of a blockchain in an exemplary embodiment. Referring to Figure 2B, the transaction flow may include a client node 260 that sends a transaction proposal 291 to an endosing peer node 281. The endosing peer 281 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read by the chaincode (read set), and a set of key / values ​​written by the chaincode (written set). Here, the endosing peer 281 may decide whether or not to endorse the transaction proposal. The proposal response 292, if accepted, is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block to all peers 281-283 on the channel. Before committing to the blockchain, each peer 281-283 can verify the transaction. For example, a peer may check the endorsement policy to ensure that the correct allocation of the specified peer has signed the result and authenticated the signature against the transaction payload 293.

[0071] Referring again to Figure 2B, the client node initiates transaction 291 by constructing and sending a request to the endorser peer node 281. The client 260 may include an application that utilizes a supported Software Development Kit (SDK) that leverages an API available for generating a transaction proposal. This proposal is a request to call a chaincode function that can read data from or write to the ledger (i.e., write a new key-value pair for an asset), or both. The SDK acts as a shim for packaging the transaction proposal into a properly designed format (e.g., protocol buffer over remote procedure call (RPC)) and can obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0072] In response, the Endosing Peer Node 281 may certify that (a) the transaction proposal is properly formed, (b) the transaction has not been submitted before (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) has the appropriate authority to perform the proposed action on its channel. The Endosing Peer Node 281 may receive the transaction proposal input as an argument to the called chaincode function. The chaincode is then executed against the current state database, generating a transaction result including response values, read sets, and write sets. However, no updates are made to the ledger at this point. In 292, the set of values, along with the Endosing Peer Node 281's signature, is returned to the client 260's SDK as proposal response 292, and the SDK parses the payload to be consumed by the application.

[0073] In response, the client 260 application inspects / certifies the endosing peer signature and compares it to the proposed response to determine if the proposed responses are the same. If the chaincode only queries the ledger, the application inspects the query response and does not typically submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines before submission whether the specified endorsement policy has been met (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, the client may include only one of several parties in the transaction. In this case, each client may have its own endosing node, and each endosing node must endorse the transaction. This architecture ensures that even if the application chooses not to inspect the response or otherwise forwards an unendorsed transaction, the endorsement policy is still enforced by the peer and maintained during the commit verification phase.

[0074] After the inspection is successful, in step 293, client 260 assembles the endorsement into a transaction proposal and broadcasts the transaction proposal and response in the transaction message to ordering node 284. The transaction may include read / write sets, endorsing peer signatures, and channel IDs. Ordering node 284 does not need to inspect the entire contents of the transaction to perform its operation; instead, it may simply receive transactions from all channels in the network, order them chronologically channel by channel, and create blocks of transactions for each channel.

[0075] The block is distributed from ordering node 284 to all peer nodes 281-283 on the channel. The data section within the block may be validated to ensure that the endorsement policy is met and that the state of the ledger of read set variables has not changed since the read set was generated by the transaction execution. Furthermore, in step 295, each peer node 281-283 adds the block to the channel chain, and a write set is committed to the current state database for each valid transaction. Events may be issued to notify client applications that a transaction (call) has been immutably added to the chain, and to notify whether the transaction has been enabled or disabled.

[0076] Figure 3A shows an example of a permissioned blockchain network 300, which features a decentralized, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction to the permissioned blockchain 304. In this example, a transaction could be a deployment, call, or query and could be issued through a client-side application utilizing an SDK, directly through an API, etc. The network may provide access to regulators 306, such as auditors. The blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients". Auditors may be restricted to querying the ledger only, while clients may be granted permission to deploy, call, and query certain types of chaincode.

[0077] Blockchain developer 310 can write chaincode and client-side applications. Blockchain developer 310 can deploy chaincode directly to the network through an interface. To include credentials from a conventional data source 312 in the chaincode, developer 310 can access the data using an out-of-band connection. In this example, blockchain user 302 connects to permissioned blockchain 304 through peer node 314. Before proceeding to any transaction, peer node 314 obtains the user's enrollment certificate and transaction certificate from Certificate Authority 316, which manages the user's role and permissions. In some cases, blockchain users must possess these digital certificates to conduct transactions on permissioned blockchain 304. On the other hand, a user attempting to utilize the chaincode may need to prove their credentials at the conventional data source 312. To verify the user's authority, the chaincode can use an out-of-band connection to this data through the conventional processing platform 318.

[0078] Figure 3B shows another example of a permissioned blockchain network 320, characterized by a decentralized, decentralized peer-to-peer architecture. In this example, blockchain user 322 can submit transactions to the permissioned blockchain 324. In this example, transactions could be deployments, calls, or queries and could be issued through client-side applications utilizing an SDK, directly through an API, etc. The network may provide access to regulators 326, such as auditors. The blockchain network operator 328 manages member permissions, such as registering regulators 326 as “auditors” and blockchain users 322 as “clients”. Auditors may be restricted to querying the ledger only, while clients may be granted permission to deploy, call, and query certain types of chaincode.

[0079] Blockchain developer 330 writes the chaincode and client-side applications. Blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include credentials from a conventional data source 332 in the chaincode, developer 330 can access the data using an out-of-band connection. In this example, blockchain user 322 connects to the network through peer node 334. Before proceeding to any transaction, peer node 334 obtains the user's enrollment certificate and transaction certificate from Certificate Authority 336. In some cases, blockchain users must possess these digital certificates to conduct transactions on permissioned blockchain 324. On the other hand, a user attempting to utilize the chaincode may need to prove their credentials at the conventional data source 332. To verify the user's authority, the chaincode can use an out-of-band connection to this data through a conventional processing platform 338.

[0080] In some embodiments, the blockchain described herein may be a permissionless blockchain. In contrast to permissionless blockchains, which require permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user may initiate interaction with the network by creating a personal address and submitting transactions to add entries to the ledger. Furthermore, all parties may choose to run nodes on the system and use mining protocols that help prove transactions.

[0081] Figure 3C illustrates the process 350 of a transaction processed by a permissionless blockchain 352 including multiple nodes 354. A sender 356 wishes to send a payment or any other form of value (e.g., a certificate, medical record, contract, goods, service, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and receiver device 358 may have a digital wallet (associated with blockchain 352) that provides user interface control and display of transaction parameters. In response, the transaction is broadcast to the nodes 354 across blockchain 352. Depending on the network parameters of blockchain 352, the nodes certify the transaction (360) based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this may include proof of the identity of the parties involved. The transaction may be certified immediately or queued with other transactions, and the node 354 determines whether the transaction is valid based on the set of network rules.

[0082] In structure 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by mining nodes between nodes 354. Mining nodes may utilize additional software specifically for mining and creating blocks in the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may contain a header, a pointer or reference to the hash of the header of the previous block in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure and independent chain for the block.

[0083] Before adding a block to the blockchain, it must be verified. Verification in the permissionless blockchain 352 may include proof of work (PoW), which is the solution to a puzzle derived from the block's header. Although not shown in the example in Figure 3C, another process for verifying a block is proof of stake. Unlike proof of work, where an algorithm rewards miners who solve a mathematical problem, in proof of stake, the creator of a new block is selected in a deterministic manner based on wealth, also defined as "stake." A similar proof is then performed by the selected / elected node.

[0084] In Mining364, nodes attempt to solve a block by making incremental changes to a single variable until the solution satisfies the network's overall goal. This creates a Proof-of-Work (PoW) mechanism, which guarantees the correct solution. In other words, a potential solution must prove that computing resources were exhausted to solve the problem. In some permissionless blockchains, miners may receive rewards in the form of value (e.g., coins) for correctly mining blocks.

[0085] Here, along with the chain of blocks, the PoW process makes it extremely difficult to modify the blockchain because an attacker would have to modify all subsequent blocks in order to accept the modification of one block. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks increases. In distributed 366, successfully verified blocks are distributed through the permissionless blockchain 352, and all nodes 354 add the blocks to the majority chain, which is the auditable ledger of the permissionless blockchain 352. In addition, the value of a transaction submitted by the sender 356 is deposited into or otherwise transferred to the digital wallet of the recipient device 358.

[0086] Figures 4A–4C illustrate a process for selectively auditing user transactions on a blockchain ledger 430 according to exemplary embodiments. In these examples, the blockchain ledger 430 may be an encrypted / anonymous blockchain ledger, but embodiments are not limited thereto. Referring to Figure 4A, a process 400A is shown that identifies the user's initial blockchain transaction 440 on the blockchain ledger 430. In this example, the user audit process is triggered, for example, in response to a new blockchain transaction (not shown) submitted by the user, or in response to some other condition such as an explicit request, a timing threshold, a new block threshold, etc.

[0087] In this example, the audit node 420 is assigned by the registration service 410 to audit a user. Here, the registration service 410 does not complete the registration unless the audit node 420 acknowledges receipt of the initial identifier provided by the user during the registration process. The initial user identifier can be used as the transaction identifier of the initial blockchain transaction 440 submitted to the blockchain ledger 430. The audit node 420 can quickly find the location (i.e., block number) of the initial blockchain transaction 440 labeled with the initial user identifier from, for example, a state database, index, dictionary, or similar. In this case, the user's initial blockchain transaction 440 is stored in block 432 of the blockchain ledger 430.

[0088] Figure 4B shows process 400B for decrypting the initial blockchain transaction 440 and recovering the second user identifier (i.e., user ID #2). Referring to Figure 4B, audit node 420 can decrypt various contents within the initial blockchain transaction 440, including transaction content 442 (e.g., recipient, value, type, etc.), and the ZKP 444 by the user guarantees a ciphertext 446 that correctly encodes various information about the user and the transaction, including the next user identifier (user ID #2) and similar. Audit node 420 can decrypt the ciphertext 446 using a shared secret key shared between audit node 420 and the user and recover the next user identifier.

[0089] Figure 4C shows process 400C of audit node 420, which retrieves the user's second blockchain transaction 450 from blockchain ledger 430 based on the second user identifier restored in process 400B in Figure 4B. Referring to Figure 4C, audit node 420 identifies block 434 containing the second blockchain transaction 450, which has a transaction identifier equal to the second user identifier restored in Figure 4B. In this example, block 434 is a block stored in blockchain ledger 430 after block 432, which holds the initial blockchain transaction 440. In other words, the second blockchain transaction 450 has not yet been added to blockchain ledger 430 and will eventually be stored later, but the user encodes a pointer to the second blockchain transaction 450 in the initial blockchain transaction 440.

[0090] Figure 5 illustrates a method 500 for selectively auditing user transactions on a blockchain ledger, according to an exemplary embodiment. In non-limiting examples, method 500 may be performed by off-chain or external entities such as blockchain peers, servers, or third-party authentication services, user devices, blockchain peers, trusted services, or similar entities. Referring to Figure 5, in 510, the method may include the step of identifying a first blockchain transaction stored in the blockchain ledger based on a first identifier of the user who submitted the first blockchain transaction. The blockchain ledger may be a public or private blockchain ledger. In some embodiments, the blockchain ledger may be anonymized, allowing the use of both encrypted transaction content and anonymous signatures rather than identifying information.

[0091] In step 520, the method may include the step of obtaining a private key shared between the audit node and the user. In step 530, the method may include the step of decrypting the ciphertext contained in the first blockchain transaction based on the private key via the audit node to recover the user's second identifier. In step 540, the method may include the step of identifying a second blockchain transaction containing the user's second user identifier stored in the blockchain ledger via the audit node.

[0092] In some embodiments, the decryption step may further include the step of decrypting the transaction details within the first blockchain transaction based on the private key and the step of verifying the transaction details against predetermined audit criteria. In some embodiments, the verification step may include the step of proving that there are no other blockchain transactions stored in the blockchain ledger having the first user identifier. In some embodiments, the verification step may include the step of verifying zero-knowledge proofs (ZKPs) submitted by users included in the first blockchain transaction.

[0093] In some embodiments, the first and second user identifiers may be certifiablely generated based on the user's unique user identifier and the user's key, respectively. In some embodiments, the method may further include the step of decrypting the ciphertext contained in the second blockchain transaction based on the private key to recover the third user identifier. In some embodiments, the method may further include the step of determining, via an audit node, that no blockchain transaction having the third user identifier is stored in the blockchain ledger and terminating the audit process in response to the determination. In some embodiments, the first and second blockchain transactions are signed with anonymous signatures.

[0094] Figure 6A shows an exemplary system 600, including a physical infrastructure 610 configured to perform various operations according to an exemplary embodiment. Referring to Figure 6A, the physical infrastructure 610 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), and may perform any of the operation steps 608 (within module 612) included in any of the exemplary embodiments. Steps / operations 608 may include one or more of the embodiments described or depicted, and may represent output written to one or more smart contracts 630 or the blockchain 620, or both, or written information read from them. The physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memory or wireless communication devices, or a combination thereof. Furthermore, modules 612 and 614 may be the same module.

[0095] Figure 6B shows another exemplary system 640 configured to perform various operations according to an exemplary embodiment. Referring to Figure 6B, system 640 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620) and may perform any of the operation steps 608 (within module 612) included in any of the exemplary embodiments. Steps / operations 608 may include one or more of the embodiments described or depicted and may represent output written to one or more smart contracts 630 or the blockchain 620, or both, or written information read from them. The physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memory or wireless communication devices, or a combination thereof. Furthermore, modules 612 and 614 may be the same module.

[0096] Figure 6C shows an exemplary system configured to utilize a smart contract configuration between contract parties, and an intermediary server configured to enforce the smart contract clauses on the blockchain, according to an exemplary embodiment. Referring to Figure 6C, configuration 650 may represent a communication session, asset transfer session, or process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 or 656, or both. The execution, operation, and results of the smart contract execution may be managed by the server 654. The content of smart contract 630 may require a digital signature by one or more entities 652 and 656 that are parties to the smart contract transaction. The results of the smart contract execution may be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, which may reside on one or more computers, servers, processors, memory, or wireless communication devices, or a combination thereof.

[0097] Figure 6D shows a system 660 including a blockchain, according to an exemplary embodiment. Referring to the example in Figure 6D, an Application Programming Interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincode) and data (e.g., a distributed ledger, etc.). In this example, the API gateway 662 is a common interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., a server 654). Here, the server 654 is a blockchain network peer component that holds copies of the world state and distributed ledger, allowing clients 652 and 656 to query data about the world state and, depending on the smart contract 630 and endorsement policy, submit transactions into the blockchain network where the endosing peer executes the smart contract 630.

[0098] The embodiments described above may be implemented in hardware, in computer programs executed by a processor, in firmware, or in a combination thereof. Computer programs may be implemented on computer-readable media such as storage media. For example, computer programs may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, hard disks, removable disks, compact disk read-only memory ("CD-ROM"), or any other form of storage media known in the art.

[0099] An exemplary storage medium may be coupled to a processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage medium may reside within an application-specific integrated circuit ("ASIC"). Alternatively, the processor and storage medium may exist as separate components.

[0100] Figure 7A illustrates the process 700 of a new block being added to the distributed ledger 720 in an exemplary embodiment, and Figure 7B illustrates the content of a new data block structure 730 of the blockchain in an exemplary embodiment. Referring to Figure 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, or 713, or a combination thereof. A client may be an instruction received from any source to perform an activity on the blockchain 720. For example, a client may be an application acting on behalf of a requester such as a device, person, or entity proposing a transaction on the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain the state of the blockchain network and a copy of the distributed ledger 720. The blockchain network may have various types of blockchain nodes / peers, including endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that prove endorsements, verify transactions, and commit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can act as endorser nodes, committer nodes, or both.

[0101] The distributed ledger 720 contains a blockchain and a state database 724 (current world state) that maintains the current state of blockchain 722, storing immutable, ordered records in blocks. There may be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for the channel it is a member of. Blockchain 722 is a transaction log structured as hash-linked blocks, each containing a sequence of N transactions. Blocks may contain various components as shown in Figure 7B. The block links (indicated by the arrows in Figure 7A) can be generated by adding the hash of the previous block's header to the block header of the current block. In this way, all transactions on blockchain 722 are ordered, collectively, and cryptographically linked, preventing tampering with blockchain data without breaking the hash links. Furthermore, because of the links, the most recent block on blockchain 722 represents all transactions that occurred before it. Blockchain 722 can be stored in a peer file system (local or connected storage) that supports append-only blockchain workloads.

[0102] The current state of blockchain 722 and distributed ledger 722 can be stored in state database 724. Here, the current state data represents the latest values ​​of all keys that have ever been included in the chain transaction log of blockchain 722. Chaincode calls execute transactions against the current state of state database 724. To make these interactions between chaincodes extremely efficient, the latest values ​​of all keys are stored in state database 724. State database 724 may contain an indexed view into the transaction log of blockchain 722 and can therefore be regenerated from the chain at any time. State database 724 can be automatically restored (or generated as needed) upon peer invocation before a transaction is accepted.

[0103] An endosing node receives a transaction from a client and endorses the transaction based on the simulation results. The endosing node holds a smart contract that simulates the transaction proposal. When an endosing node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endosing node to the client application indicating the endorsement of the simulated transaction. How a transaction is endorsed depends on an endorsement policy that may be specified in the chaincode. An example of an endorsement policy is that "a majority of endosing peers must endorse the transaction." Different channels may have different endorsement policies. Endorsed transactions are forwarded by the client application to the ordering service 710.

[0104] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers the blocks to the committing peers. For example, the ordering service 710 may start a new block when a transaction threshold is reached, when a timer times out, or when another state is reached. In the example in Figure 7A, blockchain node 712 is a committing peer that has received a new data block 730 of new data to be stored on blockchain 720. The first block of the blockchain may be called a genesis block, which contains information about the blockchain, its members, the data stored within it, etc.

[0105] The ordering service 710 may consist of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may accept endorsed transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed so that a specific implementation of “ordering” (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0106] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to the state database 724 are valid when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism best suited to their network.

[0107] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer verifies the transactions in the new data block 730 by checking that the read and write sets still match the current world state in the state database 724. Specifically, a committing peer can determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 724. Once a committing peer verifies the transaction, the transaction is written to blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read and write sets. If the transaction fails, i.e., if a committing peer finds that the read and write sets do not match the current world state in the state database 724, the transaction ordered to the block is still included in that block, but is marked as invalid, and the state database 724 is not updated.

[0108] Referring to Figure 7B, a new data block 730 (also called a data block) stored in the blockchain 722 of the distributed ledger 720 may contain multiple data segments, such as a block header 740, block data 750 (block data section), and block metadata 760. It should be understood that the various blocks and their contents illustrated, such as the new data block 730 and its contents shown in Figure 7B, are merely examples and are not intended to limit the scope of exemplary embodiments. In a conventional block, the data section may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750.

[0109] The new data block 730 may also include a link to the previous block (for example, on blockchain 722 in Figure 7A) within its block header 740. Specifically, the block header 740 may include a hash of the header of the previous block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, and similar. The block number of the new data block 730 is unique and can be assigned in various orderings, such as zero-based increments / sequences.

[0110] According to various embodiments, the block data 750 may also store attributes 752 associated with the blockchain transaction described herein, such as encrypted transaction content that can only be decrypted with a shared secret key between the client and the audit node, a ZKP containing various proofs, ciphertext that, upon decryption, reveals another user identifier, and so on. Attributes 752 include one or more of the steps, features, processes, or actions, or combinations thereof, described or depicted herein. Thus, attributes 752 can be stored in the immutable log of the block on the distributed ledger 720. Some of the advantages of storing attributes 752 in the blockchain are reflected in the various embodiments disclosed and depicted herein. In Figure 7B, attributes 752 are shown in the block data 750, but they could be located in the block header 740 or block metadata 760.

[0111] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array). Metadata fields may include the signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions within the block, the last surviving offset of the ordering service that orders the blocks, and similar. The signature, last constituent block, and orderer metadata may be added by the ordering service 710. Meanwhile, the block committer (e.g., blockchain node 712) may add validity / invalidity information based on endorsement policies, read / write set proofs, and similar. The transaction filter may include a byte array equal in size to the number of transactions contained in the block data 750, and verification codes that identify whether a transaction is valid or invalid.

[0112] Figure 7C illustrates an embodiment of the blockchain 770 for digital content according to the embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable and additive aspects of the blockchain act as safeguards to protect the integrity, validity, and authenticity of the digital content, whether legal proceedings or evidence are considered to be subject to permissible rules, or whether the presentation and use of the digital information is appropriately used in other settings of other interest. In this case, the digital content may be referred to as digital evidence.

[0113] Blockchains can be formed in various ways. In one embodiment, digital content is contained within the blockchain itself and can be accessed from within the blockchain itself. For example, each block in a blockchain may store a hash value of reference information (e.g., header, value, etc.) along with its associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing previous blocks. This can be illustrated as follows: Block 1 Block 2...Block N Hash value 1 Hash value 2...Hash value N Digital Content 1 Digital Content 2...Digital Content N

[0114] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain may store the encrypted hash of the content of each block without any digital content. The digital content may be stored in a separate storage area or memory address, associated with the hash value of the original file. The other storage area could be the same storage device used to store the blockchain, a different storage area, or even another relational database. The digital content of each block can be referenced or accessed by retrieving or querying the hash value of the block of interest and then searching for the block with the value in the storage area where the actual digital content is stored. This operation can be performed, for example, by a database gatekeeper. This can be shown as follows: Blockchain storage Block 1 Hash Value Block 1 Hash Value...Content · · · Block N hash value Block N hash value...content

[0115] In an exemplary embodiment of FIG. 7C, the blockchain 770 includes several blocks 7781, 7782, … 778N that are cryptographically linked in an ordered sequence, where N≧1. N The encryption used to link the blocks 7781, 7782, … 778N can be either some keyed or keyless hash functions. N In one embodiment, the blocks 7781, 7782, … 778N are subject to a hash function that generates an n-bit alphanumeric output (n is 256 or another number) from an input based on the information within the block. Examples of such hash functions include, but are not limited to, SHA type (SHA is short for Secured Hash Algorithm) algorithms, Merkle-Damgård algorithms, HAIFA algorithms, Merkle tree algorithms, non-base algorithms, and collision-resistant PRF algorithms. N In another embodiment, the blocks 7781, 7782, …, 778N can be cryptographically linked by a function different from a hash function. For illustrative purposes, the following description is made with reference to a hash function, for example, SHA-2. N

[0116] Each block 7781, 7782, …, 778N of the blockchain includes a header, a version of the file, and a value. As a result of being hashed in the blockchain, the header and the value are different for each block. In one embodiment, the value can be included in the header. As will be described in more detail below, the version of the file can be the original file or a different version of the original file. N

[0117] The first block of the blockchain, 7781, is called the genesis block and contains the header 7721, the original file 7741, and the initial value 7761. The hash scheme used for the genesis block, and indeed for all subsequent blocks, may be different. For example, all the information in the first block 7781 may be hashed all at once, or each or part of the information in the first block 7781 may be hashed individually, and then the individually hashed parts may be hashed.

[0118] Header 7721 may contain one or more initial parameters, which may include, for example, a version number, timestamp, nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. Header 7721 can be generated automatically (e.g., by blockchain network management software) or manually by blockchain participants. Other blocks in the blockchain 7782-778 N Unlike the headers within the main block, header 7721 in the genesis block does not reference the previous block simply because there is no previous block.

[0119] The original file 7741 within the genesis block may be data captured by a device, either processed or unprocessed, before being included in the blockchain. The original file 7741 is received from a device, media source, or node through the system interface. The original file 7741 is associated with metadata, which may be generated, for example, manually or automatically, by a user, device, or system processor, or a combination thereof. The metadata is associated with the original file 7741 and may be included in the first block 7781.

[0120] The value 7761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, one or more unique attributes may include the hash value of the original file 7741, the metadata of the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes: 1) The calculated SHA-2 hash value of the original file 2) Source device ID 3) Start timestamp of the original file 4) The original file's initial storage location 5) The blockchain network member ID of the software currently controlling the original file and associated metadata.

[0121] Other blocks in the blockchain: 7782-778 N It also has a header, file, and value. However, unlike the first block 7721, the headers of the other blocks 7722-772 N Each of these contains the hash value of the previous block. The hash value of the previous block can be just the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, a trace can be performed block by block, tracing back from the Nth block to the genesis block (and the associated original file), as shown by arrow 780, to establish an auditable and immutable chain of control.

[0122] Headers 7722-772 in other blocks N Each of these may contain other information, such as version number, timestamp, nonce, root information, difficulty, consensus protocol and / or corresponding file and / or other parameters or information associated with the blockchain in general.

[0123] Files 7742-774 in other blocks NThis may be, for example, identical to the original file, or a modified version of the original file within the genesis block, depending on the type of operation performed. The type of operation performed may differ from block to block. The operation may include any modifications to the file within the previous block, such as editing the file's information or otherwise changing the file's content, deleting information from the file, or adding or attaching information to the file.

[0124] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing actions related to the blockchain or associated metadata, or both, of the file. Processing involving file analysis may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0125] Other blocks within other blocks 7762-776 N Each value is unique and differs as a result of the process performed. For example, a value within any one block corresponds to an updated version of a value in the previous block. The update is reflected in the hash of the block to which the value was assigned. Therefore, the values ​​of a block provide an indicator of which process was performed in that block, and it is also possible to trace back through the blockchain to the original file. This tracking confirms the chain of file management across the entire blockchain.

[0126] For example, consider a case where, to protect the identity of the person whose file is displayed, a portion of the file in the previous block is edited, blocked out, or pixelated. In this case, the block containing the edited file contains metadata associated with the edited file, such as how the edit was performed, who performed the edit, and the timestamp when the edit was made. This metadata may be hashed to form a value. Because the metadata of a block is different from the information hashed to form a value in the previous block, the values ​​are different from each other and can be decoded and reconstructed.

[0127] In one embodiment, the value of the previous block may be updated (for example, by calculating a new hash value) when one or more of the following occur, thereby forming the value of the current block. In this exemplary embodiment, the new hash value may be calculated by hashing all or part of the information shown below. a) A new SHA-2 hash value if the file has been processed in any way (e.g., if the file has been edited, copied, tampered with, accessed, or any other action has been performed on it). b) New storage location for files c) New metadata identified and associated with the file d) Transfer of access to or control of files from one blockchain participant to another blockchain participant

[0128] Figure 7D shows an embodiment of a block that may represent the structure of a block within blockchain 790 according to one embodiment. i Header 772 i , file 774 i , and value 776 i Includes.

[0129] Header 772 i This is the previous block. i-1This includes the hash value of the previous block and additional reference information, which may be any of the types of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). Of course, all blocks, except the genesis block, refer to the hash of the previous block. The hash value of the previous block may be only the hash of the header in the previous block, or it may be the hash of all or part of the information in the previous block, including files and metadata.

[0130] File 774 i This includes multiple data in order, such as Data 1, Data 2, ..., Data N. The data are tagged with metadata Metadata 1, Metadata 2, ..., Metadata N, which describe the content or characteristics associated with the data, or both. For example, the metadata for each data may include information indicating a timestamp of the data, information for processing the data, keywords indicating a person or other content indicated within the data, or information indicating the validity and content of the entire file, or a combination thereof, and other features that may help establish the use of digital evidence, as described in relation to the embodiments discussed below. In addition to metadata, each data includes references to previous data REF1, REF2, ..., REF1 to prevent tampering, gaps within the file, and sequential referencing through the file. N It can be tagged as follows.

[0131] Once metadata is assigned to data (for example, through a smart contract), it cannot be tampered with without altering the hash, making invalidation easily identifiable. Thus, metadata creates a data log of information that blockchain participants can access for use.

[0132] Value 776 i This is a hash value or other value calculated based on any of the aforementioned types of information. For example, any given block iIn this case, the value of the block may be updated to reflect the actions performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, control or access, an identifier, or the transfer of any other actions or information added. Although the values ​​within each block are shown as separate from the metadata of the file and header data, in another embodiment, some or all of the values ​​may be based on this metadata.

[0133] Once blockchain 770 is formed, at any given time, the immutable management chain of the file can be obtained by querying the blockchain for the transaction history of the values ​​of the entire block. This query, or tracking procedure, may begin by deciphering the values ​​of the most recent block it contains (e.g., the last (Nth) block), and then continue deciphering the values ​​of other blocks until the genesis block is reached and the original file is restored. Deciphering may also include deciphering the headers and files in each block, as well as the associated metadata.

[0134] Decryption is performed based on the type of encryption used for each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, when asymmetric encryption is used, a blockchain participant or a processor in the network may generate a public-private key pair using a predetermined algorithm. The public and private keys are related to each other through some mathematical relationship. The public key may be made public and distributed to function as an address for receiving messages from other users, such as an IP address or home address. The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can prove it using the sender's public key. In this way, the recipient can verify that only the sender could have sent this message.

[0135] Generating a key pair can be analogous to creating an account on the blockchain, but there's no actual need to register anywhere. Furthermore, every transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner (within the scope of permissions determined by the smart contract) can track and process files on the blockchain.

[0136] Figures 8A and 8B illustrate additional examples of blockchain use cases that may be incorporated and used herein. Specifically, Figure 8A shows an example of blockchain 800 for storing machine learning (artificial intelligence) data. Machine learning relies on vast amounts of historical data (or training data) to build predictive models for accurately predicting new data. Machine learning software (e.g., neural networks) can often sift through millions of records to discover counterintuitive patterns.

[0137] In the example in Figure 8A, the host platform 820 builds and deploys a machine learning model for predictive monitoring of asset 830. Here, the host platform 820 could be a cloud platform, industrial server, web server, personal computer, user device, and similar. Asset 830 could be any type of asset (e.g., machinery or equipment, etc.), such as aircraft, locomotives, turbines, medical machinery and equipment, oil and gas equipment, boats, ships, vehicles, and similar. As another example, asset 830 could be an intangible asset such as stocks, currencies, digital coins, insurance, or similar.

[0138] Using blockchain 810, both the machine learning model training process 802 and the prediction process 804 based on the trained machine learning model can be significantly improved. For example, in 802, historical data can be stored on blockchain 810 by the asset 830 itself (or through an intermediary not shown), rather than requiring data scientists / engineers or other users to collect the data. This can significantly reduce the collection time required by the host platform 820 when training the prediction model. For example, smart contracts can be used to transfer data directly and securely from its original location to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can send data directly from the asset to individuals who will use the data to build machine learning models. This makes it possible to share data among assets 830.

[0139] The collected data can be stored on Blockchain 810 based on a consensus mechanism. The consensus mechanism involves authorized nodes to ensure that the recorded data is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can improve both the frequency and accuracy of the recorded data in certain cases (i.e., supply chain, healthcare, logistics, etc.).

[0140] Furthermore, training a machine learning model on the collected data may require rounds of refinement and testing by the host platform 820. Each round may be based on additional data or data not previously considered useful for expanding the machine learning model's knowledge. In 802, the host platform 820 may store various training and testing steps (and the data associated with them) on blockchain 810. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) may be stored on blockchain 810. This provides verifiable evidence of how the model was trained and the data used to train the model. Additionally, when the host platform 820 finally realizes the trained model, the resulting model may be stored on blockchain 810.

[0141] After the model is trained, it can be deployed to a live environment where it can ultimately make predictions / decisions based on the execution of the trained machine learning model. For example, in 804, the machine learning model may be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, medical equipment, and the like. In this example, data fed back from asset 830 can be input to the machine learning model and used to make event predictions such as failure events, error codes, and the like. Decisions made by the execution of the machine learning model on host platform 820 can be stored on blockchain 810 to provide auditable / provable evidence. In a non-limiting example, the machine learning model may predict future failures / outbreaks for a portion of asset 830 and generate alerts or notifications for replacing parts. The data underlying this decision can be stored by host platform 820 on blockchain 810. In one embodiment, features or actions or both that are described or depicted herein, or both, can be performed on or with respect to blockchain 810.

[0142] New transactions on the blockchain can be grouped into a new block and appended to an existing hash value. This is then encrypted, creating a new hash for the new block. This is then added to the next list of transactions, for example, when a transaction is encrypted. The result is a chain of blocks, each containing the hash value of all previous blocks. A computer that stores these blocks periodically compares the hash values ​​to ensure they all match. A computer that does not match discards the record causing the problem. This method is suitable for ensuring blockchain fraud prevention, but it is not foolproof.

[0143] One way to exploit a loophole in this system is for a malicious user to alter the list of transactions to their advantage, thus preventing the hash from being changed. This can be done by brute force, in other words, by modifying the record, encrypting the result, and checking if the hash value is the same. If they don't match, they try again and again until a matching hash is found. Blockchain security is based on the idea that ordinary computers can only perform this kind of brute-force attack on completely unrealistic timescales, such as the age of the universe. In contrast, quantum computers are much faster (thousands of times faster) and therefore pose a much greater threat.

[0144] Figure 8B shows Example 850 of Quantum Secure Blockchain 852, which implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can use QKD to prove each other's identity. This involves transmitting information using quantum particles such as photons, which cannot be copied without destruction by an eavesdropper. In this way, senders and receivers through the blockchain can verify each other's identity.

[0145] In the example in Figure 8B, there are four users: 854, 856, 858, and 860. Each pair of users can share the private key 862 (i.e., QKD) with each other. In this example, there are four nodes, so there are six pairs of nodes, and therefore the QKD AB QKD AC QKD AD QKD BC QKD BD , and QKD CD Six different secret keys, including 862, are used. Each pair can create a QKD by transmitting information using quantum particles such as photons, which cannot be copied by an eavesdropper without destruction. In this way, the user pairs can verify each other's identities.

[0146] The operation of blockchain 852 is based on two steps: (i) creating a transaction, and (ii) building a block that aggregates the new transaction. A new transaction can be created in the same way as in a conventional blockchain network. Each transaction may include information about the sender, recipient, creation time, the amount (or value) being transferred, a list of reference transactions justifying that the sender has the funds for the operation, and similar information. This transaction record is then sent to all other nodes and placed into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from 854-860) authenticate the transaction by providing a shared secret key 862 (QKD). This quantum signature can be attached to every transaction, making tampering extremely difficult. Each node checks the entries against its local copy of blockchain 852 to prove that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0147] Instead of performing a traditional mining process on blocks, blocks can be created in a decentralized manner using a broadcast protocol. Within a predetermined timeframe (e.g., seconds, minutes, hours), the network can apply the broadcast protocol to unconfirmed transactions, thereby achieving a Byzantine consensus regarding the correct version of a transaction. For example, each node may possess private values ​​(transaction data for that particular node). In the first round, nodes send their private values ​​to each other. In subsequent rounds, nodes communicate information received from other nodes in the previous round. Here, honest nodes can create a complete set of transactions within a new block. This new block can be added to blockchain 852. In one embodiment, features or actions, or both, described or depicted herein, can be performed on or with respect to blockchain 852.

[0148] Figure 9 shows an exemplary system 900 supporting one or more exemplary embodiments described or depicted herein, or both. System 900 comprises a computer system / server 902 that can operate in a number of other general-purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments or configurations or combinations thereof that may be suitable for use with the computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and similar ones.

[0149] The computer system / server 902 can be described in the general context of computer system executable instructions, such as program modules, that are executed by the computer system. Generally, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system / server 902 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may reside on storage media of both local and remote computer systems, including memory storage devices.

[0150] As shown in Figure 9, the computer system / server 902 within the cloud computing node 900 is represented in the form of a general-purpose computing device. The components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, system memory 906, and a bus that connects various system components, including the system memory 906, to the processor 904.

[0151] The term "bus" refers to one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use one of various bus architectures. Examples, but not limited to, such architectures include the Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Expansion ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Components Interconnect (PCI) bus.

[0152] The computer system / server 902 typically includes various computer system-readable media. Such media can be any available media accessible by the computer system / server 902 and include both volatile and non-volatile media, and removable and non-removable media. In one embodiment, the system memory 906 implements the flow diagram of the other figure. The system memory 906 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 910 or cache memory 912, or both. The computer system / server 902 may further include other removable / non-removable, volatile / non-volatile computer system storage media. As just one example, the storage system 914 may be provided for reading to and writing to a non-removable non-volatile magnetic medium (not shown, commonly referred to as a “hard drive”). Not shown, a magnetic disk drive may be provided for reading to and writing to a removable non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive may be provided for reading to or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such cases, each can be connected to the bus by one or more data media interfaces. As further illustrated and described below, the memory 906 may include at least one program product having a set of program modules (e.g., at least one) configured to perform functions of various embodiments of the application.

[0153] A program / utility 916 having a set (at least one) of program modules 918 can be stored in memory 906, as well as, but not limited to, 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 may include an implementation of a networking environment. The program modules 918 generally perform functions or methodologies, or both, of various embodiments of the application as described herein.

[0154] As will be understood by those skilled in the art, aspects of this application may be embodied as systems, methods, or computer program products. Accordingly, aspects of this application may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware embodiments, all of which may be commonly referred to herein as “circuits,” “modules,” or “systems.” Furthermore, aspects of this application may take the form of computer program products embodied in one or more computer-readable media in which computer-readable program code is embodied.

[0155] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, which enable a user to interact with the computer system / server 902, or any device (e.g., a network card, modem, etc.) or a combination thereof, which enable the computer system / server 902 to communicate with one or more other computing devices. Such communication can be performed via the I / O interface 924. Furthermore, the computer system / server 902 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 926. As shown in the figure, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that other hardware or software components, or combinations thereof, may be used in conjunction with the computer system / server 902, although these are not shown. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0156] While at least one exemplary embodiment of the system, method, and non-temporary computer-readable medium is shown in the accompanying drawings and described in the preceding detailed description, it should be understood that this application is not limited to the disclosed embodiments and that numerous reconfigurations, modifications, and substitutions are possible as described and defined in the following claims. For example, the functions of the various diagrammed systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include transmitters, receivers, or pairs of both. For example, all or part of the functions performed by individual modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at different points in time in relation to various events inside or outside the modules or components. Also, information transmitted between various modules may be transmitted between modules via at least one of data networks, the internet, voice networks, Internet Protocol networks, wireless devices, wired devices, or via multiple protocols, or both. Also, messages transmitted or received by any of the modules may be transmitted or received directly, or via one or more of the other modules, or both.

[0157] Those skilled in the art will understand that the “System” can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or other suitable computing device, or combination of devices. Presenting the above functions as being performed by the “System” is not intended to limit the scope of this application in any way, but rather to provide examples of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein can be implemented in localized and distributed forms consistent with computing technologies.

[0158] It should be noted that some of the system functions described herein are presented as modules to more specifically emphasize the independence of implementation. For example, modules may be implemented as hardware circuits including custom very large-scale integrated circuits (VLSI) or off-the-shelf semiconductors such as gate arrays, logic chips, transistors, or other discrete components. Modules may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or similar.

[0159] Modules can also be implemented, at least partially, in software for execution by various types of processors. For example, an identified unit of executable code may have one or more physical or logical blocks of computer instructions, which may be organized as, for example, objects, procedures, or functions. Nevertheless, the executable file of an identified module does not need to be physically located together, but may have heterogeneous instructions stored in different locations, and when logically combined, it constitutes a module and achieves the defined purpose of the module. Furthermore, modules can be stored on computer-readable media, which may be, for example, hard disk drives, flash devices, random access memory (RAM), tape, or any other such medium used to store data.

[0160] In fact, a module of executable code can be a single instruction or many instructions, and can be distributed across several different code segments, between different programs, and even across several memory devices. Similarly, operational data can be identified and represented within a module herein, embodied in any suitable form, and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or distributed across different locations including different storage devices, or simply exist at least partially as electronic signals on a system or network.

[0161] It will be readily apparent that the components of this application can be arranged and designed in a wide variety of different configurations, as generally described herein and shown in the figures. Therefore, the detailed description of embodiments is not intended to limit the scope of the claimed application, but merely to represent selected embodiments of this application.

[0162] Those skilled in the art will readily understand that the above can be carried out in a different sequence of steps, with hardware elements of a different configuration than those disclosed, or both. Therefore, although this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations are also apparent.

[0163] While preferred embodiments of this application have been described, it should be understood that the embodiments described are merely illustrative, and the scope of this application should be defined solely by the appended claims, considering the full range of equivalents and modifications to the embodiments (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. 1. An apparatus comprising: Identifying a first blockchain transaction stored in a blockchain ledger based on a first user identifier of a user who submitted the first blockchain transaction; Obtaining a private key shared between an audit node and the user; decrypting, via the audit node, a ciphertext included in the first blockchain transaction based on the private key to recover a second user identifier of the user; and identifying, via the audit node, second blockchain transactions stored in the blockchain ledger that include the second user identifier of the user.

2. 2. The apparatus of claim 1, wherein the processor is further configured to decrypt transaction details in the first blockchain transaction based on the private key and verify the transaction details against predetermined audit criteria.

3. 3. The apparatus of claim 2, wherein the processor is configured to certify that no other blockchain transactions are stored in the blockchain ledger with the first user identifier.

4. 3. The apparatus of claim 2, wherein the processor is configured to verify a zero-knowledge proof (ZKP) submitted by the user included in the first blockchain transaction.

5. The apparatus of claim 1 , wherein the first user identifier and the second user identifier are provably generated based on the user's unique user identifier and the user's key, respectively.

6. 2. The apparatus of claim 1, wherein the processor is further configured to decrypt a ciphertext included in the second blockchain transaction based on the private key to recover a third user identifier.

7. 7. The apparatus of claim 6, wherein the processor is further configured to determine, via the audit node, that no blockchain transactions having the third user identifier are stored in the blockchain ledger, and to terminate the audit process in response to the determination.

8. 8. The apparatus of claim 1, wherein the first blockchain transaction and the second blockchain transaction are signed with anonymous signatures.

9. 1. A method comprising: identifying a first blockchain transaction stored in a blockchain ledger based on a first user identifier of a user who submitted the first blockchain transaction; obtaining a private key shared between an audit node and the user; decrypting, via the audit node, a ciphertext included in the first blockchain transaction based on the private key to recover a second user identifier of the user; identifying, via the audit node, a second blockchain transaction stored in the blockchain ledger that includes the second user identifier of the user; A method for providing the above.

10. 10. The method of claim 9, wherein the decrypting further comprises: decrypting transaction details in the first blockchain transaction based on the private key; and verifying the transaction details against predetermined audit criteria.

11. 11. The method of claim 10, wherein the verifying step comprises proving that no other blockchain transactions having the first user identifier are stored in the blockchain ledger.

12. 11. The method of claim 10, wherein the verifying comprises verifying a zero-knowledge proof (ZKP) submitted by the user included in the first blockchain transaction.

13. The method of claim 9 , wherein the first user identifier and the second user identifier are provably generated based on the user's unique user identifier and the user's key, respectively.

14. 10. The method of claim 9, wherein the method further comprises decrypting a ciphertext included in the second blockchain transaction based on the private key to recover a third user identifier.

15. 15. The method of claim 14, further comprising: determining, via the audit node, that no blockchain transactions having the third user identifier are stored in the blockchain ledger; and terminating an audit process in response to the determination.

16. 16. The method of claim 9, wherein the first blockchain transaction and the second blockchain transaction are signed with anonymous signatures.

17. When read by a processor, the processor: Identifying a first blockchain transaction stored in a blockchain ledger based on a first user identifier of a user who submitted the first blockchain transaction; obtaining a secret key shared between an audit node and the user; decrypting, via the audit node, a ciphertext included in the first blockchain transaction based on the private key to recover a second user identifier of the user; and identifying, via the audit node, second blockchain transactions stored in the blockchain ledger that include the second user identifier of the user.

18. 20. The computer program product of claim 17, wherein the decrypting step further comprises: decrypting transaction details in the first blockchain transaction based on the private key; and verifying the transaction details against predetermined audit criteria.

19. 20. The computer program product of claim 18, wherein the verifying step comprises: proving that there are no other blockchain transactions stored in the blockchain ledger that have the first user identifier; and verifying a zero-knowledge proof (ZKP) submitted by the user that is included in the first blockchain transaction.

20. 20. The computer program product of claim 17, wherein the first user identifier and the second user identifier are provably generated based on the user's unique user identifier and the user's key, respectively.

Images