Privacy protection status reference

Abstract

Example operations may include one or more of: receiving a blockchain transaction including a state reference for an unspent transaction output (UTXO); determining whether the UTXO is included within a first subset of transactions on a blockchain ledger based on a zero-knowledge (ZK) proof included in the state reference; determining whether the UTXO is included within a second subset of transactions on the blockchain ledger based on a hash value included in the state reference; and, in response to determining that the UTXO is not included in either the first or second subset of transactions, committing the blockchain transaction including the state reference to the blockchain ledger via a blockchain peer.

Description

[Background technology]

[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, a web server, a mainframe computer, etc. Information stored on a centralized platform is typically accessible from multiple different points. Multiple users or client workstations can work simultaneously on the centralized platform, for example, based on a client / server configuration. Due to its single location, a centralized platform is easier to manage, maintain, and control, especially for security purposes. Within a centralized platform, data redundancy is minimized, as the single storage location of all data also implies that a given set of data has only one primary record. Summary of the Invention

[0002] One example embodiment provides an apparatus comprising: a memory configured to store a blockchain ledger; and a processor configured to do one or more of: receive a blockchain transaction including a state reference to an unspent transaction output (UTXO); determine, based on a zero-knowledge (ZK) proof included in the state reference, whether the UTXO is included in a first subset of transactions on the blockchain ledger; determine, based on a hash value included in the state reference, whether the UTXO is included in a second subset of transactions on the blockchain ledger; and, in response to determining that the UTXO is not included in either the first or second subset of transactions, commit the blockchain transaction including the state reference to the blockchain ledger.

[0003] Another example embodiment provides a method comprising one or more of: receiving a blockchain transaction including a state reference to an unspent transaction output (UTXO); determining, based on a zero-knowledge (ZK) proof included in the state reference, whether the UTXO is included within a first subset of transactions on a blockchain ledger; determining, based on a hash value included in the state reference, whether the UTXO is included within a second subset of transactions on the blockchain ledger; and, in response to determining that the UTXO is not included in either the first or second subset of transactions, committing the blockchain transaction including the state reference to the blockchain ledger via a blockchain peer.

[0004] A further exemplary embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following steps: receive a blockchain transaction including a state reference to an unspent transaction output (UTXO); determine, based on a zero-knowledge (ZK) proof included in the state reference, whether the UTXO is included in a first subset of transactions on a blockchain ledger; determine, based on a hash value included in the state reference, whether the UTXO is included in a second subset of transactions on the blockchain ledger; and, in response to determining that the UTXO is not included in either the first or second subset of transactions, commit the blockchain transaction including the state reference to the blockchain ledger via a blockchain peer. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 illustrates a blockchain network according to an example embodiment.

[0006] [Figure 1B] FIG. 1 illustrates a blockchain transaction generated according to an unspent transaction output (UTXO) model, according to an example embodiment.

[0007] [Figure 1C] FIG. 1 illustrates a blockchain transaction including a state reference, according to an example embodiment.

[0008] [Figure 2A] FIG. 1 illustrates an example blockchain architecture configuration according to an example embodiment.

[0009] [Figure 2B] FIG. 1 illustrates a blockchain transaction flow between nodes, according to an example embodiment.

[0010] [Figure 3A] FIG. 1 illustrates a permissioned network according to an example embodiment.

[0011] [Figure 3B] FIG. 1 illustrates another permissioned network according to an example embodiment.

[0012] [Figure 3C] FIG. 1 illustrates an open-ended network according to an example embodiment.

[0013] [Figure 4A] FIG. 1 illustrates a process for generating a privacy-preserving state reference, according to an example embodiment.

[0014] [Figure 4B] FIG. 4B illustrates an example of data values ​​included with the state references of FIG. 4A, according to an example embodiment.

[0015] [Figure 4C] FIG. 1 illustrates a timeline for processing a blockchain transaction, according to an example embodiment.

[0016] [Figure 4D] FIG. 1 illustrates a privacy-preserving search process according to an example embodiment.

[0017] [Figure 5] FIG. 1 illustrates a method for validating state references in blockchain transactions, according to an example embodiment.

[0018] [Figure 6A] FIG. 1 illustrates an example system configured to perform one or more operations described herein, according to an example embodiment.

[0019] [Figure 6B] FIG. 1 illustrates another example system configured to perform one or more operations described herein, according to an example embodiment.

[0020] [Figure 6C] FIG. 1 illustrates a further example system configured to utilize smart contracts, according to example embodiments.

[0021] [Figure 6D] FIG. 1 illustrates yet another example system configured to utilize blockchain, according to an example embodiment.

[0022] [Figure 7A] FIG. 1 illustrates a process by which a new block is added to a distributed ledger, according to an example embodiment.

[0023] [Figure 7B] FIG. 10 illustrates the data content of a new data block, according to an example embodiment.

[0024] [Figure 7C]FIG. 1 illustrates a blockchain for digital content, according to an example embodiment.

[0025] [Figure 7D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment.

[0026] [Figure 8A] FIG. 1 illustrates an example blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment.

[0027] [Figure 8B] FIG. 1 illustrates an example quantum secure blockchain, according to an example embodiment.

[0028] [Figure 9] FIG. 1 illustrates an example system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

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

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

[0032] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks directed to privacy-preserving processes for state references (e.g., one or more references to UTXOs, etc.) stored within blockchain transactions.

[0033] In one embodiment, the present application utilizes a decentralized database (such as a blockchain), which is a distributed storage system with multiple nodes communicating with each other. A decentralized database includes an append-only immutable data structure, similar to a distributed ledger, that can maintain records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching consensus among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain across the blocks. This process forms a ledger by ordering the storage transactions as necessary for consistency. In various embodiments, permissioned and / or open-source blockchains can be used. In public or open-source blockchains, anyone can participate without a concrete identity. Public blockchains include native cryptocurrencies and can use consensus based on various protocols, such as Proof of Work (PoW). Permissioned blockchain databases, on the other hand, provide secure interactions among a group of entities that share a common purpose but do not fully trust each other, such as businesses exchanging funds, goods, information, etc.

[0034] The present application may utilize a blockchain tailored to a decentralized storage method and running arbitrary programmable logic, referred to as a "smart contract" or "chaincode." In some cases, there may be specialized chaincode for managing functions and parameters, referred to as a system chaincode. The present application may further utilize smart contracts, which are trusted distributed applications that leverage the tamper-resistant properties of the blockchain database and underlying agreements between nodes, referred to as endorsements or endorsement policies. Blockchain transactions associated with this application may be "approved" before being committed to the blockchain, while unapproved transactions are ignored. The endorsement policy allows the chaincode to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client submits a transaction to a peer specified in the endorsement policy, the transaction is executed and the transaction is validated. After validation, the transaction enters an ordering phase, in which a consensus protocol is used to generate an ordered sequence of approved transactions grouped into multiple blocks.

[0035] This application may utilize nodes, which are communication entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes may include different types, such as client or submitting client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain a ledger state and copy of blockchain transactions. Peers may also have the role of endorser, but this is not a requirement. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system when committing transactions and modifying the blockchain world state, which is another name for the initial blockchain transaction, which typically contains control and setup information.

[0036] The present application may utilize a ledger, which is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party may maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable, sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0037] The present application may utilize 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 a hash of the block's transactions and a hash of the header of the previous block. In this way, all transactions on the ledger can be sequenced and cryptographically linked together. Therefore, it is not possible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that came before it, allowing all peer nodes to ensure a consistent and trusted state. The chain may be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0038] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain transaction log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes referred to as the world state. Chaincode invocations perform transactions against the ledger's current state data. To make these chaincode interactions efficient, the latest values ​​of keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log, so it can be regenerated from the chain at any point in time. The state database may be automatically recovered (or generated if necessary) at peer node startup and before any transactions are accepted.

[0039] Various blockchain frameworks, such as BITCOIN (copyright) and others, follow the Unspent Transaction Output (UTXO) model. When a blockchain transaction is submitted, it may include one or more inputs and one or more outputs. The output results from the inputs being mixed in some way, for example, via addition, subtraction, multiplication, division, etc. The outputs are called UTXOs. Each UTXO is a digital token that represents the amount of digital currency remaining after executing a cryptocurrency transaction. In some cases, multiple outputs (UTXOs) can result from a single transaction. Each UTXO is stored at a blockchain address and includes an identifier that identifies the blockchain transaction and an index that identifies each UTXO within that transaction. For example, if transaction #500 includes two outputs (UTXO1 and UTXO2), the identifiers for these two outputs may be as follows: UTXO1=<ID=500,インデックス=0> UTXO2=<ID=500,インデックス=1>

[0040] UTXOs also serve as inputs to blockchain transactions. Each UTXO may be embodied as a digital token. Each UTXO may be spent only once. To spend a UTXO, one or more new UTXOs must be created from the initial UTXO. For example, in a transaction to transfer 100 coins from user A to user B, the transaction may include user A selecting a first UTXO worth 200 coins as the input UTXO. The transaction may then create two new UTXOs: a second UTXO containing 100 coins and sent to user B, and a third UTXO containing the remaining 100 coins (i.e., 200-100=100) and sent to user A.

[0041] To prevent double-spending of UTXOs, identifiers of available UTXOs (i.e., UTXOs that have not yet been spent as inputs) may be stored in a pool constructed by blockchain peers based on content from the blockchain ledger. The pool itself may be stored locally on the blockchain peer, not on the blockchain ledger. During the validation process of a blockchain transaction, a blockchain peer (e.g., a mining node, a commit node, etc.) may query the pool for a list of available unspent UTXOs, e.g., via an application programming interface (API), a smart contract, etc., and verify that the input UTXO of the blockchain transaction is included within the pool of unspent UTXOs. In some embodiments, each unspent UTXO may include a unique serial number assigned to it. The manner in which the serial number is assigned to a UTXO may depend on the particular implementation of the UTXO model used. The serial number may be unique with respect to other UTXOs on the blockchain, thereby allowing the UTXO to be separately identified by the serial number rather than by the UTXO owner's public key (blockchain address). In some embodiments, the service may maintain a mapping of serial numbers to UTXOs, etc., where blockchain peers may query the service for serial numbers. As another example, each peer may maintain its own mapping of serial numbers to UTXOs.

[0042] To protect privacy, certain blockchain networks may perform serial number checks instead of UTXOs. As noted above, a blockchain transaction may include one or more input UTXOs and one or more distinct output UTXOs. The input UTXOs are consumed by the blockchain transaction. The serial numbers assigned to the consumed UTXOs are added to a pool of spent (i.e., spent UTXOs). Publishing these serial numbers is harmless because they cannot be linked to the associated UTXOs. Therefore, even if an attacker were to obtain the serial numbers, they could not be used for cryptocurrency transactions.

[0043] However, in some cases, a blockchain transaction may include a reference to a UTXO that has not been consumed by the blockchain transaction but has simply been added by a client / user for any desired purpose, such as further validation, security, etc. This reference may be referred to as a state reference. A state reference UTXO is also assigned a serial number, but is not consumed by the transaction and is therefore still an actionable UTXO. Current blockchain platforms, such as BITCOIN®, require that the serial number assigned to the reference UTXO be made public for security purposes.

[0044] Exemplary embodiments overcome the shortcomings of related art by protecting the privacy of state reference UTXOs within blockchain transactions that follow the UTXO model. In particular, exemplary embodiments add both a zero-knowledge proof (ZKP) and a hash value to the state reference when submitting a blockchain transaction. Without revealing anything, the ZKP ensures that, at the time the blockchain transaction is submitted to the blockchain network, the transaction is valid, the input UTXO is in the pool of unspent tokens, and the corresponding serial number is not in the pool of spent serial numbers. However, additional transactions may be stored on the blockchain ledger between when the blockchain transaction is submitted and when the blockchain transaction is finally committed (i.e., after a consensus process such as a mining operation). This delay allows time for intervening transactions to be added to the ledger, any of which may consume the state reference as the input UTXO (i.e., being spent). When the state reference is consumed by an intervening transaction, its serial number will be added to the pool of spent serial numbers. However, the client does not want to make this serial number public.

[0045] In this case, simply providing a zero-knowledge proof that the serial number is valid at the time of submission is not enough because the blockchain network must verify that the state reference does not include a serial number that has been consumed by any intervening transactions since the blockchain transaction was submitted. To address this, the client generates a hash of the serial number using a two-way universal hash function that takes the serial number and a random value "R" as input, and computes the two-way universal hash function over both inputs to generate a hashed serial number. The hashed serial number is then stored in the blockchain transaction in place of the actual serial number.

[0046] Here, a miner node (e.g., a BITCOIN® or another type of blockchain node, such as a commit node) can identify each serial number stored in a pool of serial numbers since a blockchain transaction having a state reference was submitted for mining / storage. For each serial number found in the pool, the blockchain node may perform a hash of SN+R (a known random string) using the same two-way universal hash function and compare it to the hash of the serial number in the state reference stored in the blockchain transaction to determine whether the serial number in the pool equals the serial number in the state reference. If the blockchain node finds a hash of a used serial number that equals the hash of the serial number in the state reference, the blockchain node detects that an intervening transaction has consumed the state reference as an input UTXO, resulting in a possible double-spend. Thus, the blockchain node can detect the invalidity of the state reference and store information about the invalidity via the blockchain. The blockchain node can also reject the transaction and take additional steps to notify the user who submitted the transaction that the state reference is no longer valid because it has been consumed / used by an intervening transaction.

[0047] FIG. 1A illustrates a blockchain network 100 according to an example embodiment. Referring to FIG. 1A, the blockchain network 100 may be a network that manages cryptocurrency transactions (e.g., BITCOIN (registered trademark), etc.) via a blockchain ledger 110. Here, the blockchain network 100 may include multiple blockchain peers 111-114 that manage the blockchain ledger 110. Each peer among the multiple blockchain peers 111-114 may store a copy of the blockchain ledger 110. Furthermore, each peer may play a role such as mining, endorsement, consensus, etc.

[0048] In the example of FIG. 1A , two clients 120 and 130 wish to transact with each other to exchange cryptocurrency in some manner. Here, client 120 may submit a blockchain transaction to any of blockchain peers 111-114. In response, the blockchain transaction may be mined as known in the art and committed to blockchain ledger 110 after the successful mining operation. Once the blockchain transaction is mined into blockchain ledger 110, the respective wallet accounts (e.g., blockchain wallets) of clients 120 and 130 may be updated to reflect the change in balance as a result of the cryptocurrency transaction between clients 120 and 130.

[0049] FIG. 1B illustrates an example of blockchain transactions generated according to an unspent transaction output (UTXO) model, according to an example embodiment. FIG. 1B illustrates a process 140 for managing an unspent UTXO pool as UTXOs are consumed by transaction 1 and transaction 2. Referring to FIG. 1B, transaction 0 includes two output UTXOs 141 and 142 created by transaction 0. Although not shown in FIG. 1B, both UTXOs 141 and 142 are available for use, and identifiers for both UTXOs 141 may be added to the pool of unspent UTXOs after transaction 0. However, the pool is not shown after transaction 0 for simplicity.

[0050] At some point following transaction 0, transaction 1 is submitted. Here, transaction 1 receives UTXO 141 as input. Therefore, the identifier of UTXO 141 can be removed from the pool of available (unspent) UTXOs 170a. Meanwhile, the identifier of UTXO 142 can be kept in the pool of unspent UTXOs 170a, as shown below transaction 1. Here, the output of transaction 1 is two new UTXOs 151 and 152. The identifiers of each of these UTXOs 151 and 152 can be added to the pool of unspent UTXOs 170a at the end of transaction 1.

[0051] At a subsequent point in time, transaction 2 is submitted to the blockchain network. Transaction 2 receives UTXO 152 and UTXO 142 as inputs and generates three new UTXOs 161, 162, and 163 as outputs. Thus, identifiers for UTXOs 152 and 142 may be removed from pool of unspent UTXOs 170b, while identifiers for new UTXOs 161, 162, and 163 may be added to pool of unspent UTXOs 170b. This process may occur simultaneously as new transactions are stored in blockchain ledger 110.

[0052] FIG. 1C illustrates a blockchain transaction (i.e., transaction 2) that includes state reference 181, according to an example embodiment. Additionally, in this example, UTXOs are assigned serial numbers (unique). Here, the blockchain network manages a pool of spent serial numbers 182 and a pool of unspent UTXOs 170. Referring to FIG. 1C, as UTXOs are consumed as input, their serial numbers are added to the pool of spent serial numbers. For example, in FIG. 1C, transaction 1 consumes UTXO 141. Therefore, the serial number assigned to UTXO 141 is added to pool of spent serial numbers 182a. Meanwhile, transaction 2 consumes two UTXOs, 152 and 142. Here, the serial numbers assigned to the two UTXOs, 152 and 142, are added to pool of spent serial numbers 182b.

[0053] However, in FIG. 1C , state-reference UTXO 181 is not consumed by transaction 2, but instead is simply added by the client as a reference. In this case, UTXO 181 is made public, including its serial number. As a result, an attacker could obtain the serial number and use it in a subsequent transaction. The illustrative embodiments provide a mechanism that can overcome such disclosure of sensitive information. In particular, the serial number can be hashed, thereby preventing another entity (such as an attacker) from learning the serial number. Furthermore, as further described in the examples of FIGS. 4A-4D , a process can be implemented to ensure that the serial number is not in pool 180 of spent serial numbers. Thus, additional security can be added to traditional cryptocurrency transactions that involve a state reference as part of the transaction. Furthermore, double-spending can still be prevented based on the validation process described in the examples of FIGS. 4A-4D below.

[0054] FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. Referring to FIG. 2A, the blockchain architecture 200 may include a particular blockchain element, e.g., a group of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown merely by way of example). These nodes participate in multiple activities, such as the blockchain transaction addition and validation process (consensus). One or more of the blockchain nodes 204-210 may approve transactions based on endorsement policies and provide ordering services for all blockchain nodes in the architecture 200. The blockchain nodes may initiate blockchain validations and seek writes to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224, linked to an application programming interface (API) 222 for accessing and executing stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which may be written according to customized configurations desired by participants and can maintain their own state, control their own assets, and receive external information, which can be deployed as transactions and installed on all blockchain nodes 204-210 via appending to the distributed ledger.

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

