Noise transactions for data protection

Abstract

Example operations may include one or more of generating a blockchain request including blockchain data, creating a tag value that identifies whether the blockchain request is a noise request including bogus data or a non-noise request including non-noise data, storing the tag value in the blockchain request, and transmitting the blockchain request to one or more blockchain peers.

Description

[Background technology]

[0001] A centralized database stores data in a single database (e.g., a database server) and maintains it in one location. This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database is typically accessible from several different locations. Multiple users or client workstations can work simultaneously using the centralized database, for example, based on a client / server configuration. Because of its single location, a centralized database is easier to manage, maintain, and control, especially for security purposes. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a particular set of data contains only one primary record. Summary of the Invention

[0002] One example embodiment provides an apparatus including one or more of: a processor configured to perform one or more of: generating a blockchain request including blockchain data; creating a tag value that identifies whether the blockchain request is a noise request including bogus data or a non-noise request including non-noise data; and storing the tag value in the blockchain request; and a network interface configured to transmit the blockchain request to one or more blockchain peers.

[0003] Another example embodiment provides a method that includes one or more of: generating a blockchain request that includes blockchain data; creating a tag value that identifies whether the blockchain request is a noise request that includes bogus data or a non-noise request that includes non-noise data; storing the tag value in the blockchain request; and transmitting the blockchain request to one or more blockchain peers.

[0004] A further example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of: generating a blockchain request including blockchain data; creating a tag value that identifies whether the blockchain request is a noise request including bogus data or a non-noise request including non-noise data; storing the tag value in the blockchain request; and transmitting the blockchain request to one or more blockchain peers. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 illustrates a computing environment for submitting noise transactions, according to an example embodiment. [Figure 1B] FIG. 10 illustrates a process for recommending a noise transaction according to an example embodiment. [Figure 2A] FIG. 1 illustrates an exemplary blockchain architecture configuration, according to an example embodiment. [Figure 2B] FIG. 1 illustrates a blockchain transaction flow between nodes according to an example embodiment. [Figure 3A] FIG. 1 illustrates a permissioned network, according to an example embodiment. [Figure 3B] FIG. 1 illustrates another permissioned network, according to an example embodiment. [Figure 3C]FIG. 1 illustrates a permission-less network, according to an example embodiment. [Figure 4A] FIG. 10 illustrates a process for submitting a noise transaction proposal to a blockchain peer, according to an example embodiment. [Figure 4B] FIG. 10 illustrates the contents of a noise transaction proposal, according to an example embodiment. [Figure 5A] FIG. 1 illustrates a method for processing blockchain transactions based on tags, according to an example embodiment. [Figure 5B] FIG. 10 illustrates a method for storing a blockchain transaction that includes a tag, according to an example embodiment. [Figure 6A] FIG. 1 illustrates an exemplary system configured to perform one or more operations described herein, according to an example embodiment. [Figure 6B] FIG. 1 illustrates another exemplary system configured to perform one or more operations described herein, in accordance with an example embodiment. [Figure 6C] FIG. 10 illustrates yet another exemplary system configured to utilize smart contracts, in accordance with an example embodiment. [Figure 6D] FIG. 1 illustrates yet another exemplary system configured to utilize blockchain, according to an example embodiment. [Figure 7A] FIG. 1 illustrates the process of a new block being added to a distributed ledger, according to an example embodiment. [Figure 7B] FIG. 10 illustrates the data content of a new data block according to an example embodiment. [Figure 7C] FIG. 1 illustrates a blockchain for digital content, according to an example embodiment. [Figure 7D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment. [Figure 8A]FIG. 1 illustrates an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 8B] FIG. 1 illustrates an exemplary quantum-secure blockchain, according to an example embodiment. [Figure 9] FIG. 1 illustrates an exemplary system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0006] It will be readily understood that the components herein, as generally described and illustrated in the Figures 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 represented in the accompanying Figures, is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

[0007] 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 “example embodiments,” “some embodiments,” or other similar language throughout this specification indicates that particular features, structures, or characteristics described in connection with an embodiment may be included in at least one embodiment. Thus, the appearances of the phrases “example embodiments,” “in some embodiments,” “in 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 connections between elements may allow for one-way or two-way communication, or both, even if the connections shown are one-way or two-way arrows. 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 that information.

[0008] 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 example embodiments, the present application is not limited to the particular types of connections, messages, and signaling.

[0009] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that protect the confidentiality and differential privacy of a blockchain ledger by intentionally introducing noise transactions (blockchain content) into the blockchain network.

[0010] In one embodiment, the present application utilizes a distributed database (e.g., a blockchain), which is a distributed storage system containing multiple nodes communicating with each other. A distributed database includes an append-only, immutable data structure, similar to a distributed ledger, that allows records to be maintained among 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 verify the validity of blockchain-stored transactions, group those stored transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering the stored transactions, as necessary, for consistency. Various embodiments may use permissioned or permissionless blockchains. Public or permissionless blockchains allow anyone to participate without specific 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 within a group of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, or information.

[0011] A blockchain system stores data on an immutable ledger, provides distributed, decentralized access to the immutable ledger through distrusting participants, establishes consensus requirements for agreement among distrusting participants so that one entity cannot modify the immutable ledger without agreement from other entities, and invokes smart contracts. A blockchain is formed by a network of participants who agree to add blocks (containing data) to the immutable ledger. Before a block is added, it is linked to the previous block on the immutable ledger, thereby forming a chain. The immutable and incorruptible nature of a blockchain protects it from counterfeit information and hacking. Its decentralized nature also gives it an inherent trustless nature, in that parties do not need to establish trust before they can transact securely.

[0012] This application may utilize a blockchain that operates arbitrary programmable logic, called a "smart contract" or "chaincode," tailored to a distributed storage scheme. In some cases, a specialized chaincode, called a system chaincode, may exist for managing functions and parameters. Applications 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, called signatures or signature policies. Blockchain transactions (also referred to herein as blockchain requests) associated with this application can be "signed" before being committed to the blockchain, while unsigned transactions are ignored. The signature policy allows the chaincode to specify the signers of a transaction in the form of a set of peer nodes required for signing. When a client submits a transaction to a peer specified in the signature policy, a transaction is executed to validate the transaction. After validation, the transaction moves to the ordering phase, where a consensus protocol is used to generate an ordered sequence of signed transactions grouped into blocks.

[0013] This application may utilize nodes, which are the communicating 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 within trust domains and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submit-client nodes, which submit transaction calls to signers (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 can also have the role of signers, but this is not a requirement. An ordering service node or ordering node is a node that performs communication services for all nodes and enforces delivery guarantees, such as broadcasting to each of the peer nodes in the system when committing transactions and when modifying the blockchain's world state (another name for the initial blockchain transaction, which typically contains control and configuration information).

[0014] This application may utilize a ledger, which is an ordered, tamper-proof 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, signer nodes, peer nodes, etc.). Each participating party (e.g., peer node) may maintain a copy of the ledger. A transaction may result in a set of key-value pairs of assets being committed to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a blockchain (also called a chain) used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0015] 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 greater than or equal to 1. The block header contains a hash of the block's transactions and a hash of the previous block's header. In this way, all transactions in the ledger may be ordered and cryptographically linked together. Therefore, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that occurred before it, allowing all peer nodes to be assured of a consistent and reliable state. The chain may be stored in the peer node's file system (i.e., local, attached storage, cloud, etc.), which efficiently supports the append-only nature of blockchain workloads.

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

