Off-chain notifications of updates from a private blockchain

Abstract

Exemplary operations can include one or more of: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; generating a notification of the changed value of the participant data; sending the notification to the non-participant system based on the link between the non-participant system and the data field.

Description

TECHNICAL FIELD

[0001] The present application relates generally to a system for storing data through a blockchain, and more particularly to a protocol for securely sharing ledger updates occurring on a private blockchain with off-chain entities that do not have read access to the private blockchain. BACKGROUND

[0002] A centralized database stores and maintains data in a single database (e.g., database server) at one location. The location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. The information stored on a centralized database is typically accessible from multiple different points. Multiple user or client workstations can work on the centralized database simultaneously, e.g., based on a client / server configuration. Centralized databases are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that there is only one primary record of a given data set.

[0003] Organizations have recently turned to blockchain as an improved storage system over traditional databases. Blockchain offers many benefits over traditional databases, including data redundancy, no central authority, multiple access nodes, etc. However, in order to read / access updates to blockchain data, a party must typically be a member of the blockchain. This is because non-participants of the blockchain should not be able to access the blockchain’s ledger. Currently, there is no mechanism to securely deliver notifications of updates from a private blockchain to non-participant systems (off-chain entities) that are not members of the private blockchain.

[0004] Accordingly, there is a need for solutions that improve and overcome these drawbacks and limitations. SUMMARY

[0005] One example embodiment provides a system comprising one or more processors and a network interface. The processors are configured to perform one or more of: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; and generating a notification of the changed value of the participant data. The network interface is configured to send the notification to the non-participant system based on the link between the non-participant system and the data field.

[0006] Another example embodiment provides a method comprising one or more of: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; generating a notification of the changed value of the participant data; and sending the notification to the non-participant system based on the link between the non-participant system and the data field.

[0007] A further example embodiment provides a non-transitory computer readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; generating a notification of the changed value of the participant data; and sending the notification to the non-participant system based on the link between the non-participant system and the data field.

[0008] Viewed from a first aspect, the present invention provides a computing system comprising: a processor and a network interface. The processor is configured to create, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detect a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; and generate a notification of the changed value of the participant data. The network interface is configured to send the notification to the non-participant system based on the link between the non-participant system and the data field.

[0009] Preferably, the present invention provides a computing system wherein the processor stores a public key of the non-participant system in an access matrix of the private blockchain along with an identifier of the data field to create the link.

[0010] Preferably, the present invention provides a computing system wherein the data field is stored within one or more of a body of a data block, a key-value store, and a world state database of the private blockchain.

[0011] Preferably, the present invention provides a computing system wherein the processor is further configured to generate a message comprising the changed value of the participant data and store the generated message within a data block of a different blockchain.

[0012] Preferably, the present invention provides a computing system wherein the processor is further configured to hash the message comprising the changed value of the participant data and control the network interface to send the hashed message to the non-participant system.

[0013] Preferably, the present application provides a computing system, wherein the processor is configured to detect a modification of a value of a data field by a participant corresponding to the participant data.

[0014] Preferably, the present application provides a computing system, wherein the processor is configured to trigger a notification entity of the private blockchain to send a notification to the non-participant system including a proof of authenticity of the modified value that is independently verifiable by the public blockchain encrypted with a public key of the non-participant system in response to detecting the modification of the value.

[0015] Preferably, the present application provides a computing system, wherein the processor generates a notification of the modified value of the participant data in response to a consensus among the blockchain nodes of the private blockchain.

[0016] Viewed from another aspect, the present application provides a method comprising: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a modification of a value of the participant data based on a read operation from the data field stored on the private blockchain; generating a notification of the modified value of the participant data; and sending the notification to the non-participant system based on the link between the non-participant system and the data field.

[0017] Preferably, the present application provides a method, wherein the creating the link comprises storing a public key of the non-participant system in an access matrix of the private blockchain along with an identifier of the data field.

[0018] Preferably, the present application provides a method, wherein the data field is stored within one or more of a body of a data block, a key-value store, and a world state database of the private blockchain.

[0019] Preferably, the present application provides a method, further comprising: generating a message including the modified value of the participant data and storing the generated message within a data block of a different blockchain.

[0020] Preferably, the present application provides a method, further comprising: hashing the message including the modified value of the participant data and sending the hashed message to the non-participant system.

[0021] Preferably, the present application provides a method, wherein the detecting comprises detecting a modification of a value of a data field by a participant corresponding to the participant data.

[0022] Preferably, the present application provides a method, further comprising: triggering a notification entity of the private blockchain to send a notification to the non-participant system including a proof of authenticity of the modified value that is independently verifiable by the public blockchain encrypted with a public key of the non-participant system in response to detecting the modification.

[0023] Preferably, the present application provides a method, wherein the generation of the notification of the changed value of the participant data is performed in response to a consensus reached between the blockchain nodes of the private blockchain.

[0024] Viewed from another aspect, the present application provides a non-transitory computer readable medium comprising instructions that, when read by a processor, cause the processor to perform a method comprising: creating, by a chaincode, a link between a non-participant system and a data field stored on a private blockchain, wherein the data field comprises participant data of the private blockchain; detecting a change in a value of the participant data based on a read operation from the data field stored on the private blockchain; generating a notification of the changed value of the participant data; and sending the notification to the non-participant system based on the link between the non-participant system and the data field.

[0025] Preferably, the present application provides a non-transitory computer readable medium, wherein the creating the link comprises storing a public key of the non-participant system in an access matrix of the private blockchain along with an identifier of the data field.

[0026] Preferably, the present application provides a non-transitory computer readable medium, wherein the data field is stored in one or more of a body of a data block, a key-value store, and a world state database of the private blockchain.

[0027] Preferably, the present application provides a non-transitory computer readable medium, wherein the method further comprises generating a message comprising the changed value of the participant data and storing the generated message in a data block of a different blockchain. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 is a schematic diagram illustrating a system for sharing updates from a private blockchain ledger with non-participant systems, in accordance with example embodiments.

[0029] Figure 2A is a schematic diagram illustrating an example blockchain architecture configuration, in accordance with example embodiments.

[0030] Figure 2B is a schematic diagram illustrating a blockchain transaction flow between nodes, in accordance with example embodiments.

[0031] Figure 3A is a schematic diagram illustrating a permissioned network, in accordance with example embodiments.

[0032] Figure 3B is a schematic diagram illustrating another permissioned network, in accordance with example embodiments.

[0033] Figure 3C is a schematic diagram illustrating an un-permissioned network, in accordance with example embodiments.

[0034] Figure 4A FIG. 1 is a schematic diagram illustrating a bootstrapping process for registering a non-participant system to updates to a data field on a private blockchain, according to example embodiments.

[0035] Figures 4B-4D FIG. 2 is a schematic diagram illustrating a process of notifying a non-participant system and sharing updates to a data field with the non-participant system, according to example embodiments.

[0036] Figure 5 FIG. 3 is a schematic diagram illustrating a method of notifying a non-participant system of updates to a private blockchain, according to example embodiments.

[0037] Figure 6A FIG. 4 is a schematic diagram illustrating an example system configured to perform one or more operations described herein, according to example embodiments.

[0038] Figure 6B FIG. 5 is a schematic diagram illustrating another example system configured to perform one or more operations described herein, according to example embodiments.

[0039] Figure 6C FIG. 6 is a schematic diagram illustrating another example system configured to utilize a smart contract, according to example embodiments.

[0040] Figure 6D FIG. 7 is a schematic diagram illustrating yet another example system configured to utilize a blockchain, according to example embodiments.

[0041] Figure 7A FIG. 8 is a schematic diagram illustrating a process of adding a new block to a distributed ledger, according to example embodiments.

[0042] Figure 7B FIG. 9 is a schematic diagram illustrating data content of a new block of data, according to example embodiments.

[0043] Figure 7C FIG. 10 is a schematic diagram illustrating a blockchain for digital content, according to example embodiments.

[0044] Figure 7D FIG. 11 is a schematic diagram illustrating a block that can represent the structure of a block in a blockchain, according to example embodiments.

[0045] Figure 8A FIG. 12 is a schematic diagram illustrating an example blockchain storing machine learning (artificial intelligence) data, according to example embodiments.

[0046] Figure 8B FIG. 13 is a diagram illustrating an example quantum secure module blockchain, according to example embodiments.