[0056] The blockchain architecture configuration of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may store and transfer data and may be executed by nodes 204-210 in the form of smart contracts and associated chaincode with conditions or other code elements subject to its execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, and / or other notifications subject to changes, updates, etc. Smart contracts themselves can be used to identify authorization and access requirements and rules associated with ledger usage. For example, smart contracts (or chaincodes executing the smart contract logic) may read blockchain data 226, which may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to generate results 228, including alerts, responsibility determinations, etc., within complex service scenarios. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

[0057] Smart contracts may be created via high-level application and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated with the blockchain (e.g., a distributed network of blockchain peers). A transaction is an execution of smart contract logic that may be executed in response to a condition associated with the smart contract being satisfied. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

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

[0059] Chaincode may include a code interpretation (e.g., logic) of a smart contract. For example, chaincode may include a packaged, deployable version of the logic in a smart contract. As described herein, chaincode may be program code deployed on a computing network, where it is executed and validated by a chain validator together during a consensus process. The 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 and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may be written to the blockchain data associated with the cryptographic details.

[0060] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. Referring to FIG. 2B, the transaction flow may include a client node 260 sending a transaction proposal 291 to an endorsing peer node 281. The endorsing peer 281 may execute a chaincode function to verify the client signature and initiate the transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (the read set), and a set of key / values ​​written to the chaincode (the write set). The endorsing peer 281 may then decide whether to approve the transaction proposal. A proposal response 292, if accepted, is sent back to the client 260 along with an 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 it to the blockchain, each peer 281-283 may validate the transaction. For example, a peer may check the endorsement policy to ensure that the correct quota of the specified peer has signed the result and authenticated the signature against the transaction payload 293.

[0061] Referring again to FIG. 2B, a client node initiates a 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 utilizes available APIs to generate a transaction proposal. The proposal is a request that invokes chaincode functions so that data can be read from and / or written to the ledger (i.e., writing a new key-value pair for an asset). The SDK may package the transaction proposal into a suitably designed format (e.g., protocol buffers for remote procedure calls (RPCs)) and act as a shim to obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

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

[0063] In response, the application on the client 260 checks / verifies the signature of the endorsing peer and compares the proposed response to determine whether it is the same. If the chaincode only queries the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all required peer nodes for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. This architecture ensures that the endorsement policy is still enforced by peers and maintained during the commit validation phase, even if the application chooses not to check the response or otherwise forwards an unendorsed transaction.

[0064] After successful validation, in step 293, client 260 assembles the endorsements into a transaction proposal and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may include a read / write set, an endorsing peer signature, and a channel ID. Ordering node 284 does not need to validate the entire contents of the transaction to perform its operations; instead, ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0065] The block is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. Data sections within the block may be validated to ensure endorsement policies are met and to ensure the ledger state has not changed for readset variables since the readset was generated by transaction execution. Furthermore, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. Events may be emitted to notify client applications that a transaction (invocation) has been immutably appended to the chain, and whether the transaction has been validated or invalidated.

[0066] In the example of FIG. 2B, client node 260 and each of blockchain peers 281-284 may use verifiable credentials as signatures. As a transaction moves through the different stages of FIG. 2B, client node 260 and each of blockchain peers 281-284 may attach their respective VCs to the stages they performed. In this example, each of blockchain peers 281-284 may include a set of VCs (e.g., one or more VCs) that provide identity and membership information associated with blockchain peer 281-284. For example, client node 260 may include a verifiable certificate with a claim issued by an MSP of the blockchain network that identifies the client as a member for transacting on the blockchain. As another example, blockchain peers 281-283 may include a VC that identifies blockchain peer 281-283 as an endorsing peer of the blockchain. Meanwhile, blockchain peer 284 may include a VC that identifies blockchain peer 284 as an ordering node of the blockchain. Many other VCs are possible. For example, particular channels on a blockchain (e.g., different blockchains on the same ledger) may require different VCs to act as clients, peers, endorsers, orderers, etc. As another example, different types of transactions and / or chaincodes may require separate VCs by client, peer, etc. For example, a client may simply submit a transaction to invoke a particular chaincode if the client has a VC that identifies the client as authorized to use such chaincode.

[0067] 3A illustrates an example of a permissioned blockchain network 300 featuring a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction against a permissioned blockchain 304. In this example, the transaction may be a deployment, a call, or a query, and may be issued through a client-side application leveraging an SDK, directly through an API, or the like. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, call, and query specific types of chaincode.

[0068] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy the chaincode directly to the network through an interface. To include credentials from traditional data sources 312 in the chaincode, the developer 310 can access the data using an out-of-band connection. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before proceeding with any transaction, the peer node 314 retrieves the user's registration and transaction certificates from a certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain 304. However, users attempting to utilize the chaincode may be required to verify their credentials against traditional data sources 312. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0069] 3B shows another example of a permissioned blockchain network 320 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, transactions may be deployments, invocations, or queries and may be issued through client-side applications leveraging SDKs, directly through APIs, etc. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query specific types of chaincode.

[0070] A blockchain developer 330 writes chaincode and client-side applications. The blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include credentials from traditional data sources 332 in the chaincode, the developer 330 can access the data using an out-of-band connection. In this example, a blockchain user 322 connects to the network through a peer node 334. Before proceeding with any transaction, the peer node 334 retrieves the user's registration and transaction certificates from a certificate authority 336. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 324. Alternatively, a user attempting to utilize the chaincode may be required to verify their credentials against traditional data sources 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0071] In some embodiments, a blockchain herein may be a permissioned blockchain. Anyone can participate in a permissioned blockchain, as opposed to a permissioned blockchain, which requires permission to participate. For example, to participate in a permissioned blockchain, a user may begin interacting with the network by creating a personal address and submitting transactions, thus adding entries to the ledger. Additionally, all parties have the option to run a node on the system and utilize a mining protocol that helps verify transactions.

[0072] 3C illustrates a transaction process 350 processed by an open-ended blockchain 352 that includes multiple nodes 354. A sender 356 wishes to send a payment or some other form of value (e.g., a certificate, medical records, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the open-ended blockchain 352. In one embodiment, the sender device 356 and the recipient device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcast throughout the blockchain 352 to the nodes 354. Depending on the network parameters of the blockchain 352, the nodes validate 360 ​​the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the open-ended blockchain 352. For example, this may include verifying the identities of the parties involved, etc. The transaction may be verified immediately or may be queued with other transactions, and node 354 determines whether the transaction is valid based on a set of network rules.

[0073] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process may be performed by mining nodes among nodes 354. Mining nodes may utilize additional software specifically for mining and creating blocks for the open-ended 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 include 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 creating a secure and independent chain of blocks.

[0074] Before a block can be added to the blockchain, it must be validated. Validation for a permissionless blockchain 352 may involve proof of work (PoW), which is the solution to a puzzle derived from the block's header. Another process for validating a block, not shown in the example of FIG. 3C, is proof of stake. Unlike proof of work, where an algorithm rewards miners for solving a mathematical problem, in proof of stake, the creator of a new block is selected in a deterministic manner depending on their wealth, also defined as "stake." Similar proofs are then performed by selected / elected nodes.

[0075] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates a proof of work, which guarantees a correct solution. In other words, a potential solution must prove that computing resources were depleted to solve the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0076] Here, the PoW process chains blocks together, making it extremely difficult for an attacker to modify the blockchain because a modification to one block requires modifying all subsequent blocks for it to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying the block increases, and the number of subsequent blocks increases. In distribution 366, successfully validated blocks are distributed throughout the open-source blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the open-source blockchain 352. Furthermore, the value of the transaction submitted by the sender 356 is deposited or otherwise transferred to a digital wallet on the recipient device 358.

[0077] FIG. 4A illustrates a process 400 for generating a privacy-preserving state reference 410, according to an example embodiment, and FIG. 4B illustrates an example of data values ​​included with the state reference 410 of FIG. 4A, according to an example embodiment. Referring to FIGS. 4A and 4B, a state reference 410 is added to a blockchain transaction 402 (i.e., transaction 2) similar to the example in FIG. 1C. However, in this example, rather than storing the serial number assigned to the state reference 410, the client stores a zero-knowledge proof (ZKP) value 412 and a hash value 414 along with the contents 416 of the UTXO. That is, in this example, the serial number is not included in the state reference 410. The ZKP value 412 may be created by running a ZKP algorithm on the pool of used serial numbers 182a at the time the blockchain transaction 402 is submitted to the blockchain ledger. The ZKP value 412 can be used to verify / prove that the state reference 410 UTXO was not an input in any transaction prior to the submission of the blockchain transaction 402.

[0078] However, as noted above, intervening transactions may be recorded on the blockchain ledger between when the blockchain transaction 402 having the state reference 410 is submitted and when it is ultimately committed to the blockchain ledger. According to various embodiments, the hash value 414 can be used to ensure that these intervening transactions do not include the state reference 410 as an input UTXO.

[0079] In particular, hash value 414 can be created by hashing a combination of a serial number assigned to state reference 410 and a random string (R). The result is hash value 414 that hides the serial number from those without knowledge of the serial number, and may only be shared in advance among blockchain participants, e.g., during registration. Note that transaction 402 does not consume state reference 410, but instead simply references this UTXO for any desired purpose, such as business purposes, security, validation, etc.

[0080] FIG. 4C illustrates a timeline 430 for processing blockchain transactions, according to an example embodiment. Referring to FIG. 4C, blockchain ledger 432 illustrates the sequence of blocks recorded in blockchain ledger 432 and the order in which they are committed. In this example, blockchain transaction 402 is submitted at a first time point, where the most recently stored blockchain transaction is transaction 1. However, blockchain transaction 402 must go through a consensus process, which may involve mining, endorsement, consensus, etc. Now, blockchain transaction 402 is not committed to the blockchain until a second time point, where the most recently recorded transaction is now transaction 4 rather than transaction 1. Therefore, two intervening transactions (transaction 3 and transaction 4) have been committed / recorded in blockchain ledger 432.

[0081] 4D, ZKP value 412 may be used to verify that state reference 410 is not an input UTXO in any of the transactions committed to blockchain ledger 432 up to transaction 1. Meanwhile, hash value 414 can be used to verify that state reference 410 is not an input UTXO in any of the intervening transactions (e.g., transactions 3 and 4) committed to blockchain ledger 432 after blockchain transaction 402 was submitted but before it was committed.

[0082] FIG. 4D illustrates a privacy-preserving search process 440, according to an example embodiment. Referring to FIG. 4D, blockchain transaction 402 has been submitted and is currently being mined / committed by blockchain node 460. Here, the most recently stored transaction on blockchain ledger 432 is transaction 4. Below transaction 4 is a diagram of pool 450 of used serial numbers, including line 455, which divides the pool of used serial numbers into two subsets. The first subset (top half) refers to used serial numbers that were already included in pool 450 when blockchain transaction 402 was submitted. Therefore, the first subset of serial numbers can be avoided because ZKP value 412 proves that state reference 410 is not an input UTXO in any transaction on the blockchain ledger until blockchain transaction 402 is submitted. This is because the top half refers to serial numbers that were used before blockchain transaction 402 was submitted.

[0083] Meanwhile, the bottom half of pool of used serial numbers 450 contains serial numbers added after blockchain transaction 402 was submitted but before it was committed, where serial numbers 451, 452, 453, and 454 correspond to UTXOs consumed as input by intervening transaction 3 and transaction 4 shown in Figure 4C. A second subset of UTXOs is not covered by ZKP value 412. In this case, blockchain node 460 can retrieve hash value 414 from state reference 410.

[0084] Additionally, blockchain node 460 may create hashes of serial numbers 451, 452, 453, and 454. For example, blockchain node 460 may perform the same hashing process performed by the client when generating hash value 414. Here, blockchain node 460 may append a random string to each of the serial numbers and use the same hash function to create the hash of serial numbers 451-454. Furthermore, blockchain node 460 may compare hashed serial numbers 451-454 with hashed value 414. If hashed value 414 is equal to any of hashed serial numbers 451-454, then state reference 410 has already been spent as an input UTXO in one of intervening transactions 3 or 4. However, if hashed value 414 is not equal to any of hashed serial numbers 451-454, blockchain node 460 successfully validates that state reference 410 has not been spent as a UTXO input and is therefore still a valid UTXO.

[0085] If blockchain node 460 is able to verify that state reference 410 has not been spent, then double-spending is not an issue. However, if state reference 410 has been spent (i.e., hash value 414 is found to be equal to one of hashed serial numbers 451-454), then the possibility of double-spending exists, and blockchain node 460 can detect that transaction 402 is invalid due to its use of state reference 410. Thus, blockchain node 460 can reject the transaction, send a notification to the user / client, record information about the invalidation of state reference 410 and / or transaction 402 on the blockchain ledger, etc.

[0086] Thus, a blockchain node / network can verify that a state reference is not double-spent by verifying that the state reference is not an input UTXO in any blockchain transaction submitted before the submission of the blockchain transaction containing the state reference, and by verifying that the state reference is not an input UTXO in any subsequent intervening transaction committed after the blockchain transaction is submitted. However, the serial number remains hidden from an attacker during the entire verification process, thereby preserving the privacy of the state reference's serial number.

[0087] FIG. 5 illustrates a method 500 for validating a state reference in a blockchain transaction, according to an example embodiment. For example, method 500 may be performed by a blockchain peer, a mining node, a smart contract, or the like. With reference to FIG. 5 , at 510, the method may include receiving a blockchain transaction including a state reference to a unspent transaction output (UTXO). At 520, the method may include determining, based on a zero-knowledge (ZK) proof included in the state reference, whether the UTXO is included in a first subset of transactions on the blockchain ledger. At 530, the method may include determining, based on a hash value included in the state reference, whether the UTXO is included in a second subset of transactions on the blockchain ledger. At 540, the method may include committing the blockchain transaction including the state reference to the blockchain ledger via the blockchain peer in response to determining that the UTXO is not included in either the first or second subset of transactions.

[0088] In some embodiments, the first subset of transactions is included within a first subset of blocks stored on the blockchain ledger prior to submission of the blockchain transactions to the blockchain peers. In some embodiments, the second subset of transactions is included within a second subset of blocks stored on the blockchain ledger after submission of the blockchain transactions to the blockchain peers. In some embodiments, the first subset of transactions is mutually exclusive from the second subset of transactions on the blockchain ledger. In some embodiments, the hash value is created by hashing a serial number assigned to the state reference with a predefined hash function.

[0089] In some embodiments, the method may further include retrieving a plurality of serial numbers assigned to input UTXOs consumed by the second subset of transactions from a pool of spent transactions stored on the blockchain peer. In some embodiments, the method may further include hashing the plurality of serial numbers based on a predefined hash function (e.g., a universal two-way hash function, etc.) to generate a plurality of hashed comparisons, and determining whether the hash value is equal to any of the hashed serial numbers. In some embodiments, the method may further include determining that the blockchain transaction is invalid in response to determining that the UTXO is included in either the first or second subset of transactions, and storing information identifying the blockchain transaction as invalid on the blockchain ledger.

[0090] FIG. 6A illustrates an example system 600 including a physical infrastructure 610 configured to perform various operations, according to an example embodiment. Referring to FIG. 6A , the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which may perform any of the operational steps 608 (in the module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the described or illustrated embodiments and may represent output or written information written to or read from one or more smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, the module 612 and the module 614 may be the same module.

[0091] FIG. 6B illustrates another example system 640 configured to perform various operations according to example embodiments. Referring to FIG. 6B, system 640 includes module 612 and module 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on blockchain 620), which may perform any of the operational steps 608 (in module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the described or illustrated embodiments and may represent output or written information written to or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, module 612 and module 614 may be the same module.

[0092] FIG. 6C illustrates an example system configured to utilize a smart contract configuration between contract parties and an intermediary server configured to enforce smart contract terms on a blockchain, according to an example embodiment. Referring to FIG. 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 and / or 656. The execution, behavior, and results of smart contract execution may be managed by a server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 that are parties to the smart contract transaction. The results of smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0093] Figure 6D illustrates a system 660 including a blockchain, according to an example embodiment. Referring to the example of Figure 6D, an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., 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., server 654). Here, server 654 is a blockchain network peer component that maintains a copy of the world state and distributed ledger, allowing clients 652 and 656 to query data against the world state and, depending on the smart contract 630 and endorsement policies, submit transactions to the blockchain network where endorsing peers execute the smart contract 630.

[0094] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program 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, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0095] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components.

[0096] FIG. 7A illustrates a process 700 in which a new block is added to a distributed ledger 720, according to an example embodiment, and FIG. 7B illustrates the contents of a new data block structure 730 for the blockchain, according to an example embodiment. Referring to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, and / or 713. A client may be an instruction to perform an activity on the blockchain 720 received from any source. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a copy of the blockchain network state and the distributed ledger 720. Different types of blockchain nodes / peers may exist within a blockchain network, including endorsing peers that simulate and approve transactions proposed by clients, and committing peers that verify endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may act as endorser nodes, committer nodes, or both.

[0097] The distributed ledger 720 comprises a blockchain that stores immutable, sequenced records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. There may be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel in which it is a member. The blockchain 722 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may include various components, such as those shown in FIG. 7B. Block linking (illustrated by arrows in FIG. 7A) may be generated by adding a hash of the header of the previous block into the block header of the current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash link. Furthermore, due to the linking, the latest block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored on a peer file system (local or attached storage) to support append-only blockchain workloads.

[0098] The current state of the blockchain 722 and distributed ledger 722 may be stored in a state database 724, where the current state data represents the latest values ​​of all keys included so far in the chain transaction log of the blockchain 722. Chaincode calls execute transactions against the current state in the state database 724. To make these chaincode interactions highly efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may contain an indexed view into the blockchain 722 transaction log, so it can be regenerated off-chain at any point in time. The state database 724 may be automatically restored (or generated if necessary) upon peer startup, before transactions are accepted.

[0099] An endorsing node receives transactions from clients and approves the transactions based on simulated results. The endorsing node holds a smart contract that simulates a transaction proposal. When the endorsing node approves a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating its endorsement of the simulated transaction. The manner in which a transaction is approved depends on the endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must approve the transaction." Different channels may have different endorsement policies. The approved transaction is forwarded by the client application to the ordering service 710.

[0100] The ordering service 710 accepts approved transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 710 may start a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 7A, blockchain node 712 is a committing peer that receives a new data block 730 of new data for storage on the blockchain 720. The first block in a blockchain may be referred to as a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0101] 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 approved 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 specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0102] 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 they are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering is achieved through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 may choose the ordering mechanism that best suits their network.

[0103] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transactions in the new data block 730 by checking the read set and write set to ensure that they 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. When a committing peer validates a transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If a transaction fails, i.e., if a committing peer finds that the read-write set does not match the current world state in state database 724, the transactions that were ordered into a block are still included in the block but are marked as invalid and state database 724 is not updated.

[0104] 7B, a new data block 730 (also referred to as a data block) stored on the blockchain 722 of a distributed ledger 720 may include 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 illustrated blocks and their contents, such as new data block 730 and its contents shown in FIG. 7B, are merely examples and are not intended to limit the scope of the illustrative 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.) in block data 750.

[0105] The new data block 730 may include a link to its predecessor block (e.g., on the blockchain 722 in FIG. 7A ) in its block header 740. In particular, the block header 740 may include a hash of the header of the predecessor 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, etc. The block numbers of the new data block 730 are unique and may be assigned in various orders, such as an incremental / sequential order starting from 0.

[0106] According to various embodiments, block data 750 may store transactions flagged with an identifier indicating that the transaction includes a state reference, and state reference data 752, which may include validity information, hash values, etc., of the state reference, including the ZKP. The state reference data 752 may be stored in an immutable log of a block (blockchain 722) on the distributed ledger 720. Some of the benefits of storing the state reference data 752 on a blockchain are reflected in various embodiments disclosed and illustrated herein. While state reference data 752 is shown in block data 750 in FIG. 7B , in other embodiments, state reference data 752 may be stored in block header 740 or block metadata 760.

[0107] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature for the block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, etc. The signature, last constituent block, and orderer metadata may be added by the ordering service 710. Alternatively, the block committer (e.g., blockchain node 712) may add validity / invalidity information based on an endorsement policy, validation of the read / write set, etc. The transaction filter may include a byte array of a size equal to the number of transactions included in block data 750 and a validation code that identifies whether the transaction was valid / invalid.

[0108] 7C illustrates an embodiment of a blockchain 770 for digital content, according to embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable append-only aspects of the blockchain serve as safeguards to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or in other settings where evidentiary considerations are taken into account or where the presentation and use of digital information is otherwise of interest. In this case, the digital content may be referred to as digital evidence.

[0109] A blockchain may be formed in a variety of ways. In one embodiment, digital content may be contained within and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with associated digital content. The hash value and associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis for referencing previous blocks. This may be shown 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

[0110] In one embodiment, the digital content may not be included within the blockchain. For example, the blockchain may store an encrypted hash of the content of each block without any accompanying digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the hash value in the storage area where it is stored in correspondence with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Area Block 1 hash value Block 1 hash value...contents . . . . . . Block N hash value Block N hash value...Contents

[0111] In the example embodiment of FIG. 7C, the blockchain 770 comprises multiple blocks 7781, 7782, ... 778 that are cryptographically linked in an ordered sequence. N where N≧1. Blocks 7781, 7782, ... 778 N The encryption used to link the blocks 7781, 7782, ... 778 may be any of a number of keyed or unkeyed hash functions. N is subjected to a hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Dangard algorithms, HAIFA algorithms, Merkle-Tree algorithms, nonce-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is made with reference to a hash function, e.g., SHA-2.

[0112] Blocks 7781, 7782, ... 778 in the blockchain N Each of the files includes a header, a file version, and a value. The header and value are different for each block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0113] The first block 7781 in a blockchain is called the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used for the genesis block and indeed all subsequent blocks may be different. For example, all of the information in the first block 7781 may be hashed together at once, or each or portions of the information in the first block 7781 may be hashed separately, followed by a hash of the separately hashed portions.

[0114] The header 7721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a 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. The header 7721 may be generated automatically (e.g., by a blockchain network that manages the software) or manually by a blockchain participant. Other blocks 7782-7788 in the blockchain N Unlike the headers in the , the header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0115] The original file 7741 in the genesis block may be, for example, data as captured by a device, with or without processing before inclusion in the blockchain. The original file 7741 is received from a device, media source, or node through an interface of the system. The original file 7741 is associated with metadata, which may be generated, for example, either manually or automatically, by a user, device, and / or system processor. The metadata may be included in the first block 7781 in association with the original file 7741.

[0116] The value 7761 in the genesis block is an initial value that is generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value for the original file 7741, metadata for 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) SHA-2 calculated hash value for the original file 2) Source device ID 3) The start timestamp for the original file 4) The initial storage location of the original file 5) Blockchain network member ID for the software that currently controls the original file and associated metadata

[0117] Other blocks in the blockchain: 7782-778 N However, unlike the first block 7721, the headers 7722 to 7723 in the other blocks also have a header, a file, and a value. N Each of the remaining blocks contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be the hash of the header of the preceding block, or it may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block trace can be performed, as indicated by arrow 780, from the Nth block back to the genesis block (and associated original file) to establish an auditable and immutable archive.

[0118] Also, headers 7722 to 772 in other blocks N may include other information, such as a version number, a timestamp, a nonce, root information, difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or the blockchain in general.

[0119] Files 7742 to 774 in other blocksN may be equal to the original file or may be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. Processing may involve any modification of the file in the preceding block, such as, for example, editing or otherwise changing the content of the file, removing information from the file, or adding or appending information to the file.

[0120] Additionally or alternatively, processing may involve 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 an action on the file on the blockchain and / or its associated metadata. Processing involving analysis of a file may include, for example, appending, including, or otherwise associating various analytics, statistics, or other information associated with the file.

[0121] Other blocks in other blocks 7762~776 N The value in each of the blocks is unique and is different as a result of the operations performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of a block provides an indication of what operations were performed in the block and also allows tracing back through the blockchain to the original file. This tracking confirms the integrity of the file throughout the blockchain.

[0122] For example, consider the case where a portion of a file in a previous block has been redacted, blocked out, or pixelated to protect the identity of a person depicted in the file. In this case, the block containing the edited file includes metadata associated with the edited file, such as how the edit was performed, who performed the edit, the timestamp at which the edit occurred, etc. The metadata may be hashed to form a value. Because the metadata for the block is different from the information hashed to form the value in the previous block, these values ​​may be different from each other and may be recovered when decrypted.

[0123] In one embodiment, the value of a previous block may be updated (e.g., a new hash value may be calculated) to form the value of a current block when any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information shown below: a) If the file is processed in any way (e.g., if the file is edited, copied, modified, accessed, or any other action is taken), a new SHA-2 calculated hash value b) A new storage location for the file c) any new metadata identified as being associated with the file; d) Transfer of access or control of a file from one blockchain participant to another.

[0124] 7D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 790, according to one embodiment. i Header 772 i , File 774 i、 and value 776 i Includes.

[0125] Header 772 i is the preceding block Block i-1and further reference information, which may be, for example, any of the types of information discussed herein (e.g., header information including references, properties, parameters, etc.). All blocks, except of course for the genesis block, reference the hash of the previous block. The hash value of the previous block may simply be a hash of the header in the previous block, or a hash of all or part of the information in the previous block, including files and metadata.

[0126] File 774 i includes multiple pieces of data in a sequence, such as Data1, Data2, ..., DataN. The data are tagged with Metadata1, Metadata2, ..., MetadataN that describe content and / or characteristics associated with the data. For example, the metadata for each piece of data may indicate a timestamp for the data, keywords that indicate the data, people or other content depicted in the data, and / or other features that may be useful in establishing the validity and content of the file as a whole, and in particular its use, e.g., information for processing digital evidence as described in connection with the embodiments discussed below. In addition to the metadata, each piece of data may include references REF1, REF2, ..., REF to previous pieces of data to prevent tampering, gaps within the file, and sequential referencing through the file. N may be tagged.

[0127] Once metadata is assigned to data (e.g., through a smart contract), it cannot be changed without a hash change that can be easily identified for invalidation. The metadata therefore creates a data log of information that can be accessed for use by participants in the blockchain.

[0128] Value 776 i is a hash value or other value calculated based on any of the types of information discussed above. For example, for any given block, Block i, the value for that block may be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information being added. Although the values ​​in each block are shown to be separate from the metadata and headers for the file's data, in other embodiments the values ​​may be based in part or entirely on this metadata.

[0129] Once the blockchain 770 is formed, at any point in time, an immutable evidence chain for a file may be obtained by querying the blockchain for a history of value transactions across blocks. This query, or tracking procedure, may begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continuing to decrypt values ​​in other blocks until the genesis block is reached and the original file is recovered. Decryption may also involve decrypting the header and file and associated metadata in each block.

[0130] Decryption is performed based on the type of encryption performed on each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, blockchain participants or processors in the network may generate a public and 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 publicly distributed to serve as an address for receiving messages from other users, such as an IP address or home address. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent the message.

[0131] Generating a key pair may be similar to creating an account on the blockchain, but without the need to actually register anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and transact files on the blockchain (within the scope of permissions determined by the smart contract).

[0132] 8A and 8B show additional example use cases for blockchain that may be incorporated and used herein. In particular, FIG. 8A shows an example 800 of a blockchain 810 that stores machine learning (artificial intelligence) data. Machine learning relies on vast amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to discover patterns that are not intuitive.

[0133] 8A , host platform 820 builds and deploys machine learning models for predictive monitoring of asset 830, where host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. Asset 830 may be any type of asset (e.g., machinery or equipment, etc.), such as an aircraft, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a boat, a watercraft, a vehicle, etc. As another example, asset 830 may be an intangible asset, such as a stock, currency, a digital coin, insurance, etc.

[0134] The blockchain 810 can be used to significantly improve both the machine learning model training process 802 and the prediction process 804 based on the trained machine learning model. For example, at 802, historical data may be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown), rather than requiring a data scientist / engineer or other user to collect the data. This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using a smart contract, data can be directly and reliably transferred from its original location to the blockchain 810. By using the blockchain 810 to ensure security and ownership of the collected data, the smart contract may send data from the asset directly to the individual who uses the data to build the machine learning model. This enables data to be shared among the assets 830.

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

[0136] Furthermore, training the machine learning model on the collected data may take rounds of refinement and testing by the host platform 820. Each round may be based on additional data or data not previously considered useful in expanding the machine learning model's knowledge. At 802, the different training and testing stages (and their associated data) may be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., change of variables, weights, etc.) may be stored on the blockchain 810. This provides verifiable evidence of how the model was trained and what data was used to train the model. Furthermore, when the host platform 820 achieves the final trained model, the resulting model may be stored on the blockchain 810.

[0137] After the model is trained, it may ultimately be deployed to a live environment where predictions / decisions can be made based on the execution of the trained machine learning model. For example, at 804, the machine learning model may be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, medical machinery, etc. In this example, feedback data from asset 830 may be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. Decisions made by the execution of the machine learning model on host platform 820 may be stored on blockchain 810 to provide auditable / verifiable evidence. As one non-limiting example, the machine learning model may predict a future failure / failure for a portion of asset 830 and generate an alert or notification to replace the portion. The data on which this decision is based may be stored by host platform 820 on blockchain 810. In one embodiment, the features and / or actions described and / or illustrated herein may be performed on or with respect to blockchain 810.

[0138] New transactions for the blockchain can be organized into a new block and added to the existing hash value. This is then encrypted to create a new hash for the new block. This is added to the next list of transactions as they are encrypted, and so on. The result is a chain of blocks, each containing the hash values ​​of all previous blocks. Computers storing these blocks periodically compare their hash values ​​to ensure they all match. Any computer that does not match discards the offending record. This approach is sufficient to ensure the blockchain is tamper-proof, but not perfect.

[0139] One way to exploit a loophole in this system is for a fraudulent user to change the list of transactions to their advantage, leaving the hash unchanged. This can be done by brute force, in other words, by modifying the record, encrypting the result, and checking whether the hash value is the same. If not, they try again until they find a matching hash. The security of blockchain is based on the idea that ordinary computers can only perform this kind of brute force attack over completely unrealistic timescales, such as the age of the universe. Quantum computers, in contrast, are much faster (thousands of times faster) and therefore pose a much greater threat.

[0140] Figure 8B shows an example 850 of a quantum secure blockchain 852 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD, which transmits information using quantum particles, such as photons, that cannot be copied by an eavesdropper without corrupting it. In this way, senders and receivers across the blockchain can confirm each other's identities.

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

[0142] The operation of blockchain 852 is based on two steps: (i) transaction creation and (ii) the construction of blocks that aggregate new transactions. New transactions may be created in the same way as in traditional blockchain networks. Each transaction may contain information about the sender, recipient, time of creation, the amount (or value) being transferred, and a list of reference transactions that validate the sender's funds for the operation. This transaction record is then sent to all other nodes, where it is placed in a pool of unconfirmed transactions. Two parties (i.e., a pair of users from among 854-860) then authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to every transaction, making it extremely difficult to tamper with. Each node checks its own entry against its local copy of blockchain 852 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0143] Rather than performing a traditional mining process on blocks, blocks may be created in a decentralized manner using a broadcast protocol. Over a predetermined period of time (e.g., seconds, minutes, hours, etc.), the network applies the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine consensus on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). In a first round, nodes send their private values ​​to each other. In subsequent rounds, nodes communicate information received from other nodes in previous rounds. Now, honest nodes can create a complete set of transactions in a new block. This new block can be added to the blockchain 852. In one embodiment, features and / or actions described and / or illustrated herein may be performed on or with respect to the blockchain 852.

[0144] 9 illustrates an example system 900 that supports one or more of the example embodiments described and / or illustrated herein. System 900 includes a computer system / server 902 that is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with 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, etc.

[0145] The computer system / server 902 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 902 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0146] 9, a computer system / server 902 in a cloud computing node 900 is shown in the form of a general-purpose computing device. Components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus coupling various system components including the system memory 906 to the processor(s) 904.

[0147] The bus represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0148] Computer system / server 902 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system / server 902, including both volatile and nonvolatile media, removable and non-removable media. System memory 906, in one embodiment, implements the flow diagrams of other figures. System memory 906 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. Computer system / server 902 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and an optical disk drive may be provided for reading from or writing to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. In such a case, each may be connected to the bus by one or more data medium interfaces. As further illustrated and described below, memory 906 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the application.

[0149] A program / utility 916 having a set (at least one) of program modules 918 may be stored in memory 906, by way of example and not limitation, as well as 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 any combination thereof, may comprise an implementation of a networking environment. The program modules 918 generally perform the functions and / or methodologies of various embodiments of the applications as described herein.

[0150] As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software (including firmware, resident software, microcode, etc.) embodiment, or an embodiment combining software and hardware aspects, which may all be referred to collectively herein as a "circuit," "module," or "system." Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0151] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, etc.; one or more devices that allow a user to interact with the computer system / server 902; and / or any devices (e.g., network cards, modems, etc.) that allow the computer system / server 902 to communicate with one or more other computing devices. Such communication may occur via an 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), and / or a public network (e.g., the Internet), via a network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. Although not shown, it should be understood that other hardware and / or software components may be used in conjunction with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0152] At least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description, but it will be understood that the present application is not limited to the disclosed embodiments and is susceptible to numerous rearrangements, modifications, and permutations as set forth and defined in the following claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functionality performed by individual modules may be performed by one or more of those modules. Furthermore, the functionality described herein may be performed at various times in connection with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Furthermore, messages sent or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0153] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in both local and distributed fashions consistent with computing technology.

[0154] Note that some of the system features described herein are presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0155] Modules may also be implemented at least partially in software for execution by various types of processors. For example, an identified unit of executable code may include one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. Nevertheless, the executable files of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations that, when logically combined together, comprise a module and achieve the module's specified purpose. Furthermore, a module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, random access memory (RAM), tape, or any other such medium used to store data.

[0156] Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed across several different code segments, among different programs, and even across several memory devices. Similarly, operational data may be identified and depicted herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or may be distributed across different locations, including different storage devices, or may exist, at least in part, solely as electronic signals on a system or network.

[0157] It will be readily understood that the components of the present application, as generally described and illustrated herein, could be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments of the present application.

[0158] Those skilled in the art will readily appreciate that the above may be practiced in a different order of steps and / or with hardware elements in different configurations than those disclosed. Thus, while the 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 will be apparent.

[0159] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are by way of example only, and that the scope of the present application should be defined solely by the appended claims when considering the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. a memory configured to store a blockchain ledger; and 1. A processor, comprising: receiving a blockchain transaction that includes a state reference to an unspent transaction output (UTXO); determining whether the UTXO is included within a first subset of transactions on the blockchain ledger based on a zero-knowledge (ZK) proof included within the state reference; determining whether the UTXO is included in a second subset of transactions on the blockchain ledger based on a hash value included in the state reference; and committing the blockchain transaction including the state reference to the blockchain ledger in response to determining that the UTXO is not included in either the first subset or the second subset of transactions. a processor configured to: An apparatus comprising:

2. 2. The apparatus of claim 1, wherein the first subset of transactions is included within a first subset of blocks stored on the blockchain ledger prior to submission of the blockchain transactions to blockchain peers.

3. 3. The apparatus of claim 1 or 2, wherein the second subset of transactions is included within a second subset of blocks stored on the blockchain ledger after submission of the blockchain transactions to blockchain peers.

4. 3. The apparatus of claim 1 or 2, wherein the first subset of transactions is mutually exclusive from the second subset of transactions on the blockchain ledger.

5. 3. The apparatus of claim 1 or 2, wherein the hash value is created via hashing a serial number assigned to the state reference using a predefined hash function.

6. 6. The apparatus of claim 5, wherein the processor is further configured to retrieve a plurality of serial numbers assigned to input UTXOs consumed by the second subset of transactions from a pool of spent transactions stored on the blockchain ledger.

7. 7. The apparatus of claim 6, wherein the processor is further configured to hash the plurality of serial numbers based on the predefined hash function to generate a plurality of hashed comparisons and determine whether the hash value is equal to any of the hashed serial numbers.

8. 3. The apparatus of claim 1 or 2, wherein in response to determining that the UTXO is included in either the first subset or the second subset of transactions, the processor is further configured to determine that the blockchain transaction is invalid and store information identifying the blockchain transaction as invalid on the blockchain ledger.

9. receiving a blockchain transaction that includes a state reference to an unspent transaction output (UTXO); determining whether the UTXO is included in a first subset of transactions on a blockchain ledger based on a zero-knowledge (ZK) proof included in the state reference; determining whether the UTXO is included in a second subset of transactions on the blockchain ledger based on a hash value included in the state reference; and committing the blockchain transaction including the state reference to the blockchain ledger via a blockchain peer in response to determining that the UTXO is not included in either the first subset or the second subset of transactions. A method comprising:

10. 10. The method of claim 9, wherein the first subset of transactions is included within a first subset of blocks stored on the blockchain ledger prior to submission of the blockchain transactions to the blockchain peers.

11. 11. The method of claim 9 or 10, wherein the second subset of transactions is included within a second subset of blocks stored on the blockchain ledger after submission of the blockchain transactions to the blockchain peers.

12. 11. The method of claim 9 or 10, wherein the first subset of transactions is mutually exclusive from the second subset of transactions on the blockchain ledger.

13. 11. The method of claim 9 or 10, wherein the hash value is created by hashing a serial number assigned to the state reference using a predefined hash function.

14. 14. The method of claim 13, further comprising retrieving a plurality of serial numbers assigned to input UTXOs consumed by the second subset of transactions from a pool of spent transactions stored on the blockchain ledger.

15. 15. The method of claim 14, further comprising hashing the plurality of serial numbers based on the predefined hash function to generate a plurality of hashed comparisons, and determining whether the hash value is equal to any of the hashed serial numbers.

16. 11. The method of claim 9 or 10, further comprising, in response to determining that the UTXO is included in either the first subset or the second subset of transactions, determining that the blockchain transaction is invalid and storing information identifying the blockchain transaction as invalid on the blockchain ledger.

17. A computer comprising: receiving a blockchain transaction that includes a state reference to an unspent transaction output (UTXO); determining whether the UTXO is included in a first subset of transactions on a blockchain ledger based on a zero-knowledge (ZK) proof included in the state reference; determining whether the UTXO is included in a second subset of transactions on the blockchain ledger based on a hash value included in the state reference; and committing the blockchain transaction including the state reference to the blockchain ledger via a blockchain peer in response to determining that the UTXO is not included in either the first subset or the second subset of transactions. A computer program for executing

18. 20. The computer program product of claim 17, wherein the first subset of transactions is mutually exclusive from the second subset of transactions on the blockchain ledger.

19. 19. A computer program product as claimed in claim 17 or 18, wherein the hash value is created by hashing a serial number assigned to the state reference using a predefined hash function.

20. The computer, retrieving a plurality of serial numbers assigned to input UTXOs consumed by the second subset of transactions from a pool of spent transactions stored on the blockchain ledger; hashing the plurality of serial numbers based on a predefined hash function to generate a plurality of hashed comparisons; and 19. The computer program product of claim 17 or 18, further comprising the step of determining whether the hash value is equal to any of the hashed serial numbers.

Images