Permission events in a decentralized database

Abstract

Example operations include one or more of receiving event data from an entity, determining that the event data satisfies an endorsement policy, setting an identifier corresponding to a context of the event data, generating an event including the event data and the identifier, and submitting the event for recording in a distributed database, where the identifier is used to verify that a state corresponding to the context in the event data is correct.

Description

BACKGROUND

[0001] A centralized database stores and maintains data in a single database (e.g., database server) at one location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. Multiple users 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 a given data set has only one primary record. SUMMARY

[0002] One example embodiment provides a system comprising: a receiver to receive event data from an entity; a storage area to store chaincode of a smart contract; and a processor to execute the smart contract to perform one or more of: determining that the event data satisfies an endorsement policy; setting an identifier corresponding to a context of the event data; generating an event comprising the event data and the identifier, and submitting the event for recording in a decentralized database, wherein the identifier verifies that a state corresponding to the context in the event data is correct.

[0003] Another example embodiment provides a method comprising one or more of: receiving event data from an entity; determining that the event data satisfies an endorsement policy; setting an identifier corresponding to a context of the event data; generating an event comprising the event data and the identifier; and submitting the event for recording in a decentralized database, wherein the identifier verifies that a state corresponding to the context in the event data is correct.

[0004] Yet another 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: receiving event data from an entity; determining that the event data satisfies an endorsement policy; setting an identifier corresponding to a context of the event data; generating an event comprising the event data and the identifier; and submitting the event for recording in a decentralized database, wherein the identifier verifies that a state corresponding to the context in the event data is correct. BRIEF DESCRIPTION OF DRAWINGS

[0005] Figure 1A A network diagram illustrating a system including a database according to an example embodiment is shown.

[0006] Figure 1BAnother network diagram of components operating with a database is shown, in accordance with example embodiments.

[0007] Figure 1C Another network diagram of components operating with a database is shown, in accordance with example embodiments.

[0008] Figure 2A An example blockchain architecture configuration is shown, in accordance with example embodiments.

[0009] Figure 2B A blockchain transaction flow is shown, in accordance with example embodiments.

[0010] Figure 3A A permissioned network is shown, in accordance with example embodiments.

[0011] Figure 3B Another permissioned network is shown, in accordance with example embodiments.

[0012] Figure 3C A permissionless network is shown, in accordance with example embodiments.

[0013] Figure 4 A system message diagram is shown, in accordance with example embodiments.

[0014] Figure 5 A flow diagram is shown, in accordance with example embodiments.

[0015] Figure 6A An example system configured to perform one or more operations described herein is shown, in accordance with example embodiments.

[0016] Figure 6B Another example system configured to perform one or more operations described herein is shown, in accordance with example embodiments.

[0017] Figure 6C Another example system configured to utilize a smart contract is shown, in accordance with example embodiments.

[0018] Figure 6D Yet another example system configured to utilize a blockchain is shown, in accordance with example embodiments.

[0019] Figure 7A A process for a new block to be added to a distributed ledger is shown, in accordance with example embodiments.

[0020] Figure 7B Content of a new data block is shown, in accordance with example embodiments.

[0021] Figure 7C A blockchain for digital content is shown, in accordance with example embodiments.

[0022] Figure 7D A block is shown that can represent a structure of a block in a blockchain, according to example embodiments.

[0023] Figure 8A An example blockchain storing machine learning (artificial intelligence) data is shown, according to example embodiments.

[0024] Figure 8B An example quantum secure blockchain is shown, according to example embodiments.

[0025] Figure 9 An example system is shown that supports one or more example embodiments. DETAILED DESCRIPTION

[0026] 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 claimed application, but is merely representative of selected embodiments.

[0027] In one or more embodiments, features, structures, or characteristics as described throughout this description can be combined or removed in any suitable manner. For example, the use of the phrases “example embodiment,” “some embodiments,” or other similar language throughout this description is intended to refer to the fact that a particular feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment. Thus, the appearance of the phrases “example embodiment,” “in some embodiments,” “in other embodiments,” or other similar language throughout this description is not necessarily all referring to the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any suitable manner in one or more embodiments. Further, in the Figures, any connection between elements can allow for one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. Also, any device depicted in the Figures can be a different device. For example, if a mobile device is shown as sending information, a wired device can also be used to send the information.

[0028] Further, while the term “message” is used in the description of embodiments, other types of network data can also be used, e.g., packets, frames, datagrams, etc. Further, while specific types of messages and signaling can be described in exemplary embodiments, they are not limited to specific types of messages and signaling.

[0029] In one embodiment, the application utilizes a decentralized database as a distributed storage system, such as a blockchain, that includes a plurality of nodes that communicate with each other. The decentralized database includes an append-only immutable data structure akin to a distributed ledger that is capable of maintaining records between mutually untrusted parties. 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, a permissioned and / or unpermissioned blockchain can be used. In a public or unpermissioned blockchain, anyone can participate without a specific identity. A public blockchain can involve local cryptocurrencies and use consensus based on various protocols, such as proof of work (PoW). In contrast, a permissioned blockchain database provides secure interactions between a group of entities, such as businesses that exchange funds, goods, information, etc., that share a common goal but do not fully trust each other.

[0030] The present application can utilize a blockchain that operates arbitrary, programmable logic that is tailored to a decentralized storage scheme and is referred to as a“smart contract” or“chaincode.” In some cases, there can be a dedicated chaincode that is referred to as system chaincode that manages functions and parameters. The application can also utilize a smart contract, which is a trusted distributed application that utilizes the tamper-proof nature of the blockchain database and the underlying protocol between the nodes, which is 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 chaincode to specify endorsers for transactions in the form of a set of peers that are necessary 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, where a consensus protocol is used to produce an ordered sequence of endorsed transactions that are grouped into blocks.

[0031] The present application can utilize nodes that are communication entities of a blockchain system. A "node" can perform logical functions in the sense that different types of multiple nodes can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in different ways. Nodes can include different types, such as client or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive client-submitted transactions, submit transactions, and maintain a state and copy of a ledger of blockchain transactions. Peers can also have the role of endorsers. Ordering service nodes or orderers are nodes that run a communication service for all nodes and implement delivery guarantees, such as broadcasting to every peer node in the system when submitting transactions and modifying the world state of the blockchain. The world state can constitute the initial blockchain transactions, which typically include control and setup information.

[0032] The present application can utilize a ledger, which is a tamper-resistant record of all state transitions of a 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. Transactions can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0033] The present application can utilize a chain that 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 the block and a hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. As such, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that has occurred prior to the chain, enabling consensus and trust that all peer nodes are in a 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.

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

[0035] Events are a type of message that are transmitted in blockchain networks and other types of decentralized databases. Events can be created by validators using chaincode of a smart contract when certain conditions are met. For example, a type of event, often referred to as a fundamental event, can be created when a new block of transactions is to be committed to the blockchain. Other types of events can constitute or indicate a state of chaincode. For example, a custom event can involve certain messages that chaincode has designated for distribution to entities (e.g., nodes, users, clients, etc.) inside or outside of the network. It is not uncommon for events of a network to have different levels of privacy, access, or restrictions, e.g., as determined by their confirmers and / or network policies. Different chaincodes can be used to manage the creation, distribution, and / or access of events with different levels of state.