[0047] Figure 9 is a diagram illustrating an example system that supports one or more example embodiments. DETAILED DESCRIPTION

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

[0049] In one or more embodiments, the features, structures, or characteristics of the application described throughout this specification, in any suitable manner, can be combined or removed. For example, the phrase "exemplary embodiment", "some embodiments", or other similar language as used throughout this specification does not necessarily refer to the same set of embodiments, but can refer to "one or more embodiments" that include at least the featured, structure, or characteristic described in conjunction with that embodiment. Thus, use of the phrases "exemplary embodiment", "in some embodiments", "in other embodiments", or other similar language, as appearing throughout this specification, are not necessarily all referring to the same embodiment, and can, in one or more embodiments, refer to different embodiments. Further, any connections between elements in the diagrams can allow for one-way and / or two-way communication, even if the connections are shown as a one-way or two-way arrow. Also, any of the apparatuses shown in the diagrams can be different apparatuses. For example, if a mobile device is shown sending information, a wired device can also send the information.

[0050] Further, although the term "message" can be used in the description of embodiments, the present application can apply to many types of networks and data. Further, although a particular type of connection, message, and signaling can be described in example embodiments, the present application is not limited to a particular type of connection, message, and signaling.

[0051] The example embodiments provide a method, system, component, non-transitory computer readable medium, device, and / or network that provides an out-of-chain non-participant system with a notification of an update to a blockchain ledger data.

[0052] In one embodiment, the system is deployed and configured as a decentralized database, such as a blockchain, as a distributed storage system that includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure similar to a distributed ledger that is capable of maintaining records among mutually untrusted parties. The mutually untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without consensus among the distributed peers. For example, the peers can execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain on the blocks. For consistency, the process forms a ledger by ordering the storage transactions as needed. In various embodiments, permissioned blockchains and / or permissionless blockchains can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. The public blockchain can involve native cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). On the other hand, a permissioned blockchain database provides secure interactions, such as exchanging funds, goods, information, and the like, among a group of entities that share a common goal but are not fully mutually trusted.

[0053] The blockchain can operate as arbitrary, programmable logic tailored to the decentralized storage scheme, which is referred to as a“smart contract” or“chaincode.” In some cases, there can be specialized chaincode, referred to as system chaincode, that is used to manage functions and parameters. The present application can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof nature of the blockchain database and the underlying protocols among the nodes referred to as endorsement or endorsement policy. Blockchain transactions associated with the present application can be“endorsed” before being submitted to the blockchain, and transactions that are not endorsed are ignored. The endorsement policy allows the chaincode to specify endorsers in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters an ordering phase, in which a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0054] A blockchain can include nodes configured therein are communication entities of the blockchain system. A "node" can perform logical functions in the sense that different types of nodes can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submit-client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive client-submitted transactions, submit the transactions, and maintain a state and copy of a ledger of blockchain transactions. A peer can also play the role of an endorser, although this is not a requirement. Ordering service nodes or orderers are nodes that run a communication service for all nodes, which implement delivery guarantees, such as broadcasting to every peer node in the system when a transaction is submitted and the world state of the blockchain is modified, which is another name for the initial blockchain transaction, which typically includes control and setup information.

[0055] A blockchain can include a ledger, which is a sorted, tamper-resistant record of all state transitions of the blockchain. State transitions can be caused by chaincode calls (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant, such as a peer node, can maintain a copy of the ledger. A transaction can cause a set of asset key-value pairs to be submitted to the ledger as one or more operations such as create, update, delete. The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0056] A chain (of the blockchain) is a transaction log structured as a hash-linked block, and each block contains a sequence of N transactions, where N is equal to or greater than 1. A block header includes a hash of the transactions of that block and a hash of the header of the previous block. In this way, all transactions on the ledger can be sorted and cryptographically linked together. As such, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that has occurred on the chain before it, thus enabling all peer nodes to be in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of the blockchain workload.

[0057] The current state of the immutable ledger represents the latest values of all keys included in the chain transaction log. Since the current state represents the latest key values known by the channel, it is sometimes referred to as the world state. Chain invocations execute transactions against the current state data of the ledger. For these chain interactions to be effective, the latest values of the keys can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated, if needed) before the peer starts and transactions are accepted.

[0058] It is often the case that entities other than the asset holder have an interest in the asset. For example, when someone purchases a house, a bank or other institution often retains a lien on the property while the person is repaying the loan to the bank. When the homeowner stores their asset information on a private land registry network hosted by a blockchain, the homeowner can access the blockchain data because the homeowner is a member; but the lender, which also has an interest in the asset, cannot access it because they are not a member of the blockchain. In this case, if the homeowner sells the asset through the land registry blockchain and records this change, then the lender will not know about this change because they cannot access the blockchain and therefore cannot detect or read the change that has occurred.

[0059] Exemplary embodiments overcome the limited notification capabilities of a blockchain by extending or otherwise sharing private blockchain data with non-member or non-participant entities. The system can link or otherwise associate a non-participant's system to a data value on the distributed ledger. In the above example, the data value (e.g., a house, etc.) can be controlled by the homeowner and can represent a value in which both the homeowner and the bank have an interest, in this case the bank is a non-participant entity. The link can be performed by storing an identifier of the non-participant entity with an identifier of the data field in a data matrix that can be used to determine access rights to the blockchain data. In some embodiments, the link can be created by storing a public key of the non-participant with an identifier of the data field in the matrix.

[0060] When the homeowner later updates the data values, e.g., by selling the asset, making a change, paying a tax bill, etc., the blockchain system can identify that an update has occurred and forward the update (in encrypted form) to the non-participant system. At the same time, the exchange between the notifier and the non-participant system of the private blockchain can be performed using a public blockchain to compensate the notifier with a payment from the non-participant system receiving the data. For example, the public blockchain can ensure that the notifier complies with its transaction end date and provides truthful information in the notification. As described herein, the notification (1) is sent in a confidential manner to the non-private blockchain recipient, e.g., by being encrypted using the recipient's public key, and (2) carries with it a verifiable guarantee that the data it contains was indeed stored on the private blockchain, e.g., a digital signature of a peer of the private blockchain.

[0061] The information comes with a verifiable guarantee of its provenance on the private blockchain. Without such a verifiable guarantee, the notifier can maliciously or negligently provide incorrect information. If the notifier provides incorrect information, the notifier will eventually lose the escrowed funds it provided earlier. In addition, the public blockchain can ensure that the non-participant system receiving the data has completed the transaction and provided sufficient compensation. In this case, the notifier releases the symmetric key to the public blockchain in order to decrypt the doubly encrypted data field to the non-participant system. The public blockchain can verify that the released symmetric key decrypts the message M2 to yield M2 and that M1 was generated by encrypting some message using the public key of the non-participant system. Here, the public blockchain can employ zero-knowledge proofs. Releasing a non-truthful symmetric key or a non-truthful data field will result in the notifier losing the funds it committed to it on the public blockchain. In addition, the non-participant system can release a digital signature to the public blockchain confirming receipt of the symmetric key after the notifier releases the symmetric key and the public blockchain verifies the symmetric key. If a non-truthful signature is not released, the non-participant system will lose the funds it committed to it on the public blockchain commensurate with the funds the notifier will lose if it releases a non-truthful symmetric key.

[0062] Thus, private blockchain data can be shared in a targeted manner to external off-chain parties. Conventional blockchain systems make it infeasible (privacy-invasive) to add external parties to the blockchain without the consent of the members. The example embodiments introduce the role of a notifier into the private blockchain. In some embodiments, the notifier can be a new system or an existing peer within the blockchain network. Each of the notifier and the recipient (non-participant system) of the notification can forward a bond of funds or assets to a public blockchain, where it is stored and held by one or more smart contracts. When the parties fail to perform their duties, the money held by the smart contract is released as a penalty to the other party.

[0063] The protocol described in the example embodiments can exchange private blockchain data with external participants on a public blockchain in an atomic manner for a reward without revealing data to other non-participant systems. Using this protocol, a method for unilaterally (one-way) linking data / assets from a private blockchain to an external entity (which can be a member of a different private blockchain) can be implemented without requiring both networks to have a common member (peer or client).

[0064] The protocol described herein produces a functional improvement over traditional blockchains by enabling trustless (i.e., no need to trust an individual party) notification from a private blockchain in a way that maintains the confidentiality of data from parties that should not be informed. The system improves the security and privacy of data sharing from a private blockchain to external parties. The protocol can also be considered to enhance traditional blockchain access control methods, as the decision to reveal data requires consensus among participants of the private blockchain.

[0065] Some benefits of the system herein include that when member data is updated, a notification service can use a public blockchain to exchange this information with off-chain users for some reward. Further, in addition to guaranteeing that updates are reliably delivered to off-chain users, the system also reliably shares the reward with the notifier and provides off-chain non-participant users with the non-repudiation of receiving data from private blockchain members. Additionally, a private blockchain does not need to have a notification service from the start, as the service can be formed by incentivizing existing peers to notify external parties through the protocol.

[0066] Figure 1 A system for sharing updates from a private blockchain ledger with non-participant systems according to example embodiments is shown. Referring to Figure 1 , the system 100 includes a private network, which in this example includes a private blockchain 110, participants 111 (or members of the private blockchain 110), and a notification system 112 (notifier). It should also be appreciated that the private network can include many participants 111 and multiple notifiers 112, but only one of each is shown for convenience. The system 100 further includes a non-participant 122 and a public blockchain 120. In this example, the notifier 112 has established one-way sharing of updates to private data of the participants 111 stored on the blockchain 110 with the non-participant recipient 122.

[0067] In this example, the private blockchain 110 includes participants 111 that are members with read and write permissions to the distributed ledger of the private blockchain 110. The private network also includes a notifier 112 that is a member of the private blockchain 110 and has at least read permissions to the private blockchain 110. Meanwhile, a non-participant system 122 is not a member of the private blockchain 110 and thus does not have trusted read or write access to the ledger, but is interested in updates to a particular field in the ledger of the private blockchain 110. For example, the particular field can store data of the participants 111, such as house purchase information in the example where the participants 111 are homeowners, and the non-participant system is a system of a lender that has a lien on the house.

[0068] In this example, the public blockchain 120 can be used to store a hash of an encrypted version of the update data field when provided by the notifier 112. Here, the data field can be encrypted with a public key of the non-participant system 122. Further, a message Ml that includes the encrypted data field can be generated by a smart contract of the private blockchain 110 based on consensus among peers and recorded on the ledger of the blockchain. Additionally, the notifier 112 can encrypt the Ml with a symmetric key that only the notifier 112 knows, send the hashed version of Ml to the non-participant system 122, and also record the hashed version of Ml on the public blockchain 120. Here, the non-participant system 122 cannot access the encrypted Ml because it does not have the symmetric key.

[0069] Further, the public blockchain 120 can have a smart contract executed therein that verifies that both the notifier 112 and the non-participant system 122 fulfill their obligations under the notification protocol. In this example, the public blockchain 120 can give the non-participant system 122 an opportunity to prove that the data field (decrypted from Ml) is not authentic. If the field is indeed authentic, then funds are released to the notifier 112 after an expiration time. Prior to this, there can be a separate exchange mediated by the public blockchain 120 that includes a symmetric key for a receipt signature. If the signed receipt is not provided after the symmetric key is released, then the non-participant system 122 loses the funds. Both the notifier 112 and the non-participant system 122 pre-commit an equal amount of funds. If either party does not fulfill their obligations, then no funds are transferred on the public blockchain.

[0070] If both parties fulfill their obligations, each will gain and lose equal amounts of funds, resulting in a net zero profit and loss expectation. If either party fails to fulfill their obligations (or forgets to record), the public blockchain 120 will prevent the release of the promissory funds provided to them upfront. For example, if the notifier 112 releases the true symmetric key, it gains funds at the expense of the non-participant system 122, but if the non-participant system 122 does not release the digital signature through the hash of the message Ml, it does not gain any funds. The result is a net gain for 112 for its compliance, but a net loss for 122 for its non-compliance. In this case, the public blockchain 120 is accessible to the participant 111, the notifier 112, and the non-participant 122. Each of these entities can have an account on the public blockchain 120. While not shown in Figure 1 , a smart contract can be executed on the public blockchain 120 that can host funds and release them if conditions are met and triggered by inputs that can be signatures, hashes, etc.

[0071] Figure 2A A blockchain architecture configuration 200 according to an example embodiment is shown. Referring to Figure 2A , the blockchain architecture 200 can include certain blockchain elements, for example, a set of blockchain nodes 202. The blockchain nodes 202 can include one or more nodes 204-210 (these four nodes are shown by way of example only). These nodes participate in many activities, such as blockchain transaction addition and confirmation processes (consensus). One or more of the blockchain nodes 204-210 can endorse transactions based on an endorsement policy, and can provide ordering services for all blockchain nodes in the architecture 200. The blockchain nodes can initiate blockchain authentication and attempt to write to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which can also be stored on an underlying physical infrastructure 214. The blockchain configuration can include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to a custom configuration sought by a participant and can maintain its own state, control its own assets, and receive external information. This can be deployed as a transaction and installed on all blockchain nodes 204-210 by appending to the distributed ledger.

[0072] The blockchain foundation or platform 212 can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure for receiving and storing new transactions and providing access to auditors seeking to access data entries. The blockchain layer 216 can expose an interface providing access to program code and virtual execution environments necessary to participate in the physical infrastructure 214. Cryptographic trust services 218 can be used to validate transactions, such as asset exchange transactions, and keep information private.

[0073] Figure 2A The blockchain architecture configuration of FIG. 2 can handle and execute program / application code 220 through one or more interfaces exposed by the blockchain platform 212 and services provided. The code 220 can control blockchain assets. For example, the code 220 can store and transfer data, can be executed by the nodes 204-210 in the form of a smart contract and associated chain code having conditions or other code elements affected by its execution. As a non-limiting example, a smart contract can be created to perform reminders, updates, and / or other notifications affected by changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and usage of the ledger. For example, the read set 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The write set 228 can include results of processing the read set 226 by one or more smart contracts. The physical infrastructure 214 can be used to retrieve any data or information described herein.

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

[0075] A smart contract can write data to the blockchain in the format of key-value pairs. Additionally, the smart contract code can read values stored in the blockchain and use them in application operations. The smart contract code can write outputs of different logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by a smart contract is saved in memory by the provided execution environment and then deleted once the data needed by the blockchain is identified.

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

[0077] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Referring to Figure 2B , the transaction flow can include a transaction proposal 291 sent by an application client node 260 to endorsing peer nodes 281. The endorsing peers 281 can validate the client signature and execute a chaincode function to initiate the transaction. The output can include a chaincode result, a set of key / value versions read in the chaincode (read set), and a set of keys / values written in the chaincode (write set). If approved, a proposal response 292 is sent back to the client 260 along with the endorsement signatures. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to the ordering service nodes 284. The ordering service nodes 284 then deliver the ordered transactions as blocks to all peers 281-283 on the channel. Each peer 281-283 can validate the transaction before committing to the blockchain. For example, the peers can check the endorsement policy to ensure the correct allocation of specified peers have signed the result and verify the signatures against the transaction payload 293.

[0078] Referring again to Figure 2B , the client node 260 initiates a transaction 291 by building a request and sending the request to the peer nodes 281 as endorsers. The client 260 can include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal. The proposal is a request that invokes a chaincode function so that data can be read and / or written to the ledger (i.e., write new asset key-value pairs). The SDK can act as a shim to package the transaction proposal into the appropriate architectural format (e.g., protocol buffers over remote procedure calls (RPC)) and employ the client’s cryptographic credentials to produce a unique signature of the transaction proposal.

[0079] In response, the endorsing peer 281 can verify that (a) the transaction proposal is well-formed, (b) the transaction has not been submitted in the past (protection against replay attacks), (c) the signature is valid, and (d) the submitter (in this example, the client 260) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 can input the transaction proposal as an argument to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no update to the ledger is made at this time. At 292, the value set is passed back to the SDK of the client 260 as the proposal response 292 along with the signature of the endorsing peer 281, which the SDK parses for the application to consume.

[0080] In response, the application of the client 260 checks / verifies the endorsing peer signature and compares the proposal response to determine if the proposal response is the same. If the chaincode only queried the ledger, the application will check the query response and will typically not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all the peer nodes required for the transaction have endorsed the transaction) before submission. Here, the client can only include one of the multiple parties to the transaction. In this case, each client can have its own endorsing node, and each endorsing node will need to endorse the transaction. This architecture makes the endorsement policy enforced by the peers and upheld at the commit validation stage, even if an application chooses not to check the response or otherwise forward an unendorsed transaction.

[0081] After successful checking, at step 293, the client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to the ordering node 284. The transaction can contain the read / write sets, the endorsing peer signatures, and the channel ID. The ordering node 284 does not need to check the full contents of the transaction in order to perform its operations, rather, the ordering node 284 can simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions per channel.

[0082] The block of transactions is delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure that any endorsement policy is satisfied and that the ledger state of the read set variable has not changed since the read set was generated from the transaction execution. The transactions in the block are marked as valid or invalid. Further, at step 295, each peer node 281-283 appends the block to the chain of the channel and the write set of each valid transaction is committed to the current state database. An event is emitted to notify the client application that the transaction (invocation) has been irrevocably appended to the chain and whether the transaction was validated or invalidated.

[0083] Figure 3A An example of a permissioned blockchain network 300 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a deployment, invocation, or query, and can be published by a client-side application leveraging an SDK, directly through an API, etc. The network can provide access to a regulator 306, such as an auditor. A blockchain network operator 308 manages membership rights, such as enrolling the regulator 306 as an “auditor” and the blockchain user 302 as a “client.” The auditor can be limited to querying the ledger, while the client can be authorized to deploy, invoke, and query certain types of chaincode.

[0084] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy chaincode directly to the network through an interface. To include credentials from a legacy data source 312 in the chaincode, the developer 310 can use an out-of-band connection to access the data. In this example, the blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before making any transactions, the peer node 314 retrieves the user’s enrollment and transaction certificates from a certificate authority 316 that manages user roles and permissions. In some cases, the blockchain user must possess these digital certificates to transact on the permissioned blockchain 304. Meanwhile, a user attempting to leverage chaincode can need to validate their credentials on a legacy data source 312. To confirm the user’s authorization, the chaincode can use an out-of-band connection to that data through a legacy processing platform 318.

[0085] Figure 3BAnother example of a permissioned blockchain network 320 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, blockchain users 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be published through a client-side application that leverages an SDK, directly through an API, and the like. The network can provide access to regulators 326, such as auditors. Blockchain network operators 328 manage membership rights, such as enrolling regulators 326 as "auditors" and enrolling blockchain users 322 as "clients." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0086] Blockchain developers 330 write chaincode and client-side applications. Blockchain developers 330 can deploy chaincode directly to the network through an interface. To include credentials from traditional data sources 332 in chaincode, developers 330 can use an out-of-band connection to access the data. In this example, blockchain users 322 connect to the network through a peer node 334. Before making any transactions, peer nodes 334 retrieve the user's enrollment and transaction certificates from a certificate authority 336. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain 324. At the same time, users attempting to leverage chaincode can need to validate their credentials on traditional data sources 332. To confirm the user's authorization, chaincode can use an out-of-band connection to that data through a traditional processing platform 338.

[0087] In some embodiments, the blockchain herein can be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting a transaction, thereby adding an entry to the ledger. Furthermore, all parties can choose to run a node on the system and employ a mining protocol to help validate transactions.

[0088] Figure 3CA process 350 of a transaction being processed by a permissionless blockchain 352 comprising a plurality of nodes 354 is shown. A sender 356 wishes to send a payment or some other form of value (e.g., a contract, a medical record, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient 358 through the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the recipient device 358 can have a digital wallet (associated with the blockchain 352) that provides a display of user interface controls and transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes validate 360 the transaction based on rules established by the creator of the permissionless blockchain 352, which can be predefined or dynamically assigned. This can include, for example, verifying the identity of the parties involved, etc. The transaction can be validated immediately, or it can be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on the network ruleset.

[0089] In a structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process can be performed by mining nodes among the nodes 354. The mining nodes can utilize additional software that is dedicated to mining and creating blocks for the permissionless blockchain 352. Each block can be identified by a hash (e.g., 256 bits, etc.) that is created using an algorithm agreed upon by the network. Each block can include a header, a pointer or reference to a hash of the header of the previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure chain of blocks.

[0090] Before a block can be added to the blockchain, the block must be validated. Validation for a permissionless blockchain 352 can include proof of work (PoW), which is a solution to a puzzle derived from the header of the block. While not shown in the example of Figure 3C Another process of validating a block is proof of stake. Unlike proof of work, where miners are rewarded with an algorithm for solving a mathematical problem, with proof of stake, the creator of a new block is selected in a determined way according to their wealth, also defined as “stake.” A similar proof is then performed by the selected node.

[0091] Through mining 364, a node attempts to solve a block by making incremental changes to one variable until the solution satisfies a network-wide goal. This creates a PoW, which ensures the correct answer. In other words, the potential solution must prove that computing resources were exhausted in solving the problem. In some types of permissionless blockchains, a miner is rewarded with a value (e.g., coin, etc.) for correctly mining a block.

[0092] Here, the PoW process along with the chain of blocks makes it extremely difficult to modify the blockchain because an attacker would have to modify all subsequent blocks for a modification to one block to be accepted. Moreover, as new blocks are mined, the difficulty of modifying a block increases, as does the number of subsequent blocks. Through distribution 366, the successfully validated block is distributed through the permissionless blockchain 352, and all nodes 354 add the block to the majority chain that is the auditable ledger of the permissionless blockchain 352. Moreover, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0093] Figure 4A A bootstrapping procedure 400A for registering a non-participant system (recipient 122) for updates to a data field of a participant 111 on a private blockchain 110 is shown in accordance with example embodiments. Reference is made to Figure 4A In 401, the recipient 122 shares its public key with the notifiers 112 and the participant 111 along with one or more data values stored on the private blockchain 110 and for which the recipient 122 desires to receive updates. In 402, the notifiers 112 request an association between the one or more fields of participant 111 data. In 403, a bootstrapping smart contract is executed on the private blockchain 110 and creates a link between the data field stored on the ledger of the private blockchain 110 and the identifier of the recipient 122. In this example, the link can be created by storing the identifier of the field and the identifier of the recipient 122 (e.g., public key, etc.) in a matrix used to access the private blockchain 110.

[0094] In this example, the link sets the recipient 122 as the designated party that should receive notifications when any updates are made to the particular field in the private blockchain. For example, the public key of the recipient 122 is associated with the field of the private blockchain in which the recipient 122 is interested. In 404, the recipient 122 provides a payment for the notification to the public blockchain 120, which is held until the duty of the notifier 112 has been performed. This payment is held by a payment smart contract executed on the public blockchain 120 in 405. When the notifier 112 shares the notification of the update with the recipient 122 based on the agreement, the payment will be used to provide an incentive to the notifier 112.

[0095] Figures 4B-4D A process 400B-400D of sharing the ledger update with the recipient 122 and providing an incentive to the notifier 112 is shown. Reference is made to Figure 4BAt 411, the data field is updated or otherwise updated. Here, the participant 111 can perform the update by changing the value, such as by sale, encumbrance, tax, etc. At 412, the bootstrap smart contract executing on the private blockchain 110 can encrypt the updated field using the public key of the recipient 122 to generate a message Ml. Further, at 413, the notifϊer 112 can read the encrypted message Ml generated by the private blockchain 110 and encrypt the message Ml with a symmetric key known only to the notifier 112. At 414, the notifier 112 can record the hashed message Ml on the public blockchain 120, and then at 415, the notifier 112 can create a message M2 by encrypting the message Ml using the symmetric key and send the message M2 to the recipient 122.

[0096] Referring to Figure 4C In the process 400C, the protocol handles the exchange of updated data for delivery of proof. At 421, the notifier 112 provides a promissory note to the public blockchain 120. Likewise, at 422, the recipient 122 provides a corresponding promissory note amount (same amount) to the public blockchain 120. If both parties fulfill their obligations, the monetary amounts cancel each other out and are voided. In some embodiments, the smart contracts SC-N-Key and SC-R-Sig can be executed on the public blockchain 120 and can be designed as a coupled contract, where each party commits to exchange money for information provided to the same contract in the future to ensure proper execution of the protocol. The coupled contract can ensure that if each party submits the required information for the contract, each party will receive the pledged money back, otherwise, the money is given to the other party as a penalty for not following the rules. In some cases, a timeout can be used to ensure that both parties have sufficient time to submit their inputs to the smart contract and receive the committed amount back in case the other party does not cooperate.

[0097] At 423, the notifier 112 provides the symmetric key (SC-N-key) to the public blockchain, and at 424, the public blockchain 120 can verify that the symmetric key decrypts the message M2 (hash of Ml) previously provided by the notifier 112. Because the public blockchain 120 is public, the symmetric key becomes public knowledge at step 423. Further, the public blockchain 120 can verify that Ml is also encrypted using the public key of the recipient 122 based on a zero-knowledge proof performed by SC-N-key. At 425, the recipient 122 provides a signed hash of Ml to SC-R-sig as proof of receipt, which SC-R-sig can verify at 426.

[0098] Referring now to Figure 4DIn 431, the notifier 112 provides the signature of the receiver 122's M2 (SC-Payment) to the public blockchain 120. In 432, the receiver 122 decrypts the message M2 using the symmetric key and decrypts the encrypted update stored in the message using the receiver's private key to reveal the original update value. Here, the receiver 122 can provide the decrypted update value to the public blockchain 120 in 433. This does not occur in all cases. For example, when the receiver 122 checks the decrypted value and finds it to be untruthful information, a submission can be performed. The receiver 122 can then submit this information to the public blockchain 120 to prove its untruthfulness, thereby preventing the notifier 112 from obtaining the payment. As another example, by default, the receiver 122 can simply decrypt Ml, obtain the useful information, and can clear the payment to the notifier 112 on the public blockchain 120 after the expiration time (since no challenge was made). In 434, which is an exceptional case, the public blockchain 120 verifies that the decryption was successful and checks the truthfulness of the decrypted value provided by the additional endorsement from the private blockchain participant. If the decrypted value is untruthful, no payment is released. In 435, which is the default case, the public blockchain 120 verifies that no challenge was received, and in 436, the public blockchain 120 releases the incentive to the notifier 112.

[0099] Figure 5 A method 500 of notifying a non-participant system of updates to a private blockchain is shown in accordance with example embodiments. Reference is made to FIG. 1 for purposes of explanation. Figure 5 In 510, the method can include creating, by a chaincode, a link between the non-participant system and a data field stored on the private blockchain, where the data field includes participant data of the private blockchain. The link or association can include storing a combination of an identifier of the non-participant system and an identifier of the data field in a matrix or other file accessible on the blockchain. The identifier of the non-participant system can include a public key, a device ID, user information, etc. A smart contract implemented on the private blockchain can direct the identifier of the non-participant system to the blockchain such that every update to the data field triggers a notification to the non-participant system. The data field can refer to a data field in one or more of a body of a data block stored on the private blockchain, a key-value store of the distributed ledger, and a world state database of the distributed ledger.

[0100] In 520, the method can include detecting a change in a value of the participant data stored in the linked data field based on a read operation from the data field stored on the private blockchain. Here, a smart contract or other service can detect an update to the data field and the created link / association to the non-participant system and trigger a consensus on the private blockchain to send to the non-participant system.

[0101] At 530, the method can include generating a notification of the changed value of the participant data. For example, the notification can be generated in response to a consensus of peer nodes or endorser nodes on the private blockchain that approved the notification for sending to the non-participant system. This consensus decision can be based on predefined rules rather than depending on the whim of different peer nodes. For example, an endorser node can approve / endorse the notification if a link between the non-participant system and the data field is found, etc.

[0102] At 540, the method can include sending the notification to the non-participant system based on the link between the non-participant system and the data field. In some embodiments, the notification can include the updated value encrypted with a public key that has a private counterpart known only to the non-participant system. Prior to the notification, a hash of the encrypted value generated with a one-way cryptographic hash algorithm can be released, as well as the encrypted value further encrypted with a symmetric key known to the notifier but not to the non-participant system. Here, the key used to perform the encryption can be the public key of the non-participant system, enabling the non-participant system to securely decrypt the updated value using its own private key. In some embodiments, the notification can also include a related proof of authenticity of the data field that can be independently verified by a third party (i.e., the public blockchain).

[0103] In some embodiments, the method can further include generating a message including the changed value of the participant data (which can be encrypted with the key of the non-participant system) and storing the generated message in a data block of a different blockchain.

[0104] In some embodiments, the detecting can include detecting a modification of the value of the data field by the participant corresponding to the participant data. In some embodiments, in response to detecting the modification, the method can further include triggering a notification entity of the private blockchain to send a notification to the non-participant system. In some embodiments, in response to a consensus reached among the blockchain nodes of the private blockchain, the generation of the notification of the changed value of the participant data is performed.

[0105] Figure 6A An example system 600 including physical infrastructure 610 configured to perform various operations in accordance with example embodiments is shown. Reference is made to Figure 6AThe physical infrastructure 610 includes modules 612 and modules 614. The modules 614 include a blockchain 620 and smart contracts 630 (which can reside on the blockchain 620) that can perform any of the operational steps 608 (in the modules 612) included in any of the example embodiments. The steps / operations 608 can include one or more of the described or illustrated embodiments and can represent output or write information written to or read from one or more of the smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, modules 612, and modules 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the modules 612 and modules 614 can be the same module.

[0106] Figure 6B Another example system 640 configured to perform various operations in accordance with example embodiments is shown. Referring to Figure 6B The system 640 includes modules 612 and modules 614. The modules 614 include a blockchain 620 and smart contracts 630 (which can reside on the blockchain 620) that can perform any of the operational steps 608 (in the modules 612) included in any of the example embodiments. The steps / operations 608 can include one or more of the described or illustrated embodiments and can represent output or write information written to or read from one or more of the smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, modules 612, and modules 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the modules 612 and modules 614 can be the same module.

[0107] Figure 6C An example system configured to utilize smart contracts between contracting parties and an intermediary server configured to enforce smart contract terms on a blockchain in accordance with example embodiments is shown. Referring to Figure 6C The configuration 650 can represent a communication session, asset transfer session or process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and execution results of the smart contract can be managed by a server 654. The content of the smart contract 630 can require a digital signature of one or more of the entities 652 and 656 that are parties to the smart contract transaction. The smart contract execution results can be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620 which in turn can reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0108] Figure 6D A system 660 including a blockchain in accordance with example embodiments is shown. Referring to Figure 6DIn this example, the API gateway 662 is a public interface for performing transactions (invocations, queries, etc.) on a blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, the server 654 is a blockchain network peer component that holds a copy of the world state and a distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions into the blockchain network, where the endorsing peers will run the smart contract 630 according to the smart contract 630 and endorsement policy.

[0109] The above embodiments can be implemented in hardware, computer program executed by a processor, firmware, or a combination thereof. The computer program can be embodied on a computer readable medium, such as a storage medium. For example, the computer program can reside in Random Access Memory ("RAM"), flash memory, Read Only Memory ("ROM"), Erasable Programmable Read Only Memory ("EPROM"), Electrically Erasable Programmable Read Only Memory ("EEPROM"), registers, hard disk, a removable disk, a compact disk read only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0110] The exemplary storage medium can 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 can be integral to the processor. The processor and the storage medium can reside in an Application-Specific Integrated Circuit ("ASIC"). In the alternative, the processor and the storage medium can reside as discrete components.

[0111] Figure 7A A process 700 of adding a new block to a distributed ledger 720 according to an exemplary embodiment is shown, Figure 7B The contents of a new data block structure 730 of a blockchain according to an exemplary embodiment are shown. Reference is made to Figure 7AA client (not shown) can submit transactions to blockchain nodes 711, 712, and / or 713. The client can be an application that receives instructions from any source to formulate activity on the blockchain 720. As an example, the client can be an application that proposes transactions to the blockchain on behalf of a requestor, such as a device, person, or entity. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) can maintain the state of the blockchain network and a copy of the distributed ledger 720. There can be different types of blockchain nodes / peers in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients and committing peers that validate endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 can act as an endorsing node, a committing node, or both.

[0112] The distributed ledger 720 includes a blockchain that stores immutable, ordered records in blocks and a state database 724 that maintains the current state of the blockchain 722 (the current world state). There can be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which it is a member. The blockchain 722 is a transaction log, structured as a hash-linked chain of blocks, where each block contains a sequence of N transactions. Blocks can include various components, such as shown in Figure 7B The linking of blocks (shown by the arrows in Figure 7A ) can be generated by adding the hash of the previous block’s header within 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 link. Moreover, because of the linking, the latest block in the blockchain 722 represents every transaction that occurred before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage) that supports only append blockchain workloads.

[0113] The current state of the blockchain 722 and the distributed ledger 722 can be stored in the state database 724. Here, the current state data represents the latest values of all keys that were 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 extremely efficient, the latest values of all keys are stored in the state database 724. The state database 724 can include an indexed view of the transaction log of the blockchain 722, so it can be regenerated from the chain at any time. The state database 724 can be automatically restored (or generated if needed) at peer startup, before transactions are accepted.

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

[0115] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers the blocks to committing peers. For example, the ordering service 710 can initiate a new block when a transaction threshold has been reached, a timer has timed out, or another condition. The ordering service 710 can be implemented as a stateless service that receives transactions, orders them, and delivers them to the committing peers. Figure 7A In the example, the blockchain node 712 is a committing peer that has received a new block of data 730 to be stored on the blockchain 720. The first block in a blockchain can be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

[0116] The ordering service 710 can be composed of an orderer cluster. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 can accept endorsed transactions and specify the order in which these are committed to the distributed ledger 720. The specific implementation of 'ordering' (e.g., Solo, Kafka, BFT, etc.) can be made a pluggable component in the architectural design of the blockchain network.

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

[0118] When the sorting service 710 initializes a new data block 730, it can broadcast the new data block 730 to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer verifies the transactions within 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. Specifically, the commit peer can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 724. When the commit peer verifies the transaction, the transaction is written to blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If the transaction fails, i.e., if the commit peer finds that the read-write set does not match the current world state in the state database 724, the transaction sorted into the block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0119] refer to Figure 7B A new data block 730 (also called a data block) stored on blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that the various blocks and their contents shown, such as... Figure 7B The new data block 730 and its contents shown are merely examples and are not intended to limit the scope of the exemplary embodiments. The new data block 730 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 750. The new data block 730 may also include a pointer to the previous block within block header 740 (e.g., ...). Figure 7A The link is on blockchain 722. Specifically, block header 740 may contain the hash of the header of the previous block. Block header 740 may also include a unique block number, the hash of block data 750 of the new data block 730, etc. The block number of the new data block 730 may be unique and assigned in various orders, such as starting from zero in an ascending / continuous order.

[0120] Block data 750 can store transaction information for each transaction recorded within the new block 730. For example, the transaction data can include one or more of the following: a type of transaction, a version, a timestamp, a channel ID of the distributed ledger 720, a transaction ID, an epoch, a payload visibility, a chaincode path (for a deployment transaction), a chaincode name, a chaincode version, inputs (chaincode and functions), a client (creator) identity (such as a public key and a certificate), a client's signature, an endorser identity, an endorser signature, a proposal hash, a chaincode event, a response status, a namespace, a read set (a list of keys and versions read by the transaction, etc.), a write set (a list of keys and values, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, etc. The transaction data can be stored for each of the N transactions.

[0121] Block metadata 760 can store a plurality of fields of metadata (e.g., as a byte array, etc.). The metadata fields can include a signature on block creation, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, a last offset of a sequencing service that sequenced the block, etc. The signature, last configuration block, and sequencer metadata can be added by the sequencing service 710. Meanwhile, a submitter of the block (such as a blockchain node 712) can add the valid / invalid information based on endorsement policies, validation of read / write sets, etc. The transaction filter can include a byte array of a size equal to the number of transactions in the block data 750 and validation codes identifying whether the transactions are valid / invalid.

[0122] Figure 7C An embodiment of a blockchain 770 of digital content according to embodiments described herein is shown. The digital content can include one or more files and associated information. The files can contain media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of the blockchain is a safeguard to the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings subject to rules of admissibility, or other environments where evidence is considered, or other environments where the presentation and use of digital information is of interest. In this case, the digital content can be referred to as digital evidence.

[0123] The blockchain can be formed in various ways. In one embodiment, the digital content can be included in and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., a header, a value, etc.) along with the associated digital content. The hash value and associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be illustrated as follows:

[0124] Block 1 Block 2... Block N

[0125] Hash Value 1 Hash Value 2 Hash Value N

[0126] Digital Content 1 Digital Content 2 Digital Content N

[0127] In one embodiment, the digital content can not be included in the blockchain. For example, the blockchain can store the encrypted hash of the content of each block without any digital content. The digital content can be stored in another storage area or memory address associated with the hash value of the original file. The other storage area can be the same storage device used to store the blockchain, or can be a different storage area or even a separate relational database. The digital content of each block can be referenced or accessed by obtaining or querying the hash value of the block of interest, and then looking up the hash value stored in the storage area corresponding to the actual digital content. This operation can be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0128]

[0129] In Figure 7C an exemplary embodiment, the blockchain 770 includes a plurality of blocks 7781, 7782,..., 778 N where N > 1. The blocks 7781, 7782,..., 778 N are cryptographically linked in an ordered sequence. The cryptographic linking of the blocks 7781, 7782,..., 778 N is subject to a hash function that produces an n-bit alphanumeric output from an input based on information in the blocks (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and collision-resistant PRF algorithms. In another embodiment, the blocks 7781, 7782,..., 778 N may be cryptographically linked by a function other than a hash function. For purposes of illustration, the following description refers to a hash function (e.g., SHA-2).

[0130] Each of the blocks 7781, 7782,..., 778 N in the blockchain includes a header, a version of a file, and a value. The header and the value are different for each block due to the hashes in the blockchain. In one embodiment, the value can be included in the header. As described in more detail below, the version of the file can be the original file or a different version of the original file.

[0131] The first block 7781 in the blockchain is called the genesis block and includes the header 7721, the original file 7741, and the initial value 7761. The hashing scheme used for the genesis block, and indeed in all subsequent blocks, can vary. For example, a one-time hash can be performed on all of the information in the first block 7781 together, or each or portions of the information in the first block 7781 can be hashed separately, and then a hash of the separately hashed portions can be performed.

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

[0133] The original file 7741 in the genesis block can be, for example, data captured by a device, either processed or unprocessed prior to its inclusion in the blockchain. The original file 7741 is received from a device, media source, or node through an interface of the system. The original file 7741 is associated with metadata, which can be generated manually or automatically by a user, device, and / or system processor, for example. The metadata can be included in the first block 7781 associated with the original file 7741.

[0134] The value 7761 in the genesis block is an initial value generated based on one or more unique properties of the original file 7741. In one embodiment, the one or more unique properties can include a hash value of the original file 7741, metadata of the original file 7741, and other information associated with the file. In one embodiment, the initial value 7761 can be based on the following unique properties:

[0135] 1) SHA-2 computed hash value of the original file

[0136] 2) originating device ID

[0137] 3) original file start timestamp

[0138] 4) original file initial storage location

[0139] 5) software currently controlling the blockchain network member ID of the original file and associated metadata

[0140] The other blocks 7782-778 NAlso has a header, a file, and a value. However, unlike the first block 7721, the header 7722 to 772 N of each of the other blocks includes the hash of the immediately preceding block. The hash of the preceding block can be just the hash of the header of the preceding block, or it can be the hash of the entire preceding block. By including the hash of the preceding block in each of the remaining blocks, tracking can be done block by block as shown by arrow 780 from the Nth block back to the genesis block (and the associated original file) to establish an auditable and immutable chain of custody.

[0141] The header 7722 to 772 N of each of the other blocks can also include other information, such as a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or blockchain.

[0142] The file 7742 to 774 N in each of the other blocks can be equal to the original file, or it can be a modified version of the original file in the genesis block, depending on the type of processing performed, for example. The type of processing performed can vary from block to block. For example, the processing can involve any modification to the file in the previous block, such as editing information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0143] Additionally or alternatively, the processing can involve copying the file from the previous block only, changing the storage location of the file, analyzing the file from one or more previous blocks, moving the file from one storage or memory location to another, or performing an action with respect to the file and / or its associated metadata of the blockchain. Processing involving analyzing the file can include, for example, appending, including, or otherwise associating different analytics, statistics, or other information associated with the file.

[0144] The other block 7762 to 776 N in each of the other blocks has a value that is unique and different from the processing performed. For example, the value in any one block corresponds to an updated version of the value in the preceding block. This update is reflected in the hash of the block in which it is assigned. The value of the block thus provides an indication of what processing was performed in the block, and also allows tracking back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0145] For example, consider the case where a portion of the file in the previous block is edited, redacted, or pixelated to protect the identity of a person shown in the file. In this case, the block that includes the edited file will include metadata associated with the edited file, e.g., how the edit was performed, who performed the edit, a timestamp of when the edit occurred, etc. The metadata can be hashed to form a value. Because the metadata of the block is different from the information hashed to form the value in the previous block, these values are different from each other and can be recovered upon decryption.

[0146] In one embodiment, the value of the previous block can be updated (e.g., a new hash value computed) to form the value of the current block when any one or more of the following occurs. In this example embodiment, the new hash value can be computed by hashing all or a portion of the information noted below.

[0147] a) a new SHA-2 computed hash value if the file has been processed in any way (e.g., if the file was edited, copied, changed, accessed, or took some other action)

[0148] b) a new storage location of the file

[0149] c) new metadata identified as being associated with the file

[0150] d) a transfer of access or control of the file from one blockchain participant to another blockchain participant

[0151] Figure 7D An embodiment of a block showing the structure of a block that can represent a block in the blockchain 790 is shown. The block Block i includes a header 772 i , a file 774 i , and a value 776 i .

[0152] The header 772 i includes a hash value of the previous block Block i-1 and additional reference information, which can be any type of information discussed herein (e.g., header information including references, features, parameters, etc.), for example. All blocks (except, of course, the genesis block) reference the hash of the previous block. The hash value of the previous block can be just the hash of the header in the previous block, or it can be a hash of all or a portion of the information in the previous block (including the file and metadata).

[0153] The file 774 iThe data includes multiple pieces of data, such as data 1, data 2,..., data N in order. The data is tagged with metadata - metadata 1, metadata 2,..., metadata N - that describes content and / or characteristics associated with the data. For example, the metadata for each piece of data can include information indicating a timestamp for the data, processing the data, keywords indicating people or other content depicted in the data, and / or other characteristics that can be helpful in determining the validity and content of the overall file, particularly information that is useful for its use as digital evidence, as described, for example, in connection with embodiments discussed below. In addition to the metadata, each piece of data can be tagged with a reference REF1, REF2,..., REF N The tagging is done to prevent tampering, gaps in the file, and sequential references through the file.

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

[0155] Value 776 i is a hash value or other value calculated based on any type of information discussed previously. For example, for any given block Block i The value for that block can be updated to reflect processing performed for that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access rights, an identifier, or other action or information to be added. Although the value in each block is shown as being separate from the metadata and header for the data of the file, in another embodiment, the value can be based in part or in whole on the metadata.

[0156] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for the file can be obtained by querying the blockchain for a transaction history of the values across the blocks. The query or tracking process can start with decrypting the value for the currently included block (e.g., the last (Nth) block) and then continue decrypting the values for the other blocks until reaching the genesis block and recovering the original file. The decryption can also involve decrypting the header and file for each block and the associated metadata.

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

[0158] Generating a key can be similar to creating an account on a blockchain, but does not necessarily have to be registered anywhere in fact. Moreover, every transaction performed on a blockchain is digitally signed by the sender using his private key. This signature ensures that only the owner of the account can track and process (if within the scope of permissions determined by a smart contract) the files of the blockchain.

[0159] Figure 8A and Figure 8B Additional examples of use cases for blockchains that can be incorporated and used herein are shown. Specifically, Figure 8A An example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models to make accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can typically sift through millions of records to discover non-obvious patterns.

[0160] In the example of Figure 8A The host platform 820 builds and deploys a machine learning model for predictive monitoring of the asset 830. Here, the host platform 820 can be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The asset 830 can be any type of asset (e.g., machine or device, etc.), such as an airplane, a locomotive, a turbine, a medical machine and device, an oil and gas equipment, a ship, a vessel, a vehicle, etc. As another example, the asset 830 can be an intangible asset, such as a stock, a currency, a digital coin, an insurance, etc.

[0161] The blockchain 810 can be used to significantly improve the training process 802 of machine learning models and the prediction process 804 based on trained machine learning models. For example, in 802, rather than requiring a data scientist / engineer or other user to collect data, historical data can be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 820 in performing prediction model training. For example, using a smart contract, data can be sent directly and reliably from its origin location to the blockchain 810. By using the blockchain 810 to ensure the security and ownership of the collected data, the smart contract can send the data directly from the asset to the individual that builds the machine learning model with that data. This allows for the sharing of data between assets 830.

[0162] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. As a result, it is auditable, transparent, and secure. In certain cases (i.e., supply chain, healthcare, logistics, etc.), the addition of Internet of Things devices that write directly to the blockchain can increase the frequency and accuracy of the data being recorded.

[0163] Further, the training of the machine learning model on the collected data can be subject to multiple rounds of fine-tuning and testing by the host platform 820. Each round can help expand the knowledge of the machine learning model based on additional data or previously unconsidered data. In 802, the different training and testing steps (and the data associated therewith) can be stored on the blockchain 810 by the host platform 820. Each fine-tuning of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on the blockchain 810. This provides a verifiable proof of how the model was trained and what data was used to train the model. Further, when the host platform 820 has achieved a final trained model, the resulting model can be stored on the blockchain 810.

[0164] After the model is trained, it can be deployed to a live environment that can make predictions / decisions based on the execution of the final trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of an asset such as an airplane, a wind turbine, a healthcare machine, etc. In this example, data fed back from the asset 830 can be input to the machine learning model and used to make a prediction of an event such as a failure event, an error code, etc. The decision made by executing the machine learning model at the host platform 820 can be stored on the blockchain 810 to provide an auditable / verifiable proof. As one non-limiting example, the machine learning model can predict a future damage / failure of a part of the asset 830 and create an alert or notification to replace the part. The data behind this decision can be stored on the blockchain 810 by the host platform 820. In one embodiment, the features and / or actions described and / or illustrated herein can occur on or with respect to the blockchain 810.

[0165] New transactions of the blockchain can be gathered into a new block and added to the existing hash value. This is then encrypted to create a new hash of the new block. As transactions are encrypted, they are added to the next transaction list, and so on. The result is a blockchain that each contains the hash value of all previous blocks. The computers that store these blocks periodically compare their hash values to make sure they are all consistent. Any computer that disagrees with the record discards the record that caused the problem. This way is advantageous to ensure the tamper resistance of the blockchain, but is not perfect.

[0166] One way to game this system is for a dishonest user to change the transaction list in a way that is favorable to them, but keeps the hash the same. This can be done through brute force, in other words, by changing the record, encrypting the result, and then seeing if the hash value is the same. If it is not, try again and again until a matching hash is found. The security of the blockchain is based on the belief that ordinary computers can only do this brute force attack on a completely impractical timescale, such as the age of the universe. In contrast, quantum computers are much faster (thousands of times faster), and thus pose a greater threat.

[0167] Figure 8B An example 850 of a quantum secure blockchain 852 that implements quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can use QKD to verify each other’s identity. This uses quantum particles such as photons to send information, which a eavesdropper cannot copy without destroying them. In this way, the sender and receiver can determine each other’s identity through the blockchain.

[0168] In Figure 8BIn the example, there are four users 854, 856, 858, and 860. Each pair of users can share a key 862 (i.e., a QKD) between them. Since there are four nodes in the example, there are six pairs of nodes, so six different keys 862 are used, including QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD . Each pair can create a QKD by sending information using quantum particles (e.g., photons) that an eavesdropper cannot copy without destroying them. In this way, a pair of users can determine each other’s identity.

[0169] The operation of the blockchain 852 is based on two processes: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similarly to a traditional blockchain network. Each transaction can contain information about the sender, the recipient, the time of creation, the amount (or value) to be transferred, a list of reference transactions that prove that the sender has the funds to operate, etc. This transaction record is then sent to all other nodes, where it is input into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users in 854-860) authenticate the transaction by providing their shared key 862 (QKD). This quantum signature can be attached to each transaction, making it very difficult to tamper with. Each node checks their entries against a local copy of the blockchain 852 to verify that each transaction has enough funds. However, the transaction is not yet confirmed.

[0170] Instead of performing a traditional mining process on the blocks, a broadcast protocol can be used to create the blocks in a decentralized manner. At a predetermined period of time (e.g., seconds, minutes, hours, etc.), the network can apply a broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine agreement (consensus) on the correct version of the transactions. For example, each node can have a private value (the transaction data for that particular node). In the first round, the nodes pass their private values to each other. In subsequent rounds, the nodes pass the information they received from other nodes in the previous round. Here, the honest nodes are able to create a complete set of transactions within a new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or illustrated herein can occur on or with respect to the blockchain 852.

[0171] Figure 9An exemplary system 900 that supports one or more of the example embodiments described and / or illustrated herein is shown. The system 900 includes a computer system / server 902, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well- known computing systems, environments, and / or configurations that can be suitable for use with computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

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

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

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

[0175] Computer system / server 902 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system / server 902 and includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flow diagrams of other figures. The system memory 906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. Computer system / server 902 can also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive can also be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be provided for reading from or writing to a removable, non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media). In such instances, each can be connected to bus by one or more data media interfaces. As will be further depicted and described below, memory 906 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of different embodiments of the application.

[0176] Program / utility 916 having a set (at least one) of program modules 918, can be stored in memory 906 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, can include an implementation of a network environment. Program modules 918 generally carry out the functions and / or methodologies of different embodiments of the application as described herein.

[0177] As will be appreciated by those skilled in the art, aspects of the present application can be embodied as a system, method or computer program product. Accordingly, aspects of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or combinations of software and hardware that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present application can take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0178] The computer system / server 902 can also communicate with one or more external devices 920 such as a keyboard or pointing device, a display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any devices (e.g., network card, modem, etc.) that enable the computer system / server 902 to communicate with one or more other computing devices. Such communication can occur via the I / O interface(s) 924. Still yet, the computer system / server 902 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via the network adapter 926. As depicted, the network adapter 926 communicates with the other components of the computer system / server 902 via the bus. It should be appreciated that the computer system / server 902 can be a plurality of computer systems, devices, and / or components working together. Further, the computer system / server 902 can be connected to one or more other computer systems within a network, networked environment, and / or enterprise network, for example. Although the computer system / server 902 is depicted as a single computing device, it should be appreciated that the computer system / server 902 can be a plurality of computing devices working in concert.

[0179] While example embodiments of at least one of a system, method, and non-transitory computer readable medium have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the application is not limited to the embodiments disclosed, but rather can include modifications, permutations, additions, subtractions, and the like as fall within the scope of the following claims and their equivalents. For example, the capabilities of the systems of the various figures can be performed by one or more modules or components described herein or in a distributed architecture, and can include a transmitter, receiver, or paired transmitter, receiver. For example, all or a portion of the functionality performed by one module can be performed by one or more of the other modules. Further, the functionality performed by the modules can be performed at different times and in relation to different events than depicted and described herein. Moreover, communication between various modules can be facilitated by the use of a database, internet, intranet, web portal, wireless network, wireline network, and / or the like, and can be achieved through a variety of methodologies that are well known to persons skilled in the art. Also, messages sent and received between the modules can be sent and received directly and / or through one or more other modules.

[0180] Those skilled in the art will appreciate that a "system" can embody a personal computer, server, console, personal digital assistant (PDA), cellular telephone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is merely to provide one illustrative example of a manner in which the methods, systems, and devices disclosed herein can be implemented. Indeed, the methods, systems, and devices disclosed herein can be implemented in local and distributed form consistent with computing technology.

[0181] It should be noted that some of the system features described in this specification have been presented as modules in order to more particularly emphasize their implementation independence. For example, a module can 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 can also be implemented in a programmable hardware device such as a field programmable gate array, a programmable array logic, a programmable logic device, a graphics processing unit, or the like.

[0182] Modules can also, at least partially, be implemented in software, executed by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, a procedure, or a function. Nevertheless, the executables of an identified module need not be physically located together, but can comprise disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, modules can be stored on a computer-readable medium, which can be, for instance, a hard disk drive, a flash device, random access memory (RAM), a tape, or any other such medium that stores data for execution by a computer.

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

[0184] It will be readily appreciated that the components of the present application, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the foregoing detailed description of the embodiments of the application is not intended to be limiting, but rather a representative of selected embodiments of the application.

[0185] One of ordinary skill in the art will readily understand that the above can be practiced with steps in different orders, and / or with hardware elements in configurations which are different than those disclosed. Accordingly, although the present application has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, changes, and substitutions are expected. Therefore, it is intended that the application not restricted but is only as broad as permitted by the appended claims, which follow.

[0186] While preferred embodiments of the application have been described, it should be understood that the described embodiments are merely illustrative of the application and that changes in the protocol, hardware devices, software platforms, etc. can be made to the full extent of equivalents and modifications as they are guided by the scope of the appended claims.

Claims

1. A computing system for off-chain notification of updates from a private blockchain, the computing system comprising: a processor configured to execute a bootstrap smart contract on the private blockchain to create a link between a non-participant system and a data field stored on the private blockchain by chaincode, wherein the data field comprises participant data of a participant entity having access to the private blockchain and the non-participant system belongs to a non-participant entity not having access to the private blockchain; detect a change in a value of the participant data based on a read operation on the data field stored on the private blockchain; and generate a notification of the changed value of the participant data; a network interface configured to send the notification to the non-participant system based on the link between the non-participant system and the data field, wherein the processor is further configured to generate a message comprising the changed value of the participant data and store the generated message within a data block of a different blockchain.

2. The computing system of claim 1, wherein, The processor stores a public key of the non-participant system with an identifier of the data field in an access matrix of the private blockchain to create the link.

3. The computing system of claim 1, wherein, The data field is stored within one or more of a body of a data block, a key-value store, and a world state database of the private blockchain.

4. The computing system of claim 1, wherein, The processor is further configured to hash the message comprising the changed value of the participant data and control the network interface to send the hashed message to the non-participant system.

5. The computing system of claim 1, wherein, The processor is configured to detect a modification of the value of the data field by a participant corresponding to the participant data.

6. The computing system of claim 5, wherein, In response to detecting the modification of the value, the processor is configured to trigger a notification entity of the private blockchain to send a notification to the non-participant system encrypted with the public key of the non-participant system comprising a proof of authenticity of the changed value verifiable independently by the public blockchain.

7. The computing system of claim 1, wherein, The processor generates the notification of the changed value of the participant data in response to a consensus among blockchain nodes of the private blockchain.

8. A method for off-chain notification of updates from a private blockchain, the method comprising: executing a bootstrap smart contract on the private blockchain; creating a link between a non-participant system and a data field stored on the private blockchain by chaincode, wherein the data field comprises participant data of a participant entity having access to the private blockchain and the non-participant system belongs to a non-participant entity not having access to the private blockchain; detecting a change in a value of the participant data based on a read operation on the data field stored on the private blockchain; generating a notification of the changed value of the participant data; sending the notification to the non-participant system based on the link between the non-participant system and the data field; wherein the method further comprises generating a message comprising the changed value of the participant data and storing the generated message within a data block of a different blockchain.

9. The method of claim 8, wherein, The creating the link comprises storing a public key of the non-participant system with an identifier of the data field in an access matrix of the private blockchain.

10. The method of claim 8, wherein, The data field is stored within one or more of a body of a data block, a key-value store, and a world state database of the private blockchain.

11. The method of claim 8, further comprising hashing a message comprising a changed value of the participant data and sending the hashed message to the non-participant system.

12. The method of claim 8, wherein, The detecting comprises detecting a modification of a value of the data field by a participant corresponding to the participant data.

13. The method of claim 12, further comprising, in response to detecting the modification, triggering a notification entity of the private blockchain to send a notification to the non-participant system comprising a proof of authenticity of the changed value that is independently verifiable by the public blockchain encrypted with a public key of the non-participant system.

14. The method of claim 8, wherein, The generation of the notification of the changed value of the participant data is performed in response to a consensus reached among the blockchain nodes of the private blockchain.

15. A non-transitory computer readable medium comprising instructions that, when read by a processor, cause the processor to perform the method of any one of claims 8-14.

Images