[0017] Blockchain ledgers are trusted storage systems because it is extremely difficult to change / tamper with data after it has been added to the ledger. In a permissioned blockchain network, a transaction is considered valid if a minimum (usually required) number of signer peers (e.g., indicated by a signature policy) reach consensus on the transaction by simulating the transaction against the current state of the ledger and verifying the client signature added to the transaction. If the client signature is valid and the simulation is successful, the signer node signs the transaction and returns a successful signing response. The transaction proposal is then forwarded to an ordering service, which adds the signed transaction to a block and broadcasts this block to the network's blockchain peers for commitment.

[0018] Maintaining confidentiality of data within a blockchain can be challenging. No system not part of the blockchain channel should be able to interpret the ledger / state of the blockchain channel. However, an attacker (e.g., a hacker, an unauthorized system, etc.) can attempt to steal the blockchain ledger by listening to an unauthorized channel associated with the blockchain. In response, an attacker can gain access to the contents of the blockchain ledger from outside the blockchain by pinging the channel. Attacks can also come from within the blockchain channel. Members within a blockchain are typically required to share the ledger and state. To protect this ledger data, members often encrypt the data, which can incur significant overhead. Furthermore, based on a member's transaction patterns, sensitive data may be exposed.

[0019] Advantages of example embodiments include preventing attackers from interpreting the blockchain ledger and maintaining data confidentiality by introducing noise data (false data) into the blockchain. For example, a client, smart contract, agent, etc. may introduce a noise transaction that is processed like a standard blockchain transaction but includes a unique identifier indicating that the transaction is noise. The noise transaction can be identified and ignored by the blockchain members / participants involved in the noise transaction using the unique identifier. However, other blockchain users and unauthorized users who do not recognize the unique identifier may process the noise transaction as usual and incorrectly update their copies of the blockchain ledger, thereby creating an obfuscated state that protects the confidentiality of the clients involved in the noise transaction. As a result, unauthorized users cannot correctly interpret the ledger with respect to the transaction history of such clients. Therefore, the state of the blockchain ledger can be maintained without introducing significant performance and management overhead between blockchain peers.

[0020] A noise transaction can only be understood by the creator of the noise transaction (e.g., client, peer, etc.) and blockchain accessors / participants who are aware of the noise transaction. Clients and / or blockchain peers may cooperatively manage and share a key that can be used to encrypt / decrypt the tag. The tag may be a value that specifies whether a transaction is noise data or genuine data (non-noise). For example, the tag may include a Boolean value where one value indicates noise and another value indicates non-noise, but embodiments are not limited to this. The tag may be encrypted so that only clients / blockchain peers that belong to the noise transaction and have the decryption key can understand the tag. Here, the tag may be encrypted using a public key, and participating clients and peers may share the corresponding private key that can successfully decrypt and read the tag to understand whether the transaction is noise.

[0021] The key may be a cryptographic key shared among participants. For example, participants may implement a key agreement scheme such as a decentralized public key infrastructure (PKI), peer-to-peer (P2P), or the like. Peers and clients that know the key may detect that a noise transaction is noise by decrypting the tag value. However, peers and clients that do not receive the key cannot decrypt the tag to determine whether the transaction is noise and treat the transaction as normal. Thus, the unaware peers or clients incorrectly update the blockchain and state database. In some embodiments, the blockchain network may encrypt the tag value using multiple keys. In this case, the client and / or blockchain peer creating the transaction may add a key identifier to the transaction to identify which shared secret key is used to encrypt the tag value.

[0022] A noise transaction (also referred to herein as a noisy blockchain request) may be collaboratively created by a group of clients whose data in the world state database is affected by the noise transaction. In this case, the noise transaction is perceived as noise by the group of clients, but not by other, uninvolved clients. Thus, when uninvolved clients review the noisy transaction (e.g., in the future), the noisy transaction will appear to be a normal / standard transaction. Generally, a noise transaction will be perceived simply as noise by the subset of clients that created it. In doing so, clients can disguise transaction patterns, including transaction frequency, transaction content, etc., to maintain the privacy of data on the blockchain. Additionally, all transactions (whether noisy or not) may include a tag value that can be obfuscated and revealed only by clients with access to the shared secret.

[0023] For example, a noise transaction may add additional shipping records and dates to conceal shipping patterns. In this example, new key values ​​reflecting these additional noisy shipping records are added to the blockchain ledger (world state database) by an uninformed peer and seen by an uninformed client. As another example, a noise transaction may add additional sales activity between a buyer and a seller to obscure a contractual relationship. In this case, the additional sales activity is added to the blockchain ledger (world state database) by an uninformed peer. Many other situations are possible, and these examples are not intended to be limiting.

[0024] The use of noise transactions may protect the privacy of the transactions themselves because an attacker cannot identify whether a particular transaction is valid data or noise data. As another example, the use of noise transactions may protect user privacy by preventing an attacker from discerning whether a pattern of transactions belongs to a particular user. In some embodiments, noise transactions may be randomly created. As another example, noise transactions may be created based on past transaction data stored on the blockchain. In other words, a smart contract, agent, client, etc. may monitor and identify patterns of behavior on the blockchain and introduce noise transactions based on such patterns of behavior. The patterns of behavior may be used to identify "believable" noise transactions. As another example, the patterns of behavior may be used to create new patterns of behavior, including noise transactions.

[0025] Example embodiments provide a lightweight approach to protecting the contents of a blockchain using differential privacy. Noise transactions and users may be injected into a blockchain system to prevent attackers from learning privacy-related knowledge from the blockchain. Unique tags may be used by member participant peers to interpret transactions as noise data or authentic / live data. Furthermore, the noise information within the noise transactions may be organized in a way that does not affect the correctness of normal blockchain operations (e.g., signatures, consensus, read / write sets, etc.).

[0026] FIG. 1A illustrates a computing environment 100A for submitting noise transactions, according to an example embodiment. Referring to FIG. 1A , client 121 and client 122 conduct transactions with one another (e.g., transfer funds, Internet of Things (IoT) data, etc.). The transactions may be processed by a network of blockchain peers 111, 112, 113, 114, and 115. For example, transaction data may be signed by signer nodes between blockchain peers, added / ordered within a block, and recorded in blockchain 110. In standard blockchain transactions (i.e., simply referred to herein as transactions), the transaction data is assumed to be live data. However, in an example embodiment, the transaction may be a noise transaction that includes false data.

[0027] For example, a smart contract, client, agent, etc. may randomly generate noise transactions between client 121 and client 122. This randomness may guarantee differential privacy. As another example (shown in FIG. 1B), a smart contract, client, agent, etc. may analyze historical ledger data and recommend noise transactions. Thus, a noise transaction proposal may be submitted by client 121, client 122, a blockchain peer, etc. and processed by the blockchain network of peers shown in FIG. 1A. In this example, all of the blockchain peers except for blockchain peer 113 know the encryption key used to obfuscate the noise transaction. For example, a tag value may be added to the transaction proposal and may be encrypted using the encryption key. The tag value is one piece of encrypted information in a blockchain transaction. The same tag may have different meanings to different blockchain clients depending on whether the client can decrypt the tag. If the client can decrypt the tag, the client can tell whether the transaction is a noise transaction based on the decrypted tag value. If the client is unable to decode the tag, the client SHOULD treat this transaction as a non-noise transaction.

[0028] In this case, the transaction data may be processed normally by the blockchain network (e.g., signed, agreed upon, etc.) and added to a block, which is then submitted to each of the blockchain peers 111-115 for storage. However, the noise transaction is not stored / recorded in the world state database on the blockchain ledger and does not affect the state of the blockchain. When updating / committing new blocks to the blockchain ledger, the blockchain peers 111, 112, 114, and 115 may detect the noise transaction and ignore it by not updating the world state database. However, the blockchain peer 113 cannot detect the noise transaction because it cannot decode the tag value. Therefore, the blockchain peer 113 processes the noise transaction normally and incorrectly updates its local copy of the world state database on the blockchain ledger, thereby obscuring the state of the blockchain with respect to transactions involving the client of the noise transaction.

[0029] 1B illustrates a process 100B for recommending a noise transaction according to an example embodiment. With reference to FIG. 1B, a smart contract 140 may analyze historical transaction data stored in a blockchain ledger 110 and recommend a noise transaction 142 based on the historical transaction data on the blockchain ledger 110. It should be understood that other entities, including but not limited to clients, agents, etc., may recommend noise transactions on behalf of the smart contract 140.

[0030] In this example, smart contract 140 may analyze historical client data 131, 132, 133, etc. Here, smart contract 140 may analyze historical client data 131, 132, and 133 and recommend noise transactions between client A and client B. Smart contract 140 may derive the frequency of transactions between the client and all other clients in the system within a specific time period from the historical data 131, 132, and 133. For example, a frequency distribution may be identified from the historical data 131, 132, and 133. This frequency distribution may include the transaction patterns of clients A and B. Smart contract 140 may determine how to perturb this frequency distribution using random noise with differential privacy guarantees. Perturbing the frequency distribution may be achieved by adding noise transactions with other clients in the system or by adding fake transactions between clients A and B. As will be further described with respect to Figures 4A-4B, a unique tag may be added to every transaction to identify / distinguish noise transactions from live / authentic transactions.

[0031] After determining the proposed / recommended noise transaction 142, the smart contract 140 and / or the blockchain peers may provide the proposed noise transaction 142 to one or more of the clients 121 and 122 shown in FIG. 1A. Here, both clients 121 and 122 may approve the noise transaction including their clients and submit the transaction to one or more signer peers, thereby submitting the noise transaction to the blockchain. Although not shown in FIG. 1A, clients that submit noise transactions to the blockchain may be noisy clients in that they do not actively participate in the blockchain but can be identified as real entities.

[0032] 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 (four nodes are shown by way of example only). These nodes participate in multiple activities, such as adding and validating blockchain transactions (agreements). One or more of the blockchain nodes 204-210 may sign transactions based on a signature policy and provide an ordering service for all blockchain nodes in the architecture 200. A blockchain node may initiate a blockchain validation and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 216; a copy of this write may also be stored in the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to application programming interfaces (APIs) 222 for accessing and executing stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations requested by participants, maintain their own state, control their own assets, and receive external information. Blockchain configurations can be installed on all blockchain nodes 204-210 by deploying them as transactions and adding them to the distributed ledger.

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

[0034] The blockchain architecture 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 assets on the blockchain. For example, the code 220 may store and transfer data and be executed by the nodes 204-210 in the form of associated chaincode containing smart contracts and conditions or other code elements subject to execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, or changes, other notifications subject to updates, or combinations thereof. The smart contract itself may be used to identify authorization and access requirements and rules associated with ledger use. For example, a smart contract (or chaincode executing the smart contract logic) may read blockchain data 226, which, in the context of complex services, 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, liability determinations, and the like. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

[0035] Smart contracts may be created using 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 to the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition associated with the smart contract being satisfied. Execution of a smart contract may trigger trusted changes to the state of the digital blockchain ledger. Changes to the blockchain ledger caused by smart contract execution may be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0036] A smart contract may write data to the blockchain in the form of key-value pairs. Additionally, smart contract code can read values ​​stored on the blockchain and use them in the operation of an application. The smart contract code can write the output of various logical operations to one or more blocks in the blockchain. This code may be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can become public and / or be kept private and encrypted. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and deleted after the data needed for the blockchain has been identified.

[0037] 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 and executed together and validated by chain validators during the consensus process. Chaincode may receive a hash and retrieve a hash from the blockchain associated with a data template created by use of a previously stored feature extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0038] FIG. 2B illustrates an example 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 a signing peer node 281. The signing peer 281 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read into the chaincode (the read set), and a set of key / values ​​written into the chaincode (the write set). The signing peer 281 may then decide whether to sign the transaction proposal. A proposal response 292 is sent back to the client 260, along with the signature if approved. The client 260 assembles the signature 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 on a channel to all peers 281-283. Before committing to the blockchain, each peer 281-283 may verify the validity of the transaction. For example, a peer may check the signature policy to ensure that the correct allocation of the designated peer signed the result and authenticated the signature on the transaction payload 293.

[0039] Additionally, before committing each transaction to the blockchain, peers 281-283 may check a tag value (which may be encrypted) included in the transaction to determine whether the transaction is a real / authentic transaction or a noise transaction containing false data. If the tag indicates that the transaction is noise, peers 281-283 may determine that the transaction is fake and ignore the transaction. However, if the tag indicates that the transaction is non-noise (i.e., actual data to be stored in the blockchain), peers 281-283 may store the data in their local copies of the world state database.

[0040] Referring again to Figure 2B, a client node initiates a transaction 291 by constructing and sending a request to a peer node 281 (the signer). The client 260 may include an application utilizing a supported software development kit (SDK), which utilizes available APIs to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read from the ledger, written to the ledger (i.e., writing a new key-value pair for an asset), or both. The SDK may act as a shim to package the transaction proposal into a suitably designed format (e.g., protocol buffers via remote procedure call (RPC)), receive the client's cryptographic credentials, and generate a unique signature for the transaction proposal.

[0041] In response, the signing peer node 281 may verify that (a) the transaction proposal is properly 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) has the appropriate permissions to perform the proposed operation on that channel. The signing peer node 281 may receive 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, no updates are made to the ledger at this time. At 292, the set of values, along with the signing peer node's 281 signature, is returned as a proposal response 292 to the client's 260 SDK, which parses the payload for use by the application.

[0042] In response, the client 260 application inspects / verifies the signing peer's signature and compares the proposal response to determine whether the proposal response is the same. If the chaincode simply queries the ledger, the application inspects 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 signature policy has been satisfied (i.e., whether all required peer nodes for the transaction have signed the transaction) before submitting. Here, the client may include only one of multiple parties in the transaction. In this case, each client may include its own signing node, and each signing node must sign the transaction. The architecture ensures that the signature policy is still enforced by peers and maintained in the commit validation phase, even if the application chooses not to inspect the response or otherwise forwards an unsigned transaction.

[0043] After successful verification, in step 293, the client 260 assembles the signatures into a transaction proposal and broadcasts the transaction proposal and transaction response in a transaction message to the ordering node 284. The transaction may include a read / write set, the signing peer's signature, and a channel ID. The ordering node 284 does not need to inspect the entire contents of the transaction to perform its operation; instead, the ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions for each channel.

[0044] The block is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The data section in the block may be validated to ensure that the signature policy is met and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the transaction's execution. Additionally, at 294, the tag value may be decoded and checked to ensure that the transaction data is not noise transaction data. Furthermore, at step 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database unless the transaction is noise. Events may be emitted to notify the client application that the transaction (invocation) has been immutably added to the chain and whether the transaction has been validated or invalidated.

[0045] FIG. 3A illustrates an example of a permissioned blockchain network 300, which features 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 can be a deployment, invocation, or query and can be issued through a client-side application utilizing 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 can be limited to only querying the ledger, while clients can be granted permission to deploy, invoke, and query certain types of chaincode.

[0046] A blockchain developer 310 can write chaincode and client-side applications. Through an interface, the blockchain developer 310 can deploy the chaincode directly to the network. To include authentication information 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 initiating any transactions, the peer node 314 obtains user registration and transaction certificates from a certificate authority 316, which manages user roles and permissions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 304. Meanwhile, users seeking to utilize chaincode may need to verify their user credentials on 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.

[0047] FIG. 3B illustrates another example of a permissioned blockchain network 320, which features 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 can be deploys, invokes, or queries and may be issued through a client-side application utilizing an SDK, directly through an API, or the like. 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 can be limited to only querying the ledger, while clients can be granted permission to deploy, invoke, and query certain types of chaincode.

[0048] A blockchain developer 330 writes chaincode and client-side applications. Through an interface, the blockchain developer 330 can deploy the chaincode directly to the network. To include authentication information 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. The peer node 334 obtains the user's registration and transaction certificate from a certificate authority 336 before initiating any transactions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 324. Meanwhile, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0049] In some embodiments, a blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions, thus adding entries to the ledger. Furthermore, any participant may choose to run a node on the system and adopt a mining protocol to help validate transactions.

[0050] FIG. 3C illustrates a transaction process 350 being processed by a permissionless blockchain 352 that includes multiple nodes 354. A sender 356 wishes to transmit a payment or other form of value (e.g., a certificate, medical records, a contract, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, the sender device 356 and the receiver device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and display of transaction parameters. In response, the transaction is broadcast to nodes 354 throughout the blockchain 352. 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 permissionless blockchain 352. For example, this validation may include verifying the identities of the parties involved. The transaction may be validated immediately, or the transaction may be placed in a queue with other transactions, and node 354 determines whether the transaction is valid based on a set of network rules.

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

[0052] Before a block can be added to the blockchain, it must be validated. Validation in 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 Figure 3C, is proof-of-stake. Unlike proof-of-work, in which an algorithm rewards miners for solving a mathematical problem, in proof-of-stake, the creator of a new block is selected deterministically according to their wealth (also defined as "stake"). Similar proofs are then performed by the selected nodes.

[0053] 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 proof of work, thereby guaranteeing a correct answer. In other words, a possible solution must prove that computational resources were expended in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0054] Here, the PoW process makes it extremely difficult to modify the blockchain, along with the block changes, because an attacker must modify all subsequent blocks to accept a change to one block. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and so does the number of subsequent blocks. In distribution 366, successfully validated blocks are distributed throughout the permissionless blockchain 352, and all nodes 354 add the blocks to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to a digital wallet on the receiving device 358.

[0055] FIG. 4A illustrates a process 400A for submitting a noise transaction proposal 440 to blockchain peers according to an example embodiment, and FIG. 4B illustrates the contents within the transaction proposal 440 according to an example embodiment. Referring to FIG. 4A, a noise transaction may be sent from a client 402 to one or more signer nodes (not shown), as described in the example of FIG. 2B. If properly signed, the client 402 may submit the transaction proposal 440 to an ordering service (e.g., ordering node 410) of the blockchain network based on the signature. In response, the ordering node 410 may combine the transaction proposal 440 with other transaction proposals, which may include non-noise transaction proposals, noise transaction proposals, or both, to create a new block 450 that is added to the blockchain network's distributed blockchain ledger. After the block 450 is created, the ordering node 410 may broadcast the block 450 to the blockchain network's blockchain peers for validation and commitment to their respective blockchain ledgers.

[0056] The example in Figure 4A shows two blockchain peers 420 and 430, each storing its own version of a blockchain ledger (blockchain ledger 422 and blockchain ledger 432). In this example, blockchain peer 420 is an authorized participant in the blockchain network and contains a shared secret key shared by the client and / or blockchain peer submitting noise data. Meanwhile, blockchain peer 430 is an unauthorized peer listening to a channel in the blockchain network. Here, blockchain peer 430 does not have the corresponding shared secret key.

[0057] Each blockchain peer 420 and 430 may receive block 450 and update their respective blockchain ledgers 422 and 432 based on the individual transactions in block 450, including transaction proposal 440. The content in transaction proposal 440 may include a tag value 446 that identifies transaction proposal 440 as a noise transaction (fake data) or a genuine transaction. In this case, tag value 446 indicates that the transaction is fake / noise. It should also be understood that non-noise transactions containing valid / live data may also include a tag value that identifies the transaction as non-noise (valid, live, etc.).

[0058] The tag value 446 may be encrypted using a shared encryption key known to the blockchain peers 420 but not to the unauthorized peers 430. The blockchain peers 420 may detect that the noise transaction proposal 440 is a noise transaction by decrypting the tag value 446 and identifying the Boolean indicator (or other tag value). In this manner, the blockchain peers 420 may skip or otherwise ignore state changes to the blockchain ledger in the noise transaction proposal 440. Meanwhile, unauthorized peers 430 may not be able to decrypt such tag values ​​446 and determine that the transaction proposal 440 is noise. Thus, the unauthorized peers 430 may process the noise transaction proposal 440 as a standard transaction and update the blockchain ledger 432 accordingly.

[0059] 4A, blockchain peer 420 has its own copy of the correct (i.e., unobscured) blockchain ledger (ledger 422) because noise transaction proposal 440 was ignored and not added to the world state database on blockchain ledger 422. Meanwhile, blockchain peer 430's blockchain ledger 432 is in an obscured state because the content from noise transaction proposal 440 has been added to ledger 432 (e.g., updated key-value pairs in state database 460). Thus, the transaction patterns of clients involved in the noise transaction are obscured and protected.

[0060] FIG. 4B illustrates an example of the contents of a transaction proposal 440 described with respect to FIG. 4A. The transaction proposal 440 may be stored in block 450 along with other transaction proposals. When processed, the transaction proposal may be used to update key-value pairs stored in world state 460, which stores the latest values ​​of all key-value pairs on the blockchain. As shown in FIG. 4B, the transaction proposal 440 contains the same components as a regular blockchain transaction, with the exception of a tag value 446, which may be encrypted and identifies whether the transaction is noise, and a key identifier 447, which identifies the encryption key used to encrypt the tag value 446. By keeping the transaction format the same, unauthorized parties are unaware that the transaction may be noise data.

[0061] For example, transaction proposal 440 may include header 441, which captures essential metadata about the transaction, such as the name of the chaincode and its version, and signature 442, which contains the cryptographic signature of client 402 that created submitted transaction proposal 440. Transaction proposal 440 also includes signature 445, which contains a list of signed transaction responses from each signer required to satisfy the signature policy.

[0062] Transaction proposal 440 also includes proposal 443, which includes input parameters for the smart contract, and response 444, which includes the read / write set of the signer node. In this example, transaction proposal 440 is a noise transaction. Therefore, proposal 443 includes noise / fake data. Proposal 443 may encode noisy input parameters that are provided to the smart contract / chaincode, which creates a proposed noisy update to the blockchain ledger. When the smart contract logic executes, proposal 443 provides the noise input parameters (e.g., key-value pairs) used to determine a new world state relative to the current world state. Transaction proposal 440 also includes a fake response 444, which captures the before and after values ​​of the world state as a read / write set including noise data. Response 444 is the output of the smart contract based on the noise input from proposal 443.

[0063] FIG. 5A illustrates a method 500 for processing blockchain transactions based on tags, according to an example embodiment. As a non-limiting example, method 500 may be performed by a client application, a smart contract on a blockchain peer, a blockchain agent system, etc. Referring to FIG. 5A, at 502, the method may include generating a blockchain request that includes blockchain data. For example, the blockchain request may include a blockchain transaction configured to invoke a chaincode. The blockchain request may include a key value to be changed on the blockchain ledger.

[0064] In some embodiments, generating may include generating a noisy blockchain request that includes false blockchain data, and creating may include creating a tag value that identifies the blockchain request as noise. In this example, the false data may include false blockchain key values, and the tag value may include a Boolean value. In some embodiments, generating may include generating a non-noisy blockchain request that includes live blockchain data, and creating may include creating a tag value that identifies the blockchain request as live data.

[0065] At 504, the method may include creating a tag value that identifies whether the blockchain request is a noise request containing false data or a non-noise request containing non-noise data. For example, the tag value may include a Boolean value where “true” indicates noise and “false” indicates non-noise, or vice versa. In some embodiments, the method may further include obfuscating the tag value based on a private key and storing a key identifier value in the blockchain request that identifies the private key used to obfuscate the tag value. For example, the key identifier may distinguish which encryption key is used when multiple encryption keys are used in a blockchain network. In some embodiments, the private key may include a public key of a symmetric public-private key pair, where the private key is shared by blockchain peers that are members of the blockchain.

[0066] At 506, the method may include storing the tag value in a blockchain request, and at 508, the method may include sending the blockchain request to one or more blockchain peers. In some embodiments, the method may further include receiving a signature and a read / write set for the noise blockchain request from a blockchain signer peer, and storing the signature and the read / write set in the noise blockchain request. In some embodiments, generating may include generating the noise blockchain request based on historical patterns of client behavior on the blockchain.

[0067] FIG. 5B illustrates a method 510 for storing blockchain transactions including tags, according to an example embodiment. Referring to FIG. 5B, at 512, the method may include receiving a blockchain request including a tag value that identifies whether the blockchain request is a noise request including false data or a non-noise request including non-noise data. For example, the blockchain request may be a noise blockchain request including false data in the blockchain, and the tag value may include a tag value that identifies the blockchain request as noise. In some embodiments, the false data may include a false key value in the blockchain, and the tag value may include a hash value previously agreed upon by the creator of the noise blockchain request.

[0068] At 514, the method may include verifying that the blockchain request is signed by enough blockchain peers to satisfy a predetermined policy. For example, this verification may include verifying signatures and read / write sets for the noise blockchain request from signer peers of the noise blockchain request. In response to successful verification, at 516, the method may include storing the blockchain request including the tag value in the data block among the hash-linked chains of the data block.

[0069] In some embodiments, the tag value may include an obfuscated tag value that is obfuscated based on a private key, and the processor is further configured to store a key identifier value of the private key in the data block. In some embodiments, the private key may include a public key of a symmetric public-private key pair, and the private key is shared by the blockchain client in the blockchain network that created the noise blockchain request but not by other blockchain clients in the blockchain network. In some embodiments, the blockchain request may be a non-noise blockchain request that includes live blockchain data, and the tag value may include a value that identifies the blockchain request as not noise to the blockchain client that created the blockchain request.

[0070] FIG. 6A illustrates an example system 600 including a physical infrastructure 610 configured to perform various operations according to example embodiments. 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 in the blockchain 620), which may perform any of the operational steps 608 (within the module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to 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, or wireless communication devices, or a combination thereof. Additionally, the modules 612 and 614 may be the same module.

[0071] FIG. 6B illustrates another exemplary system 640 configured to perform various operations according to example embodiments. Referring to FIG. 6B, system 640 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside in blockchain 620), which may perform any of the operational steps 608 (within module 612) included in any of the example embodiments. Steps / operations 608 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to 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, or wireless communication devices, or a combination thereof. Furthermore, module 612 and module 614 may be the same module.

[0072] FIG. 6C illustrates an exemplary system configured to utilize an intermediary server configured to configure smart contracts between contracting parties and enforce the terms of the smart contracts on a blockchain, according to an example embodiment. Referring to FIG. 6C, configuration 650 may represent a communication session, an asset transfer session, or a process or procedure operated by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the execution of the smart contract 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 participants in the smart contract transaction. The results of the execution of the smart contract 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.

[0073] FIG. 6D illustrates a system 660 including a blockchain, according to an example embodiment. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing the blockchain's logic (e.g., smart contracts 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.) against the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the servers 654 are peer components of the blockchain network that maintain copies of the world state and the distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where the signing peers execute the smart contracts 630 according to the smart contracts 630 and signing policies.

[0074] The foregoing embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or any combination thereof. The computer program may be embodied in 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.

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

[0076] FIG. 7A illustrates a process 700 for a new block being 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 a blockchain according to an example embodiment. Referring to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, or 713, or a combination thereof. A client may be an instruction received from any source to specify an activity on the blockchain 720. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, that proposes a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain copies of the blockchain network state and the distributed ledger 720. Various types of blockchain nodes / peers may exist within a blockchain network, including signing peers that simulate and sign transactions proposed by clients, and commit peers that verify signatures, confirm the validity of the transactions, and commit the transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the role of signer nodes, committer nodes, or both.

[0077] The distributed ledger 720 includes a blockchain, which stores immutable, ordered records in blocks, and a state database 724 (current world state), which 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 contain various components, such as those shown in Figure 7B. Block links (shown by arrows in Figure 7A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored in the file system (local or attached storage) of a peer supporting additional dedicated blockchain workloads.

[0078] The current state of the blockchain 722 and distributed ledger 720 may be stored in a state database 724, where the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 722. Chaincode invocations 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 and therefore can be regenerated off-chain at any time. The state database 724 may be automatically restored (or generated if necessary) upon peer startup, before any transactions are received.

[0079] The signing node receives transactions from clients and signs them based on the simulation results. The signing node holds a smart contract that simulates the transaction proposal. When the signing node signs a transaction, it generates a transaction signature, which is a signed response from the signing node to the client application indicating the signature of the simulated transaction. The way in which a transaction is signed is determined by a signature policy, which may be specified in the chaincode. An example of a signature policy is "a majority of the signing peers must sign the transaction." Different channels may have different signature policies. The signed transaction is forwarded by the client application to the ordering service 710.

[0080] The ordering service 710 receives signed 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 in the blockchain 720. The first block in a blockchain may be called a genesis block, which contains information about the blockchain, its members, the stored data, etc.

[0081] The ordering service 710 may consist of a cluster of ordering nodes. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may receive signed 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.

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

[0083] The ordering service 710 may initialize a new data block 730, which may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer verifies the validity of the transactions in the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. In particular, the committing peer may determine whether the read data that existed when the signer simulated the transaction is identical to the current world state in the state database 724. If the committing peer verifies the validity of the transaction, the transaction is written to the blockchain 722 of 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 commit peer detects that the read / write set does not match the current world state in state database 724, the transactions ordered in the block are still included in that block but are marked as invalid and state database 724 is not updated.

[0084] 7B, a new data block 730 (also referred to as a data block) stored in the blockchain 722 of the 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 the new data block 730 and its contents illustrated in FIG. 7B, are exemplary only and are not intended to limit the scope of example embodiments. In a conventional block, a data section may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the data block 750.

[0085] The new data block 730 may include a link to the previous block (e.g., on the blockchain 722 of FIG. 7A) in the block header 740. In particular, the block header 740 may include a hash of the previous block's header. The block header 740 may also include a unique block number for the new data block 730, a hash of the block data 750, etc. The block numbers for the new data block 730 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

[0086] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, and the last persistent offset of the ordering service that ordered the block. The signature, last constituent block, and ordering node metadata may be added by the ordering service 710. Meanwhile, the block committer (e.g., blockchain node 712) may add valid / invalid information based on signature policies, validation of the read / write set, etc. The transaction filter may include a byte array with a size equal to the number of transactions included in block data 750 and a validation code that identifies whether the transaction was valid or invalid.

[0087] Figure 7C illustrates an embodiment of a blockchain 770 for digital content, in accordance with embodiments described herein. Digital content may include one or more files and associated information. These files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of blockchain serves as a safeguard to protect the integrity, validity, and authenticity of digital content, making it appropriate for use in legal proceedings where admissibility rules apply, or in other settings where evidence is considered or the presentation and use of digital information is otherwise subject. In this case, the digital content may be referred to as digital evidence.

[0088] A blockchain may be formed in a variety of ways. In one embodiment, digital content may be contained in and accessed from the blockchain itself. For example, each block in the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with the 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 the previous block. 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

[0089] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the contents of each block that does not contain digital content. The digital content may be stored in a separate storage area or memory address relative to 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 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 in question and then searching the storage area for the stored hash value that corresponds to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Area Hash value of block 1 Hash value of block 1 Contents · · · · · · Hash value of block N Hash value of block N...Contents

[0090] 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 either multiple keyed or unkeyed hash functions. Nare subjected to a hash function (where n is 256 or another number) that generates an n-bit alphanumeric output from the 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 non-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 given with reference to a hash function (e.g., SHA-2).

[0091] Blocks 7781, 7782, ... 778 in the blockchain N Each of the file versions includes a header, a file version, and a value. The header and value vary from block to block as a result of hashing within 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.

[0092] The first block 7781 in a blockchain is called the genesis block and contains a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used for the genesis block (and indeed for all subsequent blocks) may vary. For example, all of the information in the first block 7781 may be hashed together simultaneously, 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.

[0093] 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, or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., by blockchain network management software) or manually by a participant in the blockchain. Other blocks 7782-7783 in the blockchain N Unlike the headers in the 7721 block, the header in the genesis block does not reference a previous block, simply because there is no previous block.

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

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

[0096] Other blocks in the blockchain: 7782-778 N Each block also contains a header, a file, and a value. However, unlike the first block 7721, the headers 7722 to 7723 in the other blocks N Each of the remaining blocks contains the hash value of the immediately preceding block, which may simply be the hash of the previous block's header, or it may be the hash value of the entire previous 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 shown by arrow 780, from the Nth block back to the genesis block (and associated original files), establishing an auditable and immutable chain of custody.

[0097] Headers 7722 to 772 in other blocks N Each of the may generally include other information (e.g., a version number, a timestamp, a nonce, root information, difficulty level, consensus protocol, or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof).

[0098] Files 7742 to 774 in other blocks N A block may be the same as the original file in the genesis block, or it may be a modified version of the original file, depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any modification of the file in the preceding block, such as, for example, editing or otherwise changing the content of information, removing information from the file, or adding information to the file.

[0099] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an operation on a file and / or associated metadata in the blockchain. Processing including analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

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

[0101] For example, consider the case where a portion of a file in a previous block is redacted, blocked, or pixelated to protect the identity of a person indicated in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp when the edit occurred, etc. This metadata may be hashed to form a value. Because the block's metadata is different from the information hashed to form the value in the previous block, the values ​​are different from each other and may be recovered when decrypted.

[0102] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block if 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 set forth below: a) A new SHA-2 computed hash value whenever the file is processed in any way (e.g., when the file is edited, copied, modified, accessed, or any other action is performed on it). b) The new storage location of the file c) Identified new metadata associated with the file d) Transfer of file access or control from one blockchain participant to another blockchain participant

[0103] FIG. 7D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 790, according to one example embodiment. i ) is header 772 i , File 774 i , and the value 776 i Contains:

[0104] Header 772 i is the previous block (block i-1 ) and additional reference information, which may be any type of information (e.g., header information containing references, properties, parameters, etc.). Every block references the hash of the previous block, except of course for the genesis block. The hash of the previous block may simply be the hash of the header in the previous block, or it may be the hash of all or part of the information in the previous block, including files and metadata.

[0105] File 774 icontains multiple pieces of data, such as Data 1, Data 2, ..., Data N, in turn. The data are tagged with Metadata 1, Metadata 2, ..., Metadata N, which describe content and / or characteristics associated with the data. For example, the metadata for each piece of data may include information to indicate a timestamp for the data, keywords indicating the process of the data, people or other content depicted in the data, or other characteristics that establish the validity and content of the file as a whole and can be particularly useful for using digital evidence, for example, as described in connection with the embodiments described below, or any combination thereof. In addition to the metadata, each piece of data may contain a reference to the previous piece of data (Reference 1, Reference 2, ..., Reference N) to prevent tampering, gaps within the file, and sequential referencing throughout the file. N ) may be tagged.

[0106] After metadata is assigned to data (e.g., via a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Thus, the metadata creates a data log of information that may be accessed for use by participants in the blockchain.

[0107] Value 776 i is a hash value or other value calculated based on any of the types of information previously described. For example, i ), the value of that block may be updated to reflect the operation performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, control or access transfer, identifier, or other action or added information). Although the values ​​in each block are shown as being separate from the metadata of the file and header data, in other embodiments, the values ​​may be based in part or in whole on this metadata.

[0108] At any point after the blockchain 770 is formed, an immutable archival record of the file may be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracking procedure may begin by decrypting the value of the last included block (e.g., the last (Nth) block), and then continue decrypting values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may further include decoding the header and file and associated metadata in each block.

[0109] Decryption is performed based on the type of encryption performed on each block. This decryption may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor within the network may generate a public and private key pair using a predefined algorithm. The public and private keys are related to each other by some mathematical relationship. The public key may be publicly distributed to serve as an address (e.g., an IP address or home address) for receiving messages from other users. 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 confident that only the sender could have sent the message.

[0110] Generating a key pair is similar to creating an account on the blockchain, but in reality, there is no need to 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 (within the scope of permissions determined by the smart contract) can track and transact on files on the blockchain.

[0111] Figures 8A and 8B illustrate additional use cases for blockchain that may be incorporated and used herein. In particular, Figure 8A illustrates an example 800 of a blockchain 810 storing machine learning (artificial intelligence) data. Machine learning relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks) can sift through millions of records to discover often non-intuitive patterns.

[0112] In the example of FIG. 8A , a host platform 820 builds and deploys machine learning models for predictive monitoring of assets 830. Here, the host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The assets 830 may be any type of asset (e.g., machinery or equipment), such as an aircraft, a locomotive, a turbine, medical equipment, oil and gas equipment, a boat, a ship, a vehicle, etc. As another example, the assets 830 may be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0113] 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, in 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, smart contracts can be used to transfer data directly and reliably from its original location to the blockchain 810. The smart contract can send data directly from the asset to the individual who uses the data to build the machine learning model, using the blockchain 810 to ensure the security and ownership of the collected data. This enables the sharing of data between assets 830.

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

[0115] Furthermore, training the machine learning model on the collected data may require a series of refinements and tests by the host platform 820. Each refinement and test may be based on additional data or data not previously considered to help expand the machine learning model's knowledge. At 802, the host platform 820 may store the different training and testing steps (and associated data) on the blockchain 810. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored on the blockchain 810, thereby providing verifiable proof 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.

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

[0117] New transactions on the blockchain can be collected together in a new block and added to an existing hash value. This hash value is then encrypted to generate a new hash for the new block. This new hash is added to the next list of transactions, such as when the transaction is encrypted. The result is a chain of blocks, each containing the hash values ​​of all preceding blocks. Computers storing these blocks periodically compare the hash values ​​of the blocks to ensure they are all in agreement. Any computers that do not agree will discard the offending record. While this method is good at ensuring the blockchain is tamper-proof, it is not perfect.

[0118] One way to game the system is for a malicious user to modify the list of transactions in a way that does not change the hash. This can be done through a brute force attack, in other words, by modifying the record, encrypting the result, and checking if the hash value is the same. If the hash value is not the same, try again and again until you find a matching hash. The security of blockchain is based on the idea that ordinary computers can only perform this type of brute force attack over completely impractical timescales, such as the age of the universe. Quantum computers, in contrast, are extremely fast (thousands of times faster) and therefore pose a much greater threat.

[0119] FIG. 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 uses quantum particles, such as photons, to transmit information that cannot be copied by an eavesdropper without being corrupted. In this way, senders and receivers can verify each other's identities via the blockchain.

[0120] In the example of Figure 8B, there are four users (854, 856, 858, and 860). Each pair of users can share a private key 862 (i.e., QKD) between themselves. Because 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 CDSix different private keys 862 are used, including . Each pair can create QKD by using quantum particles such as photons to transmit information that cannot be copied by an eavesdropper without being corrupted. In this way, pairs of users can verify each other's identities.

[0121] The operation of blockchain 852 is based on two steps: (i) transaction creation and (ii) the construction of blocks, which collect 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, creation time, the amount (or value) being transferred, and a list of reference transactions that justify the sender's having sufficient funds for the operation. This transaction record is then sent to all other nodes and entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from 854 to 860) authenticate the transaction by providing a shared private key 862 (QKD). This quantum signature is attached to every transaction, making it extremely difficult to tamper with. Each node checks the transaction entry against its local copy of blockchain 852 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0122] 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 may apply 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). First, the nodes send the private value to each other. Then, the nodes communicate the information they previously received from other nodes. Now, the authentic node can create the complete set of transactions in a new block. This new block can be added to the blockchain 852. In one embodiment, features and / or operations described and / or illustrated herein may occur in or with respect to the blockchain 852.

[0123] 9 illustrates an exemplary system 900 supporting one or more of the example embodiments described and / or illustrated herein. System 900 includes a computer system / server 902, which may operate in numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, 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 these systems or devices.

[0124] The computer system / server 902 may be described in the general context of computer system executable instructions, such as program modules being executed by the computer system. Typically, 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 executed 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.

[0125] 9, a computer system / server 902 within 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.

[0126] A bus may represent 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, including, by way of example only, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus.

[0127] The computer system / server 902 typically includes a variety of computer system-readable media. Such media may be any available media accessible by the computer system / server 902, including volatile and nonvolatile media, removable and non-removable media. The system memory 906, in one embodiment, implements the flow diagrams of other figures. The 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. The computer system / server 902 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 914 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such an example, each may be connected to the bus by one or more data media interfaces. As shown and described in detail below, memory 906 may include at least one program product comprising a series of (e.g., at least one) program modules configured to perform the functions of various embodiments of the present application.

[0128] For example, a program / utility 916 including a set of (at least one) program modules 918 may be stored in memory 906, including, but not limited to, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a network environment. The program modules 918 typically perform the functions and / or methods of various embodiments of the present application described herein.

[0129] 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 embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally 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.

[0130] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, one or more devices that allow a user to interact with the computer system / server 902, or any device (e.g., a network card, modem, etc.) that allows the computer system / server 902 to communicate with one or more other computing devices, or a combination thereof. Such communication may occur through an I / O interface 924. Additionally, the computer system / server 902 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, through a network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that other hardware and / or software components, not shown, may be used 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.

[0131] While at least one example embodiment of the system, method, and non-transitory computer-readable medium has been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but is susceptible to numerous rearrangements, modifications, and substitutions, as illustrated and defined by 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, with respect to various events, within or external to the modules or components. Additionally, 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, or via multiple protocols, or a combination thereof. Additionally, a message sent or received by any of the modules may be sent or received directly, via one or more of the other modules, or both.

[0132] Those skilled in the art will understand that the "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the foregoing functions performed by the "system" is in no way intended to limit the scope of this application, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in a localized or distributed fashion consistent with computing technology.

[0133] It should be noted that some of the features of the systems described herein are presented as modules to particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large-scale integration (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.

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

[0135] In practice, a module of executable code may be a single instruction, or many instructions, and may be distributed across several different code segments, among different programs, and across multiple memory devices. Similarly, operable data, identified and depicted herein within modules, may be embodied in any suitable form and organized within any suitable type of data structure. Manipulable data may be collected as a single data set or distributed across different locations, including different storage devices, and may exist, at least in part, as simple electronic signals over a system or network.

[0136] It will be readily understood that the components of the present application, as generally described and illustrated in the Figures herein, may 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 merely represents selected embodiments of the present application.

[0137] Those skilled in the art will readily appreciate that the foregoing can be practiced using steps in an order other than that disclosed, or using hardware elements other than those in the disclosed configurations, or both. 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 constructions will be apparent.

[0138] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely examples, and that the scope of the present application, along with the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.), is to be defined solely by the appended claims.

Claims

1. 1. A system including a client and one or more blockchain peers, the client comprising: generating a blockchain request including noise data, the noise data being configured in a format such that a peer that does not identify the received blockchain request including the noise data as a noise request modifies valid data stored on a blockchain ledger with the noise data; creating a tag value that identifies the blockchain request as a noise request that includes the noise data; storing the tag value in the blockchain request; Transmitting the blockchain request, wherein the transmitted blockchain request is included in a block together with a plurality of other blockchain requests and provided to the one or more blockchain peers; wherein each of the one or more blockchain peers is configured to: performing an update of the blockchain ledger based on a plurality of blockchain requests included in the given block, the update skipping the execution of blockchain requests identified as the noise requests based on the tag value included in the given block. A system configured to:

2. 2. The system of claim 1, wherein the noise data includes a false key value in the blockchain ledger, the false key value being configured in a manner such that a peer that does not identify a received blockchain request including the false key value as a noise request modifies a valid key value stored on the blockchain ledger with the false key value, and the tag value includes a value that has been obfuscated in a manner previously agreed upon by the creator of the blockchain request and the one or more blockchain peers.

3. 3. The system of claim 1, wherein the client is further configured to receive a signature and a read / write set for the noisy blockchain request from a signer peer of the blockchain, and store the signature and the read / write set in the noisy blockchain request.

4. The system comprises: an ordering node configured to order the submitted blockchain request with the plurality of other blockchain requests within the block and distribute the block to the one or more blockchain peers. The system according to any one of claims 1 to 3, further comprising:

5. the blockchain ledger includes a blockchain and a state database; The one or more blockchain peers: Adding the block to the blockchain; The system of any one of claims 1 to 4, wherein the update is performed to reflect changes made by valid blockchain requests identified as non-noise requests to the state database.

6. 6. The system of claim 1, wherein the client is configured to generate blockchain requests that are noise requests based on historical patterns of behavior of multiple clients on the blockchain ledger.

7. 2. The system of claim 1, wherein the client is further configured to obfuscate the tag value based on a private key prior to sending the blockchain request.

8. 8. The system of claim 7, wherein the private key comprises a public key of a symmetric public-private key pair, and the private key is shared by a blockchain client in a blockchain network that created a blockchain request that is a noise request, but is not shared by other blockchain clients in the blockchain network.

9. 1. An apparatus comprising: Obtaining a block containing multiple blockchain requests; Identifying the blockchain requests including the noise data as noise requests based on tag values ​​included in the blocks, which identify whether each of the plurality of blockchain requests is a noise request including noise data or a non-noise request including non-noise data, wherein the noise data is configured such that a peer that does not identify the received blockchain request including the noise data as a noise request modifies valid data stored on a blockchain ledger with the noise data; performing an update of the blockchain ledger based on the plurality of blockchain requests included in the block, the update skipping execution of blockchain requests identified as the noise requests based on the identifying; a processor configured to: An apparatus comprising:

10. 10. The apparatus of claim 9, wherein the noise data includes false key values ​​in the blockchain ledger, the false key values ​​configured in a manner such that a peer that does not identify a received blockchain request including the false key value as a noise request modifies a valid key value stored on the blockchain ledger with the false key value, and the tag value includes a value that has been obfuscated in a manner previously agreed upon by the creator of the noise blockchain request and one or more blockchain peers.

11. 11. The apparatus of claim 9 or 10, wherein the tag value comprises an obfuscated tag value that is obfuscated based on a secret key.

12. 12. The apparatus of claim 11, wherein the private key comprises a public key of a symmetric public-private key pair, and the private key is shared by a blockchain client in a blockchain network that created a blockchain request that is a noise request, but is not shared by other blockchain clients in the blockchain network.

13. A client generates a blockchain request including blockchain data, the noise data being configured in a format such that a peer that does not identify the received blockchain request including the noise data as a noise request modifies valid data stored on a blockchain ledger with the noise data; The client creates a tag value that identifies the blockchain request as a noise request that includes the noise data; the client storing the tag value in the blockchain request; The client transmits the blockchain request, wherein the transmitted blockchain request is included in a block together with a plurality of other blockchain requests and provided to one or more blockchain peers; a peer of the one or more blockchain peers performing an update of the blockchain ledger based on a plurality of blockchain requests included in the given block, the update skipping the execution of blockchain requests identified as the noise requests based on the tag value included in the given block; A method comprising:

14. 14. The method of claim 13, wherein the noise data includes false key values ​​in the blockchain ledger, the false key values ​​configured in a manner such that a peer that does not identify a received blockchain request including the false key value as a noise request changes a valid key value stored on the blockchain ledger to the false key value, and the tag value includes a value that has been obfuscated in a manner previously agreed upon by the creator of the noise blockchain request and the one or more blockchain peers.

15. The method comprises: The client receives a signature and a read / write set for the noise request from a signer peer of the blockchain; storing the signature and the read / write set in a blockchain request that is the noise request; 15. The method of claim 13 or 14, further comprising:

16. The method comprises: an ordering node ordering the submitted blockchain request with the plurality of other blockchain requests within the block and distributing the block to the one or more blockchain peers; The method of any one of claims 13 to 15, further comprising:

17. 17. The method of any one of claims 13 to 16, wherein the generating comprises generating blockchain requests that are noise requests based on historical patterns of behavior of multiple clients on the blockchain ledger.

18. 18. The method of any one of claims 13 to 17, wherein the creating further comprises obfuscating the tag value using a private key before sending the blockchain request.

19. A computer program for implementing an apparatus according to any one of claims 9 to 12.

Images