[0036] Example embodiments provide methods, systems, components, non-transitory computer readable media, devices, and / or networks that generate and validate events before the events are stored in a decentralized database, such as but not limited to a blockchain. Event generation and validation are performed in a manner that improves the functioning of computers that manage blockchain information and assets. In one embodiment, the improvement is achieved by adding new information that is stored in association with an event, which binds the event (and, e.g., one or more associated transactions) to an object and / or namespace that is managed by the database. The new information can be, e.g., key information such as but not limited to a key name or key address.

[0037] By performing operations based on new information, validation of events can be performed in a more timely and processing-efficient manner in connection with database queries related to events, prior to submission of events to a database. In one embodiment, key information is pre-validated with respect to an object or event. Thus, when an event (and transaction) exists in a field associated with the event, the key information is used to automatically validate the event (and transaction(s)) along with the event (and, for example, one or more accompanying transactions) to be recorded in a blockchain or other database. In one embodiment, such a field can be included in or appended to the event. In that or another embodiment, a transaction associated with an event can include a message format that includes the field along with event data. Thus, checking for the presence of valid key information (e.g., matching known key information) is used to validate the event and its accompanying transaction(s) without having to query the web of peers in the database to perform the validation.

[0038] In one embodiment, operations are performed to relate an event to a pseudo-write in a state namespace. When an event is defined, the event can include establishing key information that produces validity of the event. When the event and one or more associated transactions are validated, the event can be assessed as a pseudo-write of that key information. Even when no state modification is performed to that key, validation can ensure that the event and / or associated transactions will still be valid even if the transaction modifies the key information. This has the advantage that a consumer of the event (e.g., a node and / or a node client) can now consider the event valid only if and only when the event is associated with the expected key information. If the key and its access are properly selected, the validity of the event implies the validity of the associated transaction(s).

[0039] In addition to the foregoing, from a security perspective, some additional benefits of the instant solutions described and depicted herein include assuring a database client (e.g., a consumer in a billing management application) that an event and its transactions and other content are correct, provided that the event and its associated transactions / content are properly endorsed and assuming that the endorsement policy is properly set (e.g., if the endorsement policy is incorrect, then no correctness of any ledger key can be claimed). With the key information and its accompanying operations provided by the embodiments described herein, if a database user (e.g., through a client application) wants to attempt to confirm the correctness of an event, the user will have to resort to querying after receiving the event in order to verify from a sufficient number of peer nodes whether the conditions or other content of the event are actually true.

[0040] Figure 1AA logic diagram illustrating an example embodiment of a system 100 for validating that an event is correct before data corresponding to the event is generated and recorded in a distributed database is shown. For illustrative purposes, the distributed database will be discussed as a blockchain. However, in another embodiment, a different type of database can be used.

[0041] Referring to Figure 1A , the system 100 includes a network entity, such as a node (N1) 120 coupled to a client (or client application) 110. The client 110 can generate event data 115 that is transmitted over a communication link to the node 120, which can include, for example, a wired or wireless network or other communication pathway. The event data can include any form of information, but can specifically relate to an intended application of a blockchain. In one non-limiting example discussed in greater detail below, the event data includes billing information for a customer of one or more network entities. In this case, the network entities can belong, for example, to the same company or different companies. In one embodiment, the client 110 can encrypt the event data and / or one or more associated transactions before being delivered to the node 120. Corresponding decryption (e.g., key) information can be located at one or more other nodes of the blockchain network or associated clients, which can be used to perform decryption to access, for example, events resulting from a query from the blockchain. The node 120 can be one of a plurality of nodes of a distributed database. In one embodiment, the node 120 can be a peer node that performs event and / or transaction validation before submitting the events and transactions to the blockchain.

[0042] As Figure 1A shown, the node 120 includes a processor 122 and a storage area 124 that stores chaincode of a smart contract executed by the processor. In operation, the processor receives event data from the client 110 and then compares the event data to an endorsement policy 125. If the conditions or requirements of the endorsement policy are satisfied, the processor 122 executes the chaincode of the smart contract to generate an event. The event, alone or with one or more associated transactions, can then be submitted for consensus and committal by the blockchain. In one embodiment, each event or associated transaction can relate to the same or different object managed in the blockchain database. In some cases, the event and associated transaction can indicate different states of the object. Thus, the blockchain can store events with associated transactions, where the content of each event can represent a different state (or state change) of the associated object. To generate key information on a namespace basis, the node 120 (and indeed one or more other nodes in the blockchain network) can include namespace logic 126.

[0043] Figure 1BAn example of a logical relationship 150 between a series of transactions 1701-170N recorded with a blockchain over time is shown. In this example, all transactions involve the same object or namespace 190. In a billing application, the object 190 can correspond to the status of a customer's bill corresponding to event data received by the nodes 120. In this case, the clients 110 can be a bank, credit card company, utility company, or another entity that bills for goods and / or services.

[0044] Referring to Figure 1B , one or more of the transactions 1701-170N can be associated with a corresponding event generated by the processor of the nodes 120 based on a different item of event data received from the clients 110. In this example, event (El) 1801 corresponds to associated transaction (Tl) 1701, event (E2) 1802 corresponds to associated transaction (T2) 1702, and so on. Each event can indicate a status of the object (or its associated transaction). While the events are shown as distinct from the transactions in Figure 1B , in one embodiment, the events (or event data) can be included in additional or additional fields of the transaction or event format. For example, in one embodiment shown in Figure 1C , the format 195 of each transaction or event can have a message structure including a first field 196 containing information indicating event data, a second field 197 including event key information that can be used for improved validation according to one or more embodiments described herein, and a third field 198 including transaction information.

[0045] One possible relationship between transactions and events can be understood according to the following example. When the object 190 indicates a bill for customer X, event (El) 1801 can indicate a status that a bill has been generated for customer X. The associated transaction (Tl) 1701 can indicate, for example, the amount of the bill. Event (E2) 1802 can indicate a different status of the bill. For example, event E2 can indicate a status (T2) 1702 that the bill has not been paid for a transaction indicating that a first due date for that bill has expired. One or more subsequent transactions can reflect different additional status changes and associated transactions. For example, even (EN) 180N can indicate that the bill for customer X has been paid, and its associated transaction (TN) 170N can indicate that a late fee has been added to the bill. From this, for a blockchain ledger, transactions can be recorded with associated events for the same object managed by the network.

[0046] In one embodiment, an object can be associated with a namespace of the state of the blockchain network. The namespace can be a partition of the state space with different validation rules than the global namespace of the smart contract, such as a private data collection in a hyperledger structure. The namespace can even be a single key with its own validation rules, such as a state-based endorsement in a hyperledger structure or a token in other blockchain systems.

[0047] Returning Figure 1A To prevent fraud and ensure the validity of information stored in the blockchain, the chaincode of the smart contract execution processor 122 can generate an event that includes an additional field for verification, e.g., confirming that the event is correct or otherwise true and valid. This can be performed, for example, by the processor executing the chaincode of the smart contract 124 to generate information linked to the object (e.g., an identifier). The identifier can be generated, for example, by the network authority and pre-authorized for use with the object (or namespace). Thus, the identifier can act as a basis for verifying the event only by being linked to the event, thereby mitigating the need to query the ledger of the peer nodes in the blockchain in order to determine that the content of the event (and its associated transaction) is correct. In Figure 1C In an example event or transaction format, the identifier can be included in a second field 197, which is a newly generated field reserved for event verification purposes.

[0048] Once the identifier is set (e.g., by accessing pre-stored information or directly from the network authority), the processor 122 can insert the identifier in the second field for verification. In at least this way, the processor can be said to perform a pseudo-write operation, which involves pre-storing information in a dedicated field of the event (or transaction), which can be used to verify the event before the event is generated for consensus and submission to the blockchain. The generation and insertion (or other association) of this identifier in the event can improve the efficiency of the computer managing the blockchain, at least in terms of reducing the processing overhead of the peer nodes and the overall managing network entities.

[0049] In one embodiment, the information stored in the new second field of the event can be linked to an object associated with the event. For example, in one embodiment, the generated identifier pseudo-written into the second field of the event / transaction can include key information that has been pre-generated for a particular object corresponding to the event. Because the key information for the object has been verified (e.g., by a network authority), the event (and its associated transaction) can be verified by confirming that the key information is associated with the event. This alleviates the need to query the ordering service of the blockchain node to verify the event and its associated transaction before submitting the transaction to a new block to be appended to the blockchain. Thus, the key information can be used to effectively bind the event to an authorization mechanism or verification authority programmed to perform verification or authorization based on the key information. In one embodiment, the key information can include a key name assigned to the object. In another embodiment, the key information can include a key address assigned to the object. In yet another embodiment, the processor can generate different types of identifying information associated with the object based on the event data received by the client 110 for use in authorizing the generation of the event. The key information can be encoded with one or more security features (e.g., different forms of encryption) prior to insertion into the additional field of the event or transaction format.

[0050] In one embodiment, the chaincode of the smart contract implemented by the processor 122 can be programmed to generate key information for event authorization based on namespaces. Each namespace can have a plurality of corresponding objects, which can be different from the objects corresponding to other namespaces, and each of the objects can have one or more corresponding transactions and / or events, depending on, for example, the intended application of the blockchain.

[0051] To generate key information on a namespace basis, the node 120 (and indeed one or more other nodes in the blockchain network) can include namespace logic 126. Such logic can be, for example, part of a blockchain platform such as, but not limited to, the Hyperledger Sawtooth platform. The namespace logic 126 can be used by the node 120 to authorize the generation of events to provide separation between unrelated transactions (e.g., transactions that are not related to the same object). For example, the node 120 can include namespace logic 126 that uses a global state store and allows the store to be divided into different namespaces, where each namespace corresponds to a separate category of objects. In one non-limiting example, each namespace can correspond to a different customer, and the events corresponding to each namespace can correspond to invoices issued to those customers.

[0052] When the node 120 includes namespace logic, different key information can be pre-generated for each object in each namespace. In one embodiment, the same key information can be generated for multiple objects corresponding to the same namespace. In either case, the key information can be pre-validated and authorized for use in association with events and / or transactions corresponding to the associated objects. In this way, event authorization can be performed by confirming that events issued by the node 120 for authorization and subsequent records in the blockchain have the appropriate corresponding key information assigned to the objects to which the events correspond. As a result, inefficient processing of querying the node directory in the blockchain to perform event authorization can be prevented, thereby improving the operation of the computer as it relates to managing event generation, authorization, consensus, and submission of blockchain transactions, and to subsequent operations of verifying transactions and their associated events when the blockchain is queried by the same or another node.

[0053] According to the foregoing features, the node 120 can operate as follows when implementing one or more embodiments described herein. When receiving event data from the client 110, the processor 122 issues a new event by additionally setting a new (event validation) field in the event (or transaction format), which includes key information corresponding to the object and / or the namespace to which the object corresponds. As previously explained, the issued event can include information indicating the status corresponding to the transaction for which the event is performing a pseudo-write. The platform validation code (e.g., included in the chaincode of the smart contract) checks the key information in the new (event validation) field when validating one or more corresponding transactions.

[0054] In some cases, the transaction associated with the issued event can have modified the key information. However, storing the key information in the new field ensures that the key information referenced by the node 120 or the platform validation code, for example, is still considered valid (except for any modifications actually performed by the transaction) even when the transaction is modified.

[0055] Subsequently, when a client application (e.g., corresponding to client 110, another client of node 120, or a client of another node in the blockchain network) performs a query to retrieve a transaction event from a block in the blockchain, the client application can verify the validity (or correctness) of the transaction event by performing a comparison based on the key information stored in the event verification field of the transaction event. For example, because the client application can have access to or has recorded the key information for the particular object (and / or namespace) associated with the retrieved transaction event, the client application can compare the key information stored in the field of the retrieved transaction event to the known key information for that object (or namespace). If there is a match, the client application determines that the transaction event is valid without having to query branches of other nodes in the blockchain network. If there is no match, the client application can determine that the transaction event recorded in the blockchain is fraudulent (e.g., from a malicious attacker) or otherwise untrustworthy.

[0056] An example scenario for these embodiments is a billing application. For example, if a smart contract executed by processor 122 of node 120 is to issue an event indicating that a particular bill (object) for a customer has been fully paid, the event can be augmented with a field referencing key information for the bill. In this case, if the customer and / or other parties (e.g., a credit card company) authorizing the associated transaction (e.g., transferring funds to pay the bill) have the right to modify the event state for the bill, the "fully paid bill" event can only be considered valid. The validity of the event state can be confirmed based on the key information (or transaction message format) stored in the additional field of the event.

[0057] In some cases, in the example scenario described above, the transaction itself can cause the key information to be modified. For example, updating the event state for a bill from "unpaid" to "fully paid" can result in a large set of keys being modified, not all of which are susceptible to prediction or require equivalent endorsement to authorize the bill payment. However, some of these keys (such as the key representing the paid state of the bill) must be modified in a valid transaction and, therefore, must be endorsed by the entity authorized to modify the bill. By tying the event to the key information, a client application can only need to determine a subset of the state machine of the smart contract in node 120 that created the event to retrieve information from the blockchain attempting to confirm the full payment. This can have the beneficial effect of preserving the privacy and security of the customer information while allowing the client application to obtain the information it has requested in order to confirm the validity of the bill payment.

[0058] Without the key information, the client application will need to operate in an insecure manner (performing no event validation at all) or will at least need to perform time and processing inefficient operations in order to validate events, both prior to submission to the blockchain and during validation after a blockchain query by the client application. For example, the client will have to make round-trip queries to the ledger state to confirm that the event was generated properly. Moreover, without the event key binding approach of the embodiments described herein, an attacker who has not paid a bill can issue a valid transaction (e.g., that might pay an unrelated smaller bill), but attach an event indicating payment of a different larger bill. When the event is received, the application can (a) examine the state modification of the transaction and attempt to validate that the state modification corresponds to the event content (this approach is fragile and error prone), (b) immediately return to the ledger to ask what the state of the bill is to confirm that the event content is correct (this is expensive and error prone), or (c) accept the event at face value and be subject to attack. By introducing the event binding of the embodiments, the client application can for example take approach (c) with additional validity checks performed based on matching key information in the new event fields and remain secure.

[0059] Figure 2A A blockchain architecture configuration 200 according to example embodiments 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 depicted by way of example only). These nodes participate in many activities, such as blockchain transaction addition and validation 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 of the 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 a supporting physical infrastructure 214. The blockchain configuration can include one or more applications 224 that are 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 for example be deployed as a transaction and installed on all of the blockchain nodes 204-210 via an addition to the distributed ledger.

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

[0061] Figure 2A The blockchain architecture configuration of FIG. 2 can handle and execute program / application code 220 via 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 and can be executed by the nodes 204-210 in the form of a smart contract and associated chaincode that has conditions or other code elements subject to its execution. As a non-limiting example, a smart contract can be created to perform reminders, updates, and / or other notifications subject to change, update, 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 information 226 can include event data received from a client application, node, or other network entity. The event data can be used by the receiving node as a basis for generating and validating events. Event generation and validation can be performed using logic of chaincode including a smart contract implemented by the receiving node. For example, the chaincode can be included in the application 224 or can be separate from the application 224. The smart contract and / or application 224 can be executed by one or more processing entities included in the blockchain layer 216 (in one case, e.g., a virtual machine).

[0062] In other operations, the chaincode of the smart contract can generate and validate events, e.g., based on existing endorsement policies in the database network. In one embodiment, the smart contract can determine a database object (e.g., an invoice) and / or namespace related to the received event data. The node can then endorse and validate the event (and any attendant transactions) based on the terms of the endorsement policy. If the conditions are satisfied (e.g., can differ depending on the content of the event data and / or intended application of the database), the node can digitally sign the event and authorize it to be issued throughout the network, e.g., including that it is committed to the blockchain.

[0063] In one embodiment, an endorsement can be predicted based on event data associated with an object or predetermined namespace managed by the database network. For example, a smart contract of a node that receives the event data can check the contents of the data against known objects and / or namespaces managed by the network. If there is a match, the smart contract can retrieve key information stored in association with the object or namespace and then generate a corresponding event that includes a new field for storing the key information. Including the key information in the event guarantees that the contents of the event (including, for example, any state changes or transactions associated with the event) are correct and valid.

[0064] The result 228 can include a now endorsed and validated event with a new field that includes the key information generated by the smart contract. The event can be output with or without one or more associated transactions. The event (and associated transactions) can be output to the blockchain network for consensus and subsequent submission to a new block in the blockchain. In one embodiment, the event can be sent as a notification to other nodes in the blockchain network. Once committed to the blockchain, a client application in communication with a node (e.g., peer nodes 204, 206, 208, 210, etc.) can query the blockchain for the event. The key information included in the new field can thus be used to automatically validate that the contents of the event and any associated transactions are correct. The physical infrastructure 214 can be used to retrieve any data or information described herein.

[0065] The smart contracts described herein can be created via a high-level application and programming language and then written to a block in the blockchain. A smart contract can include executable code that is registered, stored, and / or replicated with the blockchain (e.g., the distributed network of blockchain peers). A transaction is an execution of the 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 execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers by one or more consensus protocols.

[0066] A smart contract can write data to the blockchain in the format of key-value pairs. Further, 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 execution environment of the supply and then deleted once the data needed by the blockchain is identified.

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

[0068] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain is shown in accordance with example embodiments. 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 chaincode functions to initiate the transaction. The output can include chaincode results, a set of key / value versions read in the chaincode (read set), and a set of 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 transaction as a block 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 has signed the results and validate the signature on the transaction payload 293.

[0069] Referring again to Figure 2B , the client node 260 initiates a transaction 291 by constructing 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 to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., a new key / value pair is written for an asset). The SDK can act as a shim to package the transaction proposal into an 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.

[0070] 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 instance, the client 260) is properly authorized to perform the proposed operation on the channel. The endorsed 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 is made to the ledger at this time. In 292, the value set is passed back to the SDK of the client 260 along with the signature of the endorsing peer 281 as a proposal response 292, which the SDK parses for the payload that the application consumes.

[0071] In response, the application of the client 260 checks / verifies the signature of the endorsing peer and compares the proposal response to determine if the proposal responses are identical. If the chaincode only queries 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 peers 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 in the commit validation phase even if the application chooses not to check the response or otherwise forward an unendorsed transaction.

[0072] Upon successful checking, in 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 signatures of the endorsing peers, and the channel ID. The ordering node 284 need not check the entire 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.

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

[0074] 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 through a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to regulators 306 such as auditors. A blockchain network operator 308 manages member permissions, such as registering the regulators 306 as "auditors" and the blockchain user 302 as a "client." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0075] Blockchain developers 310 can write chaincode and client-side applications. Blockchain developers 310 can deploy chaincode directly to the network through an interface. To include credentials from traditional data sources 312 in the chaincode, developers 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 credentials from a certificate authority 316 that manages user roles and permissions. In some cases, the blockchain user must possess these digital credentials in order to transact on the permissioned blockchain 304. At the same time, users attempting to utilize chaincode can be required to validate their credentials on traditional data sources 312. To confirm the user's authorization, chaincode can use an out-of-band connection to that data through a traditional processing platform 318.

[0076] Figure 3B Another example of a permissioned blockchain network 320 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, a blockchain user 322 can submit a transaction to a permissioned blockchain 324. In this example, the transaction can be a deployment, invocation, or query, and can be published through a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to regulators 326 such as auditors. A blockchain network operator 328 manages member permissions, such as registering the regulators 326 as "auditors" and the blockchain user 322 as a "client." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0077] A blockchain developer 330 writes chaincode and client-side applications. The blockchain developer 330 can deploy chaincode directly to the network through an interface. To include credentials from traditional data sources 332 in the chaincode, the developer 330 can use an out-of-band connection to access the data. In this example, a blockchain user 322 connects to the network through a peer 334. Before making any transactions, the peer 334 retrieves the user's enrollment and transaction certificates from a certificate authority 336. In some cases, the blockchain user must possess these digital certificates in order to transact on a permissioned blockchain 324. Meanwhile, users attempting to leverage chaincode can be required to validate their credentials on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to that data through a processing platform 338.

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

[0079] Figure 3C Processing 350 of a transaction handled by an un-permissioned 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, medical record, contract, good, service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the un-permissioned 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 user interface controls and a display of 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 un-permissioned 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.

[0080] In construct 362, valid transactions are formed into a block and sealed with a lock (hash). This process can be performed by a node in the mining node 354. The mining node can utilize additional software that is specifically used to mine and create 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 the 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, independent chain of blocks.

[0081] Before a block can be added to the blockchain, the block must be validated. Validation for the 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 for validating blocks is proof-of-stake, which is not shown in the example of FIG. 3. Unlike proof-of-work, where an algorithm rewards miners who solve mathematical problems with proof-of-stake, the creator of a new block is selected in a deterministic way, depending on its wealth, also defined as “stake.” A similar proof is then performed by the selected / choosing node.

[0082] With mining 364, a node attempts to solve the block by incrementally changing one variable until the solution satisfies the goal of the full network. This results in PoW, which ensures the correct answer. In other words, a potential solution must prove that it exhausted computational resources in solving the problem. In some types of permissionless blockchains, a miner can be rewarded with a value (e.g., coin, etc.) for correctly mining a block.

[0083] Here, the PoW process makes modifications to the blockchain extremely difficult alongside the chain of blocks, because an attacker must modify all subsequent blocks in order for a modification of one block to be accepted. Moreover, the difficulty of modifying a block increases as new blocks are mined, and the number of subsequent blocks increases. With distribution 366, the successfully validated block is distributed through the permissionless grouping chain 352, and all nodes 354 add the block to the majority chain as the auditable ledger of the permissionless grouping chain 352. Moreover, values in the transactions submitted by the sender 356 are deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0084] Figure 4 A system message diagram 400 for generating and confirming an event is shown in accordance with example embodiments. Referring to Figure 4 The system diagram 400 includes a first entity 410, a second entity 420, and a blockchain 430. The first entity 410 can be a first node of a blockchain network, and the second entity 420 can be a second node of the blockchain network.

[0085] With reference to Figure 4 The message graph includes receiving a first message 411 that includes event data to be considered in generating a new event. The first message can be received from a client application in communication with the first entity 410, another node of the blockchain network, or another entity. The event data can include content that identifies or provides information that can be used as a basis to identify an object and / or namespace of the blockchain network. In one embodiment, the content of the event data can indicate a status (or change in status) of a related object, e.g., for an object of a bill for a particular customer of a company, the event data can indicate that the status of the bill has changed from a status of "unpaid" to a status of "fully paid."

[0086] In operation 412, once the first message is received, the processor of the first entity 410 executes the smart contract to determine the content of the first message. The content is submitted to an endorsement policy that can define a set of conditions or operations to be performed in endorsing and validating the event data in order to determine whether an event should be generated in the network. The conditions or operations can include determining whether the object indicated by the content of the message corresponds to key information previously generated and maintained by the blockchain network. Additionally or alternatively, the processor of the first entity can determine whether there is a predetermined namespace corresponding to the content of the event data. If none of the conditions are met, then the event data can not be validated and the generation of the event can be denied. On the other hand, if the conditions of the endorsement policy have been met, then an event can be generated.

[0087] In operation 413, once it is determined that the conditions of the endorsement policy have been met, the processor executing the smart contract of the first entity 410 generates an event having a new field storing key information corresponding to the object and / or namespace related to the event data. This operation can be performed in various ways. For example, the generated event can include a new field having the key information. Additionally or alternatively, the message format of the transaction associated with the event can include a new field containing the key information.

[0088] Once the event has been created, a message 414 is sent to the blockchain 430. This message can be sent with the event and one or more associated transactions, if they exist. Upon receipt, in operation 415, the blockchain submits the event for consensus and then commits the event in a new block in the blockchain.

[0089] A message 416 can then be sent from the second entity 420 to the blockchain 430 at any point after the event has been committed to the blockchain. The message 416 can include a query to access the event and its accompanying transaction(s).

[0090] In operation 417, the block containing the event is retrieved from the blockchain and sent back to the second entity 420 in a reply message 418.

[0091] In operation 419, the second entity 420 searches the content of the event retrieved from the blockchain and retrieves key information. The key information is then compared to known key information for the object (and / or namespace) corresponding to the content of the event. If there is a match, the second entity 420 can determine that the event, along with any transactions associated with the event identified from the information retrieved from the blockchain 430, is valid. These operations can be performed, for example, by a smart contract executed by a processor of the second entity 420.

[0092] Figure 5 A flowchart 500 illustrating an example method of managing information in a decentralized database, such as a blockchain, according to example embodiments is shown. With reference to Figure 5 , the method 500 can include, at 510, receiving event data from an entity. The content of the event data can include various types of information indicative of an event to be generated and recorded in a blockchain. The entity can be a client application of a node of the blockchain, a node in the blockchain, another blockchain entity, or an entity outside of the blockchain network but in communication with one or more entities of the network.

[0093] At 520, it is determined whether the event data satisfies an endorsement policy. The endorsement policy can include one or more requirements or conditions described herein. In one embodiment, the endorsement policy can require that the content of the event data corresponds to one or more of an object or a namespace of the blockchain managed by the blockchain. In a billing application, for example, the object can be a particular bill, and the event data can be indicative of a transaction related to the bill. For example, the event data can be indicative of a change in status with respect to the bill having occurred, such as a change from "unpaid" to "fully paid." The namespace may, for example, correspond to a company or service that issues the bill and / or a customer that provides services or goods related to the bill.

[0094] At 530, an identifier corresponding to a context of the event data is set. The context of the event data can be or include, for example, the object or namespace indicated previously. In one embodiment, the identifier can include any type of key information described herein. For example, the context of the event data can include a tuple including all or any two or more of a channel name, namespace, collection, or key name corresponding to the database. The key information may, for example, be pre-set to correspond to the object or namespace. Thus, the association of the key information with the event and / or one or more associated transactions can be used to automatically verify that the event is correct.

[0095] At 540, once the endorsement policy and the set of identifiers have been satisfied, the method can include generating an event for submission to the blockchain network. The generated event can include, for example, a plurality of fields. A field can include information obtained from the event data that indicates a state, object, namespace, or context managed by the database. Another field can include an identifier, such as key information predetermined for the object, namespace, or other context.

[0096] At 550, the generated event can be submitted to the blockchain network. This can involve submitting the event for consensus and topic recordation in a new block in the blockchain. In one embodiment, this can include providing a notification of the event to a peer node in the blockchain network regardless of whether the event is recorded in the blockchain.

[0097] At 560, the blockchain can be queried to retrieve the event, and validation of the content of the retrieved event can be confirmed by matching key information in the retrieved event with known key information that has been pre-authorized and linked to the object or namespace associated with the content of the event.

[0098] Figure 6A An example system 600 is shown that includes physical infrastructure 610 configured to perform various operations according to example embodiments. Referring to Figure 6A , the physical infrastructure 610 includes modules 612 and modules 614. The modules 614 include a blockchain 620 and a smart contract 630 (which can reside on the blockchain 620), which 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 depicted embodiments and can represent output or write information written to or read from one or more 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.

[0099] Figure 6B Another example system 640 is shown that is configured to perform various operations according to example embodiments. Referring to Figure 6BThe system 640 includes modules 612 and 614. The modules 614 include the blockchain 620 and the smart contract 630 (which can reside on the blockchain 620), which 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 depicted embodiments and can represent output or write information written to or read from one or more smart contracts 630 and / or the blockchain 620. The modules 612 and 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the modules 612 and 614 can be the same module.

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

[0101] Figure 6D A system 660 including a blockchain is shown according to example embodiments. Reference is made to Figure 6D In the example of FIG. 6B, an application programming interface (API) gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, the API gateway 662 is a public interface for performing transactions (invocations, queries, etc.) on the 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 endorsing peers will run the smart contract 630 according to the smart contract 630 and endorsement policies.

[0102] The above embodiments can be implemented in hardware, computer program executed by a processor, firmware, or a combination thereof. Computer programs can be implemented on a computer readable medium such as a storage medium. For example, a 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.

[0103] An 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.

[0104] Figure 7A A process 700 showing a new block being added to a distributed ledger 720 according to an example embodiment, Figure 7B The contents of a new data block structure 730 for a blockchain according to an example embodiment are shown. Referring to Figure 7A A client (not shown) can submit transactions to the blockchain nodes 711, 712, and / or 713. The client can be an application acting on behalf of a requestor (such as a device, person, or entity) to formulate activity on the blockchain 720. As an example, the client can be an application acting on behalf of a requestor to propose a transaction for the blockchain. 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 peers that endorse and endorse transactions proposed by the client and peers that commit validated endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 can perform the role of an endorser node, a committer node, or both.

[0105] 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 a distributed ledger 720 for each 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 log of transactions structured as a chain of blocks, where each block contains a sequence of N transactions. A block can include various components as shown in FIG. 1. The chain of blocks (denoted by Figure 7B 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 a distributed ledger 720 for each 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 log of transactions structured as a chain of blocks, where each block contains a sequence of N transactions. A block can include various components as shown in FIG. 1. The chain of blocks (denoted byFigure 7A The hash of the header of the previous block can be generated by adding the hash of the header of the previous block 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 chain. Furthermore, because of the chain, 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 append-only blockchain workloads.

[0106] The current state of the blockchain 722 and distributed ledger 722 can be stored in a 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. Chain 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 into 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.

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

[0108] 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 service that is separate from the peer nodes 712. Figure 7A In the example of FIG. 7, the blockchain node 712 is a committing peer that has received a new data block 730 for storage on the blockchain 720. The first block in the blockchain can be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

[0109] 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 designate the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network can be designed such that the specific implementation of the "ordering" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0110] Transactions are written to the distributed ledger 720 in consensus order. The order of transactions is established to ensure that updates to the state database 724 are valid when they are committed to the network. Unlike a cryptocurrency blockchain system in which ordering occurs through the solving of cryptographic puzzles or mining (e.g., Bitcoin, etc.), in this example, the parties to the distributed ledger 720 can select an ordering mechanism that best suits the network.

[0111] When the ordering service 710 initializes a new data block 730, the new data block 730 can be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transactions within the new data block 730 by checking to ensure that the read set and the write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transactions is the same as the current world state in the state database 724. When the committing peer validates the transactions, the transactions are written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If the transactions fail, i.e., if the committing peer finds that the read-write set does not match the current world state in the state database 724, the transactions ordered 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.

[0112] Reference Figure 7B The new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 can include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that the different depicted blocks and their contents, such as the new data block 730 and its contents, are examples only and are not meant to limit the scope of example embodiments. Figure 7B The new data block 730 can store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750. The new data block 730 can also include a reference to a previous block (e.g., block 720) within the block header 740. The block header 740 can also include a block number, a block timestamp, and a block hash. Figure 7AThe block header 740 can include a hash of the header of the previous block. The block header 740 can also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block numbers of the new data blocks 730 can be unique and assigned in a different order, such as an incremental / sequential order starting from zero.

[0113] The block data 750 can store transaction information for each transaction recorded within the new data block 730. For example, the transaction data can include one or more of 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 (deploy tx), a chaincode name, a chaincode version, inputs (chaincode and function), a client (creator) identity (such as a public key and 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.

[0114] In some embodiments, the block data 750 can also store new data 762 that adds additional information to the chain of the chain of hashes of the blocks in the blockchain 722. The additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. As such, the new data 762 can be stored in the immutable block log on the distributed ledger 720. Some benefits of storing such new data 762 are reflected in the different embodiments disclosed and depicted herein. While the new data 762 is depicted in the block data 750 in Figure 7B In some embodiments, the block data 750 can also store new data 762 that adds additional information to the chain of the chain of hashes of the blocks in the blockchain 722. The additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. As such, the new data 762 can be stored in the immutable block log on the distributed ledger 720. Some benefits of storing such new data 762 are reflected in the different embodiments disclosed and depicted herein. While the new data 762 is depicted in the block data 750 in

[0115] The 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 the block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, a last offset of a retention of a sequencing service that ordered the block, etc. The signature, last configuration block, and sequencer metadata can be added by the sequencing service 710. Meanwhile, the submitter of the block (such as the 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 a verification code that identifies whether a transaction is valid / invalid.

[0116] Figure 7CEmbodiments of a blockchain 770 for digital content are shown in accordance with embodiments described herein. 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 acts as a safeguard to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where rules of admissibility apply, or in other settings where evidence is considered or where the presentation and use of digital information is otherwise of interest. In this case, the digital content can be referred to as digital evidence.

[0117] 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 (e.g., header, value, etc.) of reference information along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be illustrated as follows:

[0118]

[0119] In one embodiment, the digital content can not be included in the blockchain. For example, the blockchain can store an encrypted hash of the contents 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 value stored in the storage area corresponding to that actual digital content. This operation can be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0120]

[0121] In Figure 7C example embodiments, the blockchain 770 includes a plurality of blocks 7781, 7782,..., 778 N where N > 1. The encryption used to link the blocks 7781, 7782,..., 778 N may be any of a plurality of key encryption or keyless encryption hash functions. In one embodiment, the blocks 7781, 7782,..., 778 Nundergoes a hash function that produces an n-bit alphanumeric output from an input based on the information in the block (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, time-based algorithms, and collision-resistant PRF algorithms. In another embodiment, the blocks 7781, 7782,..., 778 N The links can be encrypted by a function other than a hash function. For purposes of illustration, a hash function (e.g., SHA-2) is referenced for the following description.

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

[0123] The first block 7781 in the blockchain is referred to as the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme for the genesis block and, in fact, all subsequent blocks can vary. For example, all of the information in the first block 7781 can be hashed together and hashed once, or each or a portion of the information in the first block 7781 can be hashed separately, and then a hash of the separately hashed portions can be performed.

[0124] 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 to 778 N In the genesis block, the header 7721 does not reference a previous block simply because there is no previous block.

[0125] The original file 7741 in the genesis block can be, for example, data captured by a device with or without processing prior to being included in the blockchain. The original file 7741 is received from a device, a media source, or a 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, a device, and / or a system processor, for example. The metadata can be included in the first block 7781 associated with the original file 7741.

[0126] 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:

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

[0128] 2) Originating device ID

[0129] 3) Start timestamp of the original file

[0130] 4) Initial storage location of the original file

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

[0132] The other blocks 7782 through 778 N also have a header, a file, and a value. However, unlike the first block 7721, the header 7722 through 772 N in the other blocks each includes a hash value of the immediately preceding block. The hash value of the previous block can be just the hash of the header of the previous block or can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, tracking back from the Nth block to the genesis block (and the associated original file) on a block-by-block basis can be performed, as indicated by arrow 780, to establish an auditable and immutable chain of custody.

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

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

[0135] Additionally or alternatively, the processing can involve copying the file from a prior block only, changing the storage location of the file, analyzing the file from one or more prior 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 from 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.

[0136] Other blocks in other blocks 7762 to 776 N The value in each of the other blocks 7762 to 776 i The value in each of the other blocks 7762 to 776

[0137] For example, consider a case where a portion of the file in a prior block is edited, blocked out, or pixelated so as 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 when the edit occurred, etc. The metadata can be hashed to form the value. Because the metadata of the block is different from the information hashed to form the value in the prior block, the values are different from one another and can be recovered upon decryption.

[0138] In one embodiment, the value of a prior block can be updated (e.g., a new hash value computed) to form the value of a 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.

[0139] 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);

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

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

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

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

[0144] 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, properties, parameters, etc.), for example. All blocks reference the hash of the previous block, of course, except the genesis block. The hash of the previous block can be just the hash of the header in the previous block or the hash of all or part of the information in the previous block (including files and metadata).

[0145] file 774 i includes a plurality of data, such as data 1, data 2,..., data N in order. The data is tagged with metadata metadata 1, metadata 2,..., metadata N describing content and / or properties associated with the data. For example, the metadata for each data can include a timestamp indicating the data, processing data, keywords indicating a person or other content depicted in the data, and / or other features that can contribute to establishing the validity and content of the file as a whole and, in particular, its use of digital evidence, for example, as described in connection with embodiments discussed below. In addition to the metadata, each data can be tagged with a reference REF 1, REF 2,..., REF N to the previous data to prevent tampering, gaps in the file, and sequential references through the file.

[0146] Once the metadata is assigned to the data (e.g., by a smart contract), the metadata cannot be changed without a hash change, which can be easily identified for invalidity. Thus, the metadata creates a data record of information that can be accessed for use by participants in the blockchain.

[0147] value 776 i is a hash value or other value computed 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, an identifier, or other action or information to be added. Although the value in each block is shown as 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 that metadata.

[0148] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody of the file can be obtained by querying the blockchain for the transaction history of the values across the blocks. This query or tracking process can begin with decrypting the values of the most current included block (e.g., the last (Nth) block) and then continue decrypting the values of the other blocks until the genesis block is reached and the original file is recovered. The decryption can also include decrypting the header and file and associated metadata at each block.

[0149] The 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, e.g., an IP address or home address, for receiving 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 using the sender’s public key. In this way, the recipient can be sure that only the sender could have sent the message.

[0150] Producing a key pair can be similar to creating an account on the blockchain, but does not necessarily have to be registered anywhere in fact. Moreover, each transaction performed on the 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.

[0151] Figure 8A and Figure 8B Further examples of use cases in which the blockchain that can be incorporated and used in this document are shown. In particular, 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 in order to make accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to mine non-obvious patterns.

[0152] 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 boat, 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.

[0153] The blockchain 810 can be used to significantly improve both the training process 802 of a machine learning model and the prediction process 804 based on the trained machine learning model. 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 assets 830 themselves (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 820 in performing the prediction model training. For example, using a smart contract, data can be transferred directly and reliably from its originating 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 using the data to establish the machine learning model. This allows for the sharing of data between assets 830.

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

[0155] Furthermore, the training of the machine learning model on the collected data can take the form of rounds of refinement and testing by the host platform 820. Each round can be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. 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 refinement 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. Furthermore, when the host platform 820 has achieved a final trained model, the resulting model can be stored on the blockchain 810.

[0156] After the model has been trained, it can be deployed to a live environment, where it 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 event predictions, 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 collapse / 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 depicted herein can occur on or with respect to the blockchain 810.

[0157] New transactions of the blockchain can be gathered together 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 all agree. Any computer that disagrees discards the record that caused the problem. This approach is good for ensuring the tamper resistance of the blockchain, but it is not perfect.

[0158] One way to game the system is for dishonest users to change the transaction list to their liking, but in a way that keeps the hash the same. This can be done by brute force, in other words, by changing the record, encrypting the result, and seeing if the hash value is the same. And if it is not, then repeatedly trying until it finds a matching hash. The security of the blockchain is based on the belief that ordinary computers can only perform this brute force attack on a completely impractical timescale, such as the age of the universe. In contrast, quantum computers are much faster (1000s of times faster) and thus pose a greater threat.

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

[0160] In Figure 8BIn the example of FIG. 8, there are four users 854, 856, 858, and 860. Each pair of users can share a secret key 862 (i.e., a QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, and thus six different secret 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 cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can determine each other’s identity.

[0161] 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 transactions are not yet confirmed.

[0162] 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 time period (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 transmit their private values to each other. In subsequent rounds, the nodes transmit the information they received from other nodes in the previous round. Here, 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 depicted herein can occur on or with respect to the blockchain 852.

[0163] Figure 9An example system 900 that supports one or more 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.

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

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

[0166] 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 limiting, 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.

[0167] 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 be used for reading from, and writing to, a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be used 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.

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

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

[0170] The computer system / server 902 can also communicate with one or more external devices 920 such as a keyboard or a pointing device, e.g., a mouse, a scanner, or a networking device via an I / O interface(s) 924. Further, 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 network adapter 926. As depicted, network adapter 926 communicates with the other components of the computer system / server 902 via a bus. It should be understood that although not shown, other hardware and / or software components could be used in conjunction with the computer system / server 902. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0171] While example embodiments of at least one of a system, method, and non-transitory computer-readable medium have been illustrated and described in the drawings and detailed description above, it will be understood that the application is not limited to the embodiments disclosed, but instead has many rearrangements, modifications, and substitutes within its scope as set forth and defined by the following claims. For example, the capabilities of the systems of the different figures can be performed by one or more modules or components described herein or in the distributed architecture, and can include a transmitter, receiver, or both. For example, all or a portion of the functions performed by separate modules can be performed by one or more of those modules. Further, the functions performed by the modules can be performed at different times and in different orders. Furthermore, messages sent from or to the modules can be sent directly and / or via one or more other modules. Moreover, the messages sent or received by any of the modules can be transmitted or received by the module directly and / or via one or more other modules.

[0172] Those skilled in the art will appreciate that a "system" can embody a personal computer, a server, a console, a personal digital assistant (PDA), a cellular telephone, a tablet computing device, a 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 meant to provide one example of a number of embodiments. Indeed, the methods, systems, and devices disclosed herein can be implemented in local and distributed form consistent with computing technology.

[0173] According to one or more of the preceding embodiments, there are provided improved systems, methods, and computer-readable media representing the management of information storage in a decentralized database, and more particularly to managing transaction and other event data for a decentralized database, including but not limited to a blockchain.

[0174] In one embodiment, one or more of the embodiments herein address the problem by preventing valid but misleadingly formed transactions from being inserted into the system by zantine clients, which appear to issue events corresponding to a particular operation but do not perform the operation. In a traditional database, transactions can be safely filtered at the entry by any participant, as there is an assumption of trust in any validating node. In contrast, according to one or more embodiments, these one or more embodiments cannot operate under a traditional database because different participants can have different authorities and / or different countries requiring different endorsements to modify them.

[0175] In addition, one or more embodiments described herein improve the security of client applications by eliminating an attack surface (fake events on otherwise valid transactions). Additionally, one or more embodiments can store and manage new types of data in a decentralized database. For example, new data can be stored within a transaction that encapsulates an event. This additional data can be used by a transaction validation component to perform more validation checks than are required to validate the transaction. This additional data is then consumed by a client, which is now able to safely process the event because if the transaction is marked as valid, the client knows that these

[0176] Additional security checks are made.

[0177] 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

[0178] Modules can also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions. These modules may, for instance, be organized as an object, procedure, or function. However, the executables of an identified module need not be physically located together, but can comprise disparate instructions stored in different locations which, 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, flash device, random access memory (RAM), tape, or any other such medium used to store data.

[0179] Indeed, a module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, in 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.

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

[0181] As will be readily appreciated by one of ordinary skill in the art, in view of the foregoing discussion, methodologies presented for a particular application can be implemented by, applied to, and / or performed by a number of different hardware configurations. While the preferred embodiments of the application have been described above, it will be recognized and understood that certain modifications, changes and substitutions are intended to be included within the scope of the application, which is limited only by the scope of the appended claims.

[0182] While the preferred embodiments of the application have been described above, it is to be understood that they have been presented by way of example only, and that modifications, changes and substitutes are intended to be included within the scope of the application, which is limited only by the scope of the appended claims.

Claims

1. A node in a blockchain network, the node comprising: a processor configured to, when executing one or more instructions stored in an associated memory: receive data from another node in the blockchain network, the data identifying a context of an object managed by a blockchain of the blockchain network; validate the data based on an endorsement policy; receive an identifier of the object; generate an event, the event comprising a first field of data associated with the event, a second field specific to validating the event, and a third field containing information associated with a transaction associated with the event; perform a pseudo-write operation to store only the identifier in the second field, wherein the identifier links the event to the object; automatically validate the event without querying other peers in the blockchain network based on a pre-authorization of the identifier assigned to the object by an authority of the blockchain network; and submit the event to the blockchain for consensus processing.

2. The node of claim 1, wherein the identifier comprises key information previously validated for the object.

3. The node of claim 2, wherein the key information links the event to an authority that validates the event based on the key information.

4. The node of claim 1, wherein the context comprises a tuple comprising at least two of: a channel name, a namespace, a collection, or a key name corresponding to the blockchain.

5. The node of claim 1, wherein a presence of key information in the identifier causes a second node in the blockchain network to automatically validate the event based on the presence of the key information without checking ledgers of other nodes in the blockchain network.

6. The node of claim 1, wherein the data has a format comprising a plurality of data fields, and wherein when the processor is configured to generate the event, the processor is further configured to: add a new data field to the format that stores key information.

7. The node of claim 1, wherein the data indicates a change in a state of the object.

8. A method for a blockchain network, comprising: receiving, by a node in the blockchain network, data from another node in the blockchain network, the data identifying a context of an object managed by a blockchain in the blockchain network; validating, by the node, the data based on an endorsement policy; receiving, by the node, an identifier of the object; generating, by the node, an event, the event comprising a first field of data associated with the event, a second field specific to validating the event, and a third field containing information associated with a transaction associated with the event; performing, by the node, a pseudo-write operation to store only the identifier in the second field, wherein the identifier links the event to the object; automatically validating, by the node, the event without querying other peers in the blockchain network based on a pre-authorization of the identifier assigned to the object by an authority of the blockchain network; and submitting, by the node, the event to the blockchain for consensus processing. ​ submitting, by the node, the event to the blockchain for consensus processing.

9. The method of claim 8, wherein the identifier comprises key information previously validated for the object.

10. The method of claim 9, wherein the key information links the event to a validation authority that validates the event based on the key information.

11. The method of claim 8, wherein the context comprises a tuple comprising at least two of: a channel name, a namespace, a collection, or a key name corresponding to the blockchain.

12. The method of claim 8, wherein presence of key information in the identifier causes a second node in the blockchain network to automatically validate the event based on the presence of the key information without checking ledgers of other nodes in the blockchain network.

13. The method of claim 8, wherein the data has a format comprising a plurality of data fields, and wherein generating the event further comprises: adding a new data field to the format that stores key information.

14. The method of claim 8, wherein the data indicates a change in a state of the object.

15. A non-transitory computer-readable medium storing one or more instructions that, when executed by a processor of a node in a blockchain network, configure the processor to: receive data from another node in the blockchain network, the data identifying a context of an object managed by a blockchain of the blockchain network; validate the data based on an endorsement policy; receive an identifier of the object; generate an event, the event comprising a first field of data associated with the event, a second field dedicated to validating the event, and a third field containing information associated with a transaction associated with the event; perform a pseudo-write operation to store only the identifier in the second field, wherein the identifier links the event to the object; automatically validate the event without querying other peer nodes in the blockchain network based on pre-authorization of the identifier assigned to the object by an authorizing authority of the blockchain network; and submit the event to the blockchain for consensus processing. the identifier comprises key information previously validated for the object.

16. The medium of claim 15, wherein, 17. The medium of claim 16, wherein the key information links the event to a validation authority that validates the event based on the key information.

18. The medium of claim 15, wherein the context comprises a tuple comprising at least two of: a channel name, a namespace, a collection, or a key name corresponding to the blockchain. when the processor is configured to generate the event, the one or more instructions further configure the processor, the processor being further configured to:

19. The medium of claim 15, wherein the data has a format comprising a plurality of data fields, and wherein, add a new data field to the format that stores key information. ​ 20. The medium of claim 15, wherein the presence of key information in the identifier causes a second node in the blockchain network to automatically validate the event based on the presence of the key information without having to check ledgers of other nodes in the blockchain network.

Images