Authorized event processing in a distributed database.

Abstract

Exemplary operations include one or more of receiving event data from an entity, determining that the event data satisfies a signature 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 to a distributed database, wherein the identifier is used to validate that a state corresponding to the context in the event data is correct.

Description

[Background technology]

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

[0002] One example embodiment provides a system including one or more of a receiver for receiving event data from an entity, a storage area for storing a chaincode of a smart contract, and a processor for executing the smart contract, wherein the smart contract performs one or more of determining that the event data satisfies a signature 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, and validating that a state in which the identifier corresponds to the context in the event data is correct.

[0003] Another example embodiment provides a method that includes one or more of receiving event data from an entity, determining that the event data satisfies a signature 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 validate that a state corresponding to the context in the event data is correct.

[0004] A further example embodiment provides a non-transitory computer readable medium including instructions that, when read by a processor, cause the processor to perform one or more of: receiving event data from an entity, determining that the event data satisfies a signature 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, and validating that the identifier is correct for a state corresponding to the context in the event data. [Brief description of the drawings]

[0005] [Figure 1A] 1 is a network diagram illustrating a system including a database according to an example embodiment. [Figure 1B] FIG. 2 is another network diagram illustrating components operating with a database in accordance with an example embodiment. [Figure 1C] FIG. 4 is a further network diagram illustrating components operating with a database in accordance with an example embodiment. [Figure 2A] FIG. 1 illustrates an exemplary blockchain architecture configuration, according to an example embodiment. [Figure 2B] FIG. 1 illustrates a blockchain transaction flow according to an example embodiment. [Figure 3A]FIG. 1 illustrates a permissioned network, according to an example embodiment. [Figure 3B] FIG. 2 illustrates another permissioned network, according to an example embodiment. [Figure 3C] FIG. 2 illustrates a permission-free network, according to an example embodiment. [Figure 4] FIG. 2 illustrates a system message diagram according to an example embodiment. [Diagram 5] FIG. 1 illustrates a flow diagram in accordance with an example embodiment. [Figure 6A] FIG. 1 illustrates an example system configured to perform one or more operations described herein, in accordance with an example embodiment. [Figure 6B] FIG. 1 illustrates another exemplary system configured to perform one or more operations described herein, in accordance with example embodiments. [Figure 6C] FIG. 1 illustrates yet another exemplary system configured to utilize smart contracts in accordance with an example embodiment. [Figure 6D] FIG. 1 illustrates yet another exemplary system configured to utilize blockchain, according to an example embodiment. [Figure 7A] FIG. 1 illustrates a process for a new block being added to a distributed ledger according to an example embodiment. [Figure 7B] 11A-11C are diagrams illustrating the data contents of a new data block according to an example embodiment. [Figure 7C] FIG. 1 illustrates a block chain for digital content, according to an example embodiment. [Figure 7D] FIG. 2 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment. [Figure 8A] FIG. 1 illustrates an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 8B] FIG. 1 illustrates an exemplary quantum secure blockchain, according to an example embodiment. [Figure 9] FIG. 1 illustrates an exemplary system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0007] Features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrase "example embodiment," "some embodiments," or other similar language throughout this specification refers to the fact that certain features, structures, or characteristics described in connection with an embodiment may be included in at least one embodiment. Thus, the appearances of the phrase "example embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Additionally, in each figure, any connection between elements may permit one-way or two-way communication, or both, even if the connection shown is a one-way or two-way arrow. Also, any devices shown in the figures may be different devices. For example, where a mobile device is shown transmitting information, a wired device may also be used to transmit the information.

[0008] In addition, although the term "message" is sometimes used in describing the embodiments, other types of network data may be used, such as packets, frames, datagrams, etc. Furthermore, although particular types of messages and signaling may be illustrated in the example embodiments, the messages and signaling are not limited to the particular types of messages and signaling.

[0009] In one embodiment, the present application utilizes a distributed database (such as a blockchain), which is a distributed storage system that includes multiple nodes that communicate with each other. A distributed database includes an append-only immutable data structure, similar to a distributed ledger, in which records can be maintained among mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching consensus among the distributed peers. For example, peers may run a consensus protocol to verify the validity of blockchain stored transactions, group those stored transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering the stored transactions, as necessary, for consistency. In various embodiments, permissioned or permissionless blockchains or both may be used. Public or permissionless blockchains allow anyone to participate without specific identification. Public blockchains include native cryptocurrencies and can use consensus based on various protocols, such as Proof of Work (PoW). Conversely, permissioned blockchain databases provide for secure interactions among a group of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, or information.

[0010] The present application may utilize a blockchain that operates on arbitrary programmable logic, called a "smart contract" or "chaincode," that is tailored to the distributed storage method. In some cases, there may be a specialized chaincode for managing functions and parameters, called a system chaincode. Applications may further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof properties of the blockchain database and the underlying agreement between nodes, called a signature or signature policy. Blockchain transactions associated with this application may be "signed" before being committed to the blockchain, while transactions that are not signed are ignored. The signature policy allows the chaincode to specify the signers of the transaction in the form of a set of peer nodes required for signing. When a client sends a transaction to a peer specified in the signature policy, a transaction is executed to verify the validity of the transaction. After validation, the transaction moves to an ordering phase, where a consensus protocol is used to generate an ordered sequence of signed transactions grouped into blocks.

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

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

[0013] The application may utilize a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is greater than or equal to 1. The block header contains a hash of the block's transactions, and a hash of the previous block's header. In this way, all transactions in the ledger may be ordered and cryptographically linked together. Thus, the ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added block of the blockchain represents all transactions on the chain that occurred before it, allowing all peer nodes to be assured that they are in a consistent and trustworthy state. The chain may be stored in the file systems of the peer nodes (i.e., locally, attached storage, cloud, etc.), which efficiently supports the append-only nature of blockchain workloads.

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

[0015] An event is a type of message sent in blockchain networks and other types of distributed databases. Events may be created by validators using smart contract chaincodes when certain conditions are met. One type of event (often called a base event) may be created, for example, when a new block of transactions is committed to the blockchain. Other types of events may form part of the chaincode or indicate the state of the chaincode. For example, a customer event may relate to a particular message designated by the chaincode for distribution to entities within or outside the network (e.g., nodes, users, clients, etc.). For example, the level of confidentiality, access privileges, or restrictions of events in the network, as determined by the validators and / or network policies, rarely changes. Different chaincodes may be used to manage the creation, distribution, and / or access of events with different state levels.

[0016] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that generate events and validate the events before the events are stored in a distributed database, such as, but not limited to, a blockchain. The generation and validation of the events is performed in a manner that improves the functionality of a computer in managing blockchain information and assets. In one embodiment, the improvement is achieved by the addition of new information stored in association with the event that ties the event (and, for example, one or more associated transactions) to an object and / or namespace managed by the database. This new information may be key information, such as, but not limited to, a key name or key address.

[0017] Validation of an event along with associated transactions may be performed in a relatively time- and processing-efficient manner, either prior to committing the event to a database by performing an action based on the new information, or in conjunction with a database query related to the event, or both. In one embodiment, key information is pre-validated with respect to the object or event. Thus, including key information recorded in a blockchain or other database along with the event (and, e.g., one or more accompanying transactions) helps to automatically validate the event (and transactions), if present within a field associated with the event. In one embodiment, such a field may be included or added to the event. In this or another embodiment, the transaction associated with the event may include a message format that also includes the field in addition to the event data. Thus, checking for the presence of valid key information (e.g., matching known key information) helps to validate the event and its accompanying transactions without needing to query other nodes' ledgers in the database to perform the validation.

[0018] In one embodiment, an operation is performed to associate the event with a pseudo-write in the state namespace. When defining an event, the event may include key information that establishes the validity of the event's creation. If the validity of the event and one or more associated transactions are validated, the event may be evaluated as a pseudo-write for that key information. Even if no state change is performed with respect to that key, the validation may ensure that the event and / or associated transactions are still valid even if a transaction has changed that key information. This has the advantage that consumers of the event (e.g., nodes and / or node clients) may consider the event to be valid at that time if and only if the event is associated with the expected key information. If the keys and their accesses are appropriately selected, the validity of the event implies the validity of one or more associated transactions.

[0019] In addition to the above, additional benefits of the solutions described and illustrated herein include assurance to a database client (e.g., a user in a billing management application) that an event and its associated transactions and other content are correct from a security perspective, provided that the event and its associated transactions / content are properly signed, and assuming that the signature policies are properly set (e.g., if the signature policies are incorrect, no assertions can be made regarding the correctness of any ledger key). Using the key information and associated operations provided by the embodiments described herein, if a database user (e.g., via a client application) wishes to attempt to verify the correctness of an event, the user need only use a query after receipt of the event to verify whether the event's conditions or other content are in fact true from a sufficient number of peer nodes.

[0020] 1A illustrates a logical diagram of 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. For illustrative purposes, the distributed database is described as a blockchain. However, in alternative embodiments, different types of databases may be used.

[0021] Referring to FIG. 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 may generate event data 115 that is transmitted to the node 120 via a communication link, which may include, for example, a wired network, or a wireless network, or other communication path. The event data may include any form of information, but may be particularly relevant to the intended application of the blockchain. In one non-limiting example, described in more detail below, the event data includes billing information regarding customers of one or more network entities. In this case, the network entities may belong to the same or different companies, for example. In one embodiment, the client 110 may encrypt the event data and / or one or more associated transactions before being delivered to the node 120. Corresponding decryption (e.g., key) information may be located at one or more other nodes or associated clients of the blockchain network and may be used to perform the decryption and access the generated events, for example, from a blockchain query. The node 120 may be one of multiple nodes of a distributed database. In one embodiment, node 120 may be a peer node that performs validation of events and / or transactions before committing them to the blockchain.

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

[0023] Figure 1B shows a series of transactions recorded on the blockchain over time. 1 ~170 N 1 illustrates an example of a logical relationship 150 between a client 110 and a customer 120. In this example, all transactions are associated with the same object or namespace 190. In a billing application, object 190 may correspond to the state of a customer's bill corresponding to event data received by node 120. In this case, client 110 may be a bank, a credit card company, a utility company, or another entity that issues bills for goods and / or services.

[0024] Referring to FIG. 1B, transaction 170 1 ~170N One or more of the event data items may be associated with a corresponding event generated by a processor of node 120 based on various items of event data received from client 110. In this example, event (E1) 180 1 However, the related transaction (T1) 170 1 Corresponding to event (E2) 180 2 However, the related transaction (T2) 170 2 , corresponding to, etc. Each event may indicate a state of an object (or its associated transaction). Although events are shown in FIG. 1B as distinct from transactions, in one embodiment, the events (or event data) may be included in an added or additional field of the transaction or event format. For example, in one embodiment shown in FIG. 1C, each transaction or event format 195 may have a message structure that includes a first field 196 containing information indicative of event data, a second field 197 containing event key information that may be used for improved validation according to one or more embodiments described herein, and a third field 198 containing transaction information.

[0025] One possible relationship between transactions and events may be understood according to the following example: If object 190 represents an invoice for customer X, then event (E1) 180 1 may indicate that an invoice has been generated for customer X. For example, related transaction (T1) 170 1 Event (E2) 180 may indicate the amount of the invoice. 2 may indicate different states of an invoice. For example, event E2 triggers transaction (T2) 170 which indicates that the first due date of the invoice has passed. 2 For example, event (EN) 180 may indicate a state that the invoice has not been paid. One or more subsequent transactions may reflect various additional state changes and related transactions.N may indicate that an invoice for customer X has been paid, and the associated transaction (TN) 170 N may indicate that a late fee has been added to the invoice. Thus, the blockchain ledger may record the transaction along with related events on the same object managed by the network.

[0026] In one embodiment, an object may be associated with a state namespace in a blockchain network. This namespace may be a partition of the state space with different validation rules than the global namespace of a smart contract, such as a collection of private data in Hyperledger Fabric. A namespace may be a single key with its own validation rules, such as a state-based signature in Hyperledger Fabric, or a token in other blockchain systems.

[0027] Returning to FIG. 1A, to prevent fraud and ensure the validity of information stored in the blockchain, the chaincode of the smart contract executed by the processor 122 may generate an event that includes an additional field used for validation (e.g., verifying that the event is correct or authentic and valid). This may be performed, for example, by the processor running the chaincode of the smart contract 124 to generate information (e.g., an identifier) ​​that is linked to the object. This identifier may be generated and pre-authorized by the network authority, for example, for use with the object (or namespace). Thus, the identifier may serve as the basis for validating the event simply by being linked to the event, thereby mitigating the need to query the ledger of peer nodes in the blockchain to determine that the content of the event (and its associated transaction) is correct. In the exemplary event or transaction format of FIG. 1C, the identifier may be included in the second field 197, which is a newly generated field reserved for event validation purposes.

[0028] After the identifier is set (e.g., set by accessing pre-stored information or obtained directly from a network authority), the processor 122 may insert the identifier into a second field used for validation. At least in this manner, the processor may be considered to perform a pseudo-write operation that involves pre-storing information into a dedicated field of the event (or transaction) that can be used to validate the event before the event is generated for agreement and commitment to the blockchain. The generation and insertion (or association) of the identifier in the event may improve the efficiency of the computer managing the blockchain, at least with respect to reducing processing overhead across peer nodes and the managing network entity.

[0029] In one embodiment, the information stored in the new second field of the event may be linked to the object with which the event is associated. For example, in one embodiment, the generated identifier pseudo-written into the second field of the event / transaction may include pre-generated key information for the particular object corresponding to the event. The event (and its associated transaction) may be validated by verifying that the key information is associated with the event since the key information has already been validated (e.g., by a network authority) for the object. This mitigates the need to query the ledger of blockchain nodes to verify the validity of the event and its associated transaction before committing the transaction to add a new block to the blockchain. Thus, the key information may serve to effectively tie the event to an authorization mechanism or validation authority programmed to perform validation or authorization based on the key information. In one embodiment, the key information may include a key name assigned to the object. In another embodiment, the key information may include a key address assigned to the object. In yet another embodiment, the processor may generate different types of identification information associated with the object for purposes of authorizing the generation of the event based on the event data received by the client 110. The key information may be encoded using one or more security features (eg, various forms of encryption) before being inserted into additional fields in the event or transaction format.

[0030] In one embodiment, the smart contract chaincode executed by the processor 122 may be programmed to generate key information for event authorization on a per-namespace basis, where each namespace may include multiple corresponding objects that may differ from objects corresponding to other namespaces, and each of those objects may include one or more corresponding transactions and / or events, depending, for example, on the intended application of the blockchain.

[0031] To generate key information for each namespace, node 120 (and indeed one or more other nodes in the blockchain network) may include namespace logic 126. Such logic may be part of a blockchain platform, such as, for example, but not limited to, the Hyperledger Sawtooth platform. Namespace logic 126 may be used by node 120 to allow the generation of events to separate between unrelated transactions (e.g., transactions unrelated to the same object). For example, node 120 may use a global state store and include namespace logic 126 that allows this store to be separated into different namespaces, each namespace corresponding to a separate category of objects. In one non-limiting example, each namespace may correspond to a different customer, and events corresponding to each namespace may correspond to invoices issued to those customers.

[0032] If node 120 includes namespace logic, different key information may be pre-generated for objects in each namespace. In one embodiment, the same key information may be generated for multiple objects corresponding to the same namespace. In either case, the key information may be pre-validated and authorized for use in connection with the event and / or transaction corresponding to the associated object. In this manner, event authorization may be performed by verifying that an event issued by node 120 for authorization and subsequent recording in the blockchain includes the appropriate corresponding key information assigned to the object to which the event corresponds. As a result, the inefficiency of querying a node's ledger in the blockchain to perform event authorization may be avoided, thereby improving the computational operations associated with managing the creation, authorization, agreement, and commitment of blockchain transaction events, as well as the subsequent operations associated with validating the transaction and its associated events when the blockchain is queried by the same or another node.

[0033] In accordance with the aforementioned features, node 120 may operate as follows in implementing one or more embodiments described herein: When event data is received from client 110, processor 122 publishes a new event by further setting a new (event validation) field in the event (or transaction format) containing key information corresponding to the object and / or namespace to which the object corresponds. As previously described, the published event may include information indicating a state in which the event corresponds to a transaction performing a pseudo-write. Validation code of the platform (e.g., included in a smart contract chaincode) checks the key information in the new (event validation) field when validating one or more corresponding transactions.

[0034] In some cases, the transaction associated with the published event may have modified the key information, but storing the key information in a new field nevertheless ensures that even if the transaction has been modified, the key information referenced by, for example, node 120 or platform validation code is still considered valid (in addition to any modifications that the transaction may actually be making).

[0035] A client application (e.g., corresponding to client 110, another client of node 120, or a client of another node in the blockchain network) may then perform a query to retrieve a transaction event from a block in the blockchain, and the client application may verify the validity (or correctness) of the transaction event by performing a comparison based on the key information stored in the event validation field of the transaction event. For example, because the client application can obtain or has recorded the key information for a particular object (and / or namespace) associated with the retrieved transaction event, the client application may compare the key information stored in the field of the retrieved transaction event with known key information for that object (or namespace). If a match exists, the client application may determine that the transaction event is valid without needing to query the ledgers of other nodes in the blockchain network. If a match does not exist, the client application may determine that the transaction event that it recorded in the blockchain is fraudulent (e.g., by a malicious attacker) or has otherwise been compromised.

[0036] An exemplary context for these embodiments is a billing application. For example, if a smart contract executed by processor 122 of node 120 issues an event indicating a state that a particular invoice (object) of a customer is fully paid, the event can be extended with an additional field referencing key information referencing the invoice. In this case, the "fully paid invoice" event can be considered valid only if the associated transaction (e.g., the transfer of funds to pay the invoice) was authorized by the customer and / or other parties (e.g., credit card companies) that have the authority to change the state of the invoice event. The validity of the event state can be verified based on the key information stored in the additional field of the event (or transaction message format).

[0037] In some cases, in the exemplary situation described above, the transaction itself may cause key information to be changed. For example, updating an invoice event's state from "unpaid" to "fully paid" may cause a large number of key changes, not all of which are easy to predict or require an equivalent signature in order for the invoice to be authorized for payment. However, some of these keys, such as the key representing the invoice's paid state, must be changed in a valid transaction and therefore must be signed by an entity authorized to modify the invoice. A client application retrieving information from the blockchain seeking to verify a full payment by binding the event to key information may only need to determine a subset of the state machinery of the smart contract of the node 120 that created the event. This may have the beneficial effect of maintaining the confidentiality and security of customer information while at the same time allowing the client application to obtain the information it requested to verify the validity of the invoice payment.

[0038] Without the key information, the client application would be required to operate in an insecure manner (without performing any validation of the event) or, at least, would be required to perform time- and processing-inefficient operations to validate the event, both before committing it to the blockchain and during subsequent validation after the client application queries the blockchain. For example, the client would be required to make a round-trip query of the ledger state to ensure that the event was generated properly. Furthermore, without the use of the event-to-key binding technique of the embodiments described herein, an attacker who has not paid a bill could issue a valid transaction (e.g., paying a possibly unrelated, smaller amount bill) but with an attached event indicating that a different, larger amount bill was paid. When the application receives an event, it can either (a) inspect the state change of the transaction and try to verify that the state change corresponds to the contents of the event (this technique is fragile and prone to error), (b) immediately go back to the ledger and ask what the state of the bill was and verify that the contents of the event are correct (this is expensive and prone to error), or (c) accept the event at face value and be open to attack. By introducing the event binding technique of the embodiment, a client application can select technique (c) and remain secure, with additional validity checks being performed, for example, based on matching key information in new event fields.

[0039] FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. With reference to FIG. 2A, the blockchain architecture 200 may include certain blockchain elements (e.g., a group of blockchain nodes 202). The blockchain nodes 202 may include one or more nodes 204-210 (four of these nodes are shown merely by way of example). These nodes participate in a number of activities, such as adding and validating blockchain transactions (agreements). One or more of the blockchain nodes 204-210 may sign transactions based on a signature policy and provide an ordering service for all blockchain nodes in the architecture 200. A blockchain node may initiate a blockchain authentication and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 216, and a copy of this write may also be stored in the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to application programming interfaces (APIs) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations required by participants, maintain their own state, control their own assets, and receive external information. A blockchain configuration can be installed on all blockchain nodes 204-210, for example, by deploying it as a transaction and adding it to the distributed ledger.

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

[0041] The blockchain architecture of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control assets of the blockchain. For example, the code 220 may store and transfer data and may be executed by the nodes 204-210 in the form of associated chaincode including smart contracts and conditions or other code elements subject to execution. As a non-limiting example, smart contracts may be created to perform reminders, updates, or changes, other notifications subject to updates, or combinations thereof. The smart contracts themselves may be used to identify authorization and access requirements and rules associated with use of the ledger. For example, the information 226 may include event data received from client applications, nodes, or other network entities. The event data may be used by the receiving node as a basis for generating and validating events. The generation and validation of events may be performed using logic that may include chaincode of smart contracts implemented by the receiving node. The chaincode may, for example, be included in the application 224 or may be separate from the application 224. The smart contract and / or the application 224 may be executed by one or more processing entities (e.g., virtual machines in one case) included in the blockchain layer 216.

[0042] Among other operations, the smart contract chaincode may, for example, generate and validate an event based on an existing signature policy in the database network. In one embodiment, the smart contract may determine the database object (e.g., invoice) and / or namespace associated with the received event data. The node may then sign and validate the event (and accompanying transaction) based on the conditions of the signature policy. If the conditions are signature and validation is met (which validation may vary, for example, depending on the content of the event data and / or the intended application of the database), the node digitally signs the event and allows the event to be published across the network, including, for example, the event being committed to the blockchain.

[0043] In one embodiment, the signature may assume that the event data is associated with an object or a default namespace managed by the database network. For example, a smart contract in a node receiving the event data may check the contents of the data against known objects and / or namespaces managed by the network. If there is a match, the smart contract may 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 with the event ensures that the contents of the event (e.g., including any state changes or transaction associations with the event) are correct and valid.

[0044] The result 228 may include the now signed and validated event along with a new field containing the key information generated by the smart contract. The event may be an output with or without one or more associated transactions. The event (and associated transactions) may be output to the blockchain network for consensus and subsequent commit to a new block in the blockchain. In one embodiment, the event may be sent as a notification to other nodes in the blockchain network. Once committed to the blockchain, a client application in communication with the node (e.g., peer nodes 204, 206, 208, 210, etc.) may query the blockchain regarding the event. Thus, the key information included in the new field may help automatically validate that the content of the event and associated transactions are correct. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

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

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

[0047] The chaincode may include a code interpretation of the smart contract along with additional functionality. As described herein, the chaincode may be program code deployed on a computing network and executed together and validated by chain validators during a consensus process. The chaincode receives the hash and retrieves the hash from the blockchain associated with a previously stored feature or data template created by use of a context extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with the cryptographic details to the blockchain.

[0048] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. With reference to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to a signing peer node 281. The signing peer 281 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of versions of the keys / values ​​read into the chaincode (the read set), and a set of keys / values ​​written into the chaincode (the write set). A proposal response 292 is sent back to the client 260, along with the signature if approved. The client 260 packages the signature into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block on a channel to all peers 281-283. Each peer 281-283 may verify the validity of the transaction before committing it to the blockchain. For example, a peer may check the signature policy to ensure that the correct allocation of the specified peer has signed the result and authenticated the signature on the transaction payload 293.

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

[0050] In response, the signing peer node 281 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in the example, client 260) has been given the proper permissions to perform the proposed operation on that channel. The signing peer node 281 may take the transaction proposal input as an argument to a chaincode function that is called. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set; however, no updates are made to the ledger at this point. At 292, the set of values, along with the signing peer node's 281 signature, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for use by the application.

[0051] In response, the client 260 application checks / verifies the signing peer's signature and compares the proposal response to determine if the proposal response is the same. If the chaincode simply queried the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application is going to submit a transaction to the ordering node service 284 to update the ledger, the application determines if the specified signature policy is satisfied (i.e., if all required peer nodes for the transaction have signed the transaction) before submitting. Here, the client may include only one of multiple parties of the transaction. In this case, each client may include its own signing node, and each signing node must sign the transaction. The architecture ensures that the signature policy is still enforced by the peers and maintained in the commit validation phase, even if the application chooses not to check the response or otherwise forwards an unsigned transaction.

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

[0053] The block of transactions is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 in the block are validated to ensure that any signature policies are satisfied and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the execution of the transaction. The transactions in the block are tagged as being valid or invalid. Further, in step 295, each peer node 281-283 adds the block to the channel's chain and, for each valid transaction, the write set is committed to the current state database. Events are published to inform the client application that the transaction (invocation) has been immutably added to the chain and to inform whether the transaction has been validated or invalidated.

[0054] FIG. 3A illustrates an example of a permissioned blockchain network 300, which features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction to a permissioned blockchain 304. In this example, the transaction may be a deploy, invoke, or query, and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as “auditors” and blockchain users 302 as “clients.” Auditors may be limited to only querying the ledger, while clients may be given permission to deploy, invoke, and query certain types of chaincode.

[0055] A blockchain developer 310 can write chaincode and client-side applications. Through an interface, the blockchain developer 310 can deploy the chaincode directly to the network. To include authentication information from traditional data sources 312 in the chaincode, the developer 310 can use an out-of-band connection to access the data. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before initiating any transactions, the peer node 314 obtains a certificate of the user's registration and transaction from a certificate authority 316 that manages the user's roles and permissions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 304. On the other hand, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 312. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0056] FIG. 3B illustrates another example of a permissioned blockchain network 320, which features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 322 may submit a transaction to the permissioned blockchain 324. In this example, the transaction may be a deploy, invoke, or query, and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as “auditors” and blockchain users 322 as “clients.” Auditors may be limited to only querying the ledger, while clients may be given permission to deploy, invoke, and query certain types of chaincode.

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

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

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

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

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

[0062] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates a proof of work, thereby guaranteeing a correct answer. In other words, a possible solution must prove that computational resources were expended in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

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

[0064] 4 illustrates a system message diagram 400 for generating and validating events according to an example embodiment. With reference to FIG. 4, the system diagram 400 includes a first entity 410, a second entity 420, and a blockchain 430. The first entity 410 may be a first node of a blockchain network, and the second entity 420 may be a second node of the blockchain network.

[0065] Referring to FIG. 4, the message diagram includes receiving a first message 411 including event data for consideration in generating a new event. The first message may be received from a client application in communication with the first entity 410, another node in the blockchain network, or another entity. The event data may include content that provides information that identifies, or may be used as a basis for identifying, an object and / or namespace in the blockchain network. In one embodiment, the content of the event data may indicate a state (or change in state) of an associated object, e.g., in the case of an object of an invoice for a particular customer of a business, the event data may indicate that the state of the invoice has changed from an “unpaid” state to a “paid in full” state.

[0066] At operation 412, after the first message is received, the processor of the first entity 410 executes a smart contract to determine the content of the first message. This content is then submitted to a signature policy, which may define a set of conditions or actions to be performed in signing the event data and validating the event data to determine whether an event should be generated in the network. These conditions or actions may include determining whether an 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 may determine whether a default namespace exists that corresponds to the content of the event data. If neither condition exists, the validity of the event data may not be verified and the generation of the event may be rejected. On the other hand, if the conditions of the signature policy are met, the event may be generated.

[0067] At operation 413, after a determination is made that the conditions of the signature policy are satisfied, a processor executing the smart contract of the first entity 410 generates an event that includes a new field that stores key information corresponding to the object and / or namespace associated with the event data. This operation may be performed in a variety of ways. For example, the generated event may include the new field that contains the key information. Additionally or alternatively, a message format of a transaction associated with the event may include the new field that contains the key information.

[0068] After the event is created, a message 414 is sent to the blockchain 430. The message may be sent along with the event and one or more associated transactions, if any. After the message is received, the blockchain submits the event for agreement at operation 415, and then commits the event to a new block in the blockchain.

[0069] Then, at any time after the event is committed to the blockchain, a message 416 may be sent from the second entity 420 to the blockchain 430. The message 416 may include a query to access the event and its associated transactions.

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

[0071] At operation 419, the second entity 420 searches the contents 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) that corresponds to the content of the event. If there is a match, the second entity 420 may determine that the event is valid along with the transaction associated with the event identified in the information retrieved from the blockchain 430. These operations may be performed, for example, by a smart contract executed by a processor of the second entity 420.

[0072] 5 illustrates a flow diagram 500 of an exemplary method for managing information in a distributed database, such as a blockchain, according to an example embodiment. With reference to FIG. 5, the method 500 may include, at 510, receiving event data from an entity. The content of the event data may include various types of information indicative of events that are generated and recorded in the blockchain. The entity may be a client application of a blockchain node, a node in the blockchain, another blockchain entity, or an entity that is external to the blockchain network but in communication with one or more entities in the network.

[0073] At 520, a determination is made as to whether the event data satisfies a signature policy. The signature policy may include one or more requirements or conditions as described herein. In one embodiment, the signature policy may require that the content of the event data corresponds to one or more of the objects managed by the blockchain or a namespace of the blockchain. In a billing application, for example, the object may be a particular invoice and the event data may indicate a transaction related to the invoice. For example, the event data may indicate that a change in state has occurred for the invoice (e.g., from "unpaid" to "paid in full"). The namespace may correspond to, for example, a business or customer of a service that issued the invoice and / or provided the service or product related to the invoice.

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

[0075] At 540, after the signature policies are satisfied and the identifier is set, the method may include generating an event for submission to a blockchain network. The generated event may include, for example, multiple fields. One field may include information obtained from the event data indicating a state, object, namespace, or context managed by the database. Another field may include predetermined key information for the identifier, e.g., object, namespace, or other context.

[0076] At 550, the generated event may be submitted to a blockchain network. This submission may include committing the event for consensus and recording of the subject in a new block that is recorded on the blockchain. In one embodiment, this submission may include providing notification of the event to peer nodes in the blockchain network, regardless of whether the event is recorded on the blockchain.

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

[0078] FIG. 6A illustrates an example system 600 including a physical infrastructure 610 configured to perform various operations according to example embodiments. With reference to FIG. 6A, the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may be present in the blockchain 620) that may perform any of the operational steps 608 (within the module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the embodiments described or illustrated in the figures and may represent information written or read, outputted, or written from one or more smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the module 612 and the module 614 may be the same module.

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

[0080] FIG. 6C illustrates an exemplary system configured to utilize an intermediary server configured to configure smart contracts between contracting parties and enforce the terms of the smart contracts on a blockchain, according to an example embodiment. With reference to FIG. 6C, configuration 650 may represent a communication session, an asset transfer session, or a process or procedure operated by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the execution of the smart contract may be managed by a server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 that are participants in the smart contract transaction. The results of the execution of the smart contract may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0081] FIG. 6D illustrates a system 660 including a blockchain, according to an example embodiment. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing the logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledger, etc.) of the blockchain. In this example, the API gateway 662 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the servers 654 are peer components of the blockchain network that hold copies of the world state and the distributed ledger, which allow clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, which executes the smart contracts 630 according to the smart contracts 630 and signing policies.

[0082] The foregoing embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination thereof. The computer program may be embodied in a computer-readable medium, such as a storage medium. For example, the computer program may be present in a random access memory (RAM), a flash memory, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a register, a hard disk, a removable disk, a compact disk read-only memory (CD-ROM), or any other form of storage medium known in the art.

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

[0084] FIG. 7A illustrates a process 700 of a new block being added to the distributed ledger 720 according to an example embodiment, and FIG. 7B illustrates the contents of a new data block structure 730 of the blockchain according to an example embodiment. With reference to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, or 713, or a combination thereof. A client may be an instruction received from any source to specify an action on the blockchain 720. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, proposing a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a copy of the blockchain network state and the distributed ledger 720. Various types of blockchain nodes / peers may exist in a blockchain network, including signing peers that simulate and sign transactions proposed by clients, and commit peers that verify the signatures, validate the transactions, and commit the transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the role of signer nodes, committer nodes, or both.

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

[0086] The current state of the blockchain 722 and distributed ledger 720 may be stored in a state database 724, where the current state data represents the latest values ​​of all keys ever included in the on-chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. To make those chaincode interactions highly efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may contain an indexed view into the blockchain 722 transaction log, and therefore may be regenerated off-chain at any time. The state database 724 may be automatically restored (or generated if necessary) at peer startup and before transactions are received.

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

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

[0089] The ordering service 710 may consist of a cluster of ordering nodes. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may receive signed transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

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

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

[0092] With reference to FIG. 7B, a new data block 730 (also referred to as a data block) stored in the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that the various illustrated blocks and their contents, such as the new data block 730 and its contents illustrated in FIG. 7B, are examples only and are not intended to limit the scope of the example embodiments. The new data block 730 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the block data 750. The new data block 730 may include a link to a previous block (e.g., on the blockchain 722 of FIG. 7A) in the block header 740. In particular, the block header 740 may include a hash of the header of the previous block. The block header 740 may include a unique block number for the new data block 730, a hash of the block data 750, etc. The block numbers for the new data block 730 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

[0093] The block data 750 may store transaction information for each transaction recorded in the new data block 730. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 720 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploy transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, signer identification, signer signature, proposal hash, chaincode event, response status, namespace, write set (e.g., list of keys and versions read by transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0094] In some embodiments, the block data 750 may store new data 762 that adds additional information to the hash-linked chain of blocks in the blockchain 722. The additional information may include one or more of the steps, features, processes, or operations, or combinations thereof, described or illustrated herein. Accordingly, the new data 762 may be stored in an immutable log of blocks on the distributed ledger 720. Some of the advantages of storing such new data 762 are reflected in various embodiments disclosed and illustrated herein. In FIG. 7B, the new data 762 is illustrated in the block data 750, but it may also be in the block header 740 or block metadata 760.

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

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

[0097] A blockchain may be formed in a variety of ways. In one embodiment, digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of the reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis to reference the previous block. This may be shown as follows: Block 1 Block 2 ····Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0098] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the contents of each block that does not contain digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then searching the storage area for the hash value stored that corresponds to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be shown as follows: Blockchain Storage Area Hash value of block 1 Hash value of block 1...Contents · · · · · · Hash value of block N Hash value of block N... contents

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

[0100] Block 778 in the blockchain 1 , 778 2 , ...778 NEach of the files includes a header, a version of the file, and a value. The header and value vary from block to block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the version of the file may be the original file or a different version of the original file.

[0101] The first block in the blockchain: 778 1 It is called the genesis block and has header 772 1 , original file 774 1 , and the initial value 776 1 The hashing scheme used for the genesis block (and in fact for all subsequent blocks) may vary. For example, the first block, 778 1 All information in may be hashed together at the same time, or the first block 778 1 Each or a portion of the information in may be hashed separately and then a hash of the separately hashed portions may be performed.

[0102] Header 772 1 may include one or more initialization parameters, such as a version number, a timestamp, a nonce, route information, difficulty, agreement protocol, duration, media format, source, descriptive keywords, or the original file 774 1 or other information associated with the blockchain or both, or a combination thereof. 1 may be generated automatically (e.g., by blockchain network management software) or manually by participants in the blockchain. 2 ~778 N Unlike the header in the genesis block, the header in 1 does not refer to a previous block, because there is simply no previous block.

[0103] Original file 774 in the genesis block 1 may be, for example, data captured by a device, with or without processing before being included in the blockchain. Original file 774 1 is received from a device, media source, or node through an interface of the system. 1 The metadata may be associated with the original file 774, and the metadata may be generated, for example, by a user, a device, or a system processor, or a combination thereof, either manually or automatically. 1 In relation to the first block 778 1 may be included in

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

[0105] 778 other blocks in the blockchain 2 ~778 N also contains a header, file, and value. But the first block 772 1 Unlike the header 772 in other blocks 2 ~772N Each of the remaining blocks contains the hash value of the immediately preceding block, which may simply be a hash of the previous block's header, or may be a hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block trace can be performed back from the Nth block to the genesis block (and associated original file), as indicated by arrow 780, establishing an auditable and immutable evidential chain of custody.

[0106] Header 772 in another block 2 ~772 N Each of the may generally include other information (e.g., a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof).

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

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

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

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

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

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

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

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

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

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

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

[0118] Decryption is performed based on the type of encryption performed on each block. This decryption may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor in the network may generate a public and private key pair using a predefined algorithm. The public and private keys are related to each other by some mathematical relationship. The public key may be distributed publicly to serve as an address (e.g., an IP address or a home address) for receiving messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent this message.

[0119] Generating a key pair is similar to creating an account on the blockchain, but in reality, there is no need to register anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using a private key. This signature ensures that only the account owner can track and process files on the blockchain (if within the scope of their permissions, as determined by the smart contract).

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

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

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

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

[0124] Additionally, training the machine learning model on the collected data may require a series of refinements and tests by the host platform 820. Each refinement and test may be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. At 802, the different training and testing steps (and associated data) may be stored in the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored in the blockchain 810. This provides verifiable proof of how the model was trained and what data was used to train the model. Additionally, when the host platform 820 achieves a final trained model, the resulting model may be stored in the blockchain 810.

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

[0126] New transactions in the blockchain can be collected together in a new block and added to an existing hash value. This hash value is then encrypted to produce a new hash for the new block. This new hash is added to the next list of transactions as they are encrypted, and so on. The result is a chain of blocks, each containing the hash values ​​of all the blocks that preceded it. The computers that store these blocks periodically compare the hash values ​​of the blocks to make sure they are all in agreement. Any computers that are not in agreement discard the offending record. This method is good at guaranteeing that the blockchain is tamper-proof, but it is not perfect.

[0127] One way to rig the system is for a malicious user to modify the list of transactions in a way that does not change the hash. This can be done by a brute force attack, in other words by modifying the record, encrypting the result, and checking if the hash value is the same. If the hash value is not the same, it tries again and again until it finds a matching hash. The security of the blockchain is based on the idea that a normal computer can only perform this kind of brute force attack over totally impractical timescales, such as the age of the universe. Quantum computers, by contrast, are very fast (thousands of times faster) and therefore pose a very large threat.

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

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

[0130] The operation of the blockchain 852 is based on two steps: (i) the creation of a transaction, and (ii) the construction of a block that collects new transactions. New transactions may be created in the same way as in a traditional blockchain network. Each transaction may contain information about the sender, the recipient, the time of creation, the amount (or value) to be transferred, a list of reference transactions that justify the sender having funds for the operation, etc. This transaction record is then sent to all other nodes and entered into the pool of unconfirmed transactions. Now, two parties (i.e., a pair of users among 854-860) authenticate the transaction by providing a shared secret key 862 (QKD). This quantum signature is attached to every transaction, making it extremely difficult to tamper with. Each node checks the transaction entry with respect to its local copy of the blockchain 852 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0131] Rather than performing a traditional mining process on a block, a broadcast protocol may be used to create blocks in a distributed manner. At a predefined time period (e.g., seconds, minutes, hours, etc.), the network may apply the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine consensus (agreement) on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). At the first time, the nodes send the private value to each other. Then, the nodes communicate the information they received from other nodes last time. Now, the authentic node can create a complete set of transactions in a new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or operations described and / or illustrated herein may occur in or with respect to the blockchain 852.

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

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

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

[0135] A bus may represent one or more of any of a number of types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example only, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus.

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

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

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

[0139] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, one or more devices that allow a user to interact with the computer system / server 902, or any device that allows the computer system / server 902 to communicate with one or more other computing devices (e.g., network cards, modems, etc.), or a combination thereof. Such communication may occur through an I / O interface 924. Additionally, the computer system / server 902 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, through a network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 through a bus. It should be understood that other hardware and / or software components, not shown, may be used with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0140] Although at least one example embodiment of the system, method, and non-transitory computer-readable medium has been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but may be subject to numerous rearrangements, modifications, and substitutions, as illustrated and defined by the following claims. For example, the functions of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or a portion of the functions performed by individual modules may be performed by one or more of those modules. Furthermore, the functions described herein may be performed at various times, with respect to various events, within or outside the modules or components. Also, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, or via multiple protocols, or a combination thereof. Additionally, a message sent or received by any of the modules may be sent or received directly, via one or more of the other modules, or both.

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

[0142] In accordance with one or more of the foregoing embodiments, systems, methods, and computer-readable media are provided that represent improvements to managing the storage of information in a distributed database, and more particularly, improvements to managing transaction and other event data in a distributed database, including but not limited to blockchain.

[0143] In one embodiment, one or more of the embodiments solve the problem by preventing a Byzantine client from injecting valid but misleadingly formed transactions into the system that appear to emit events corresponding to certain actions but fail to perform said actions. In a traditional database, transactions may be safely filtered at the point of entry because there is an assumption of trust by any participant to any validating node. In contrast, in accordance with one or more embodiments, these one or more embodiments cannot operate under a traditional database because different participants have different permissions and / or different states and require different signatures to modify them.

[0144] Additionally, one or more embodiments described herein improve the security of client applications by removing an attack surface (spoofed events for otherwise valid transactions). Additionally, one or more embodiments may store and manage new types of data in a distributed database. For example, new data may be stored inside a transaction that encapsulates an event. This additional data may be utilized by a transaction validation component to perform more validation checks than would otherwise be required to validate the transaction. This additional data is then utilized by the client, which, if the transaction is marked as valid, can now safely process the event because it knows that these additional security checks have been performed.

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

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

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

[0148] It will be readily understood 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, and thus, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but merely represents selected embodiments of the present application.

[0149] Those skilled in the art will readily appreciate that it is possible to practice the foregoing using steps in an order other than that disclosed, or using hardware elements other than those in the disclosed configurations, or both. Thus, while the application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be apparent.

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

Claims

1. a receiver for receiving event data from the entity; A system comprising: a storage area for storing code of a smart contract; and a processor for executing the smart contract, the smart contract comprising: determining that the event data satisfies a signature policy; establishing an identifier corresponding to a context of the event data; generating an event including the event data and the identifier; submitting the event for recording in a distributed database; The system validates that the identifier is a state that corresponds to the context in the event data is correct.

2. The system of claim 1 , wherein the identifier comprises previously generated key information that corresponds to the context of the event data.

3. 3. The system of claim 1, wherein the context of the event data references an object managed by the database.

4. The system of any of claims 1 to 3, wherein the context of the event data comprises a tuple containing at least two of a channel name, a namespace, a collection, or a key name corresponding to the database.

5. The system of any of claims 1 to 3, wherein the context of the event data includes a tuple containing a channel name, a namespace, a collection, and a key name corresponding to the database.

6. The system of any preceding claim, wherein the processor generates the event according to an operation including inserting the identifier into a predefined field in a format corresponding to the event.

7. the context being an object or namespace managed by the database; The system of any preceding claim, wherein the identifier is pre-authenticated with respect to the object or namespace.

8. A method comprising: receiving event data from the entities by a receiver in the system; A smart contract executed by a processor of the system, determining that the event data satisfies a signature policy; establishing 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, wherein the identifier is used to validate that a state corresponding to the context in the event data is correct.

9. The method of claim 8 , wherein the identifier comprises previously generated key information that corresponds to the context of the event data.

10. 10. The method of claim 8 or 9, wherein the context of the event data references an object managed by the database.

11. The method of any of claims 8 to 10, wherein the context of the event data comprises a tuple containing at least two of a channel name, a namespace, a collection, or a key name corresponding to the database.

12. The method of any of claims 8 to 10, wherein the context of the event data comprises a tuple containing a channel name, a namespace, a collection, and a key name corresponding to the database.

13. The method according to any one of claims 8 to 12, wherein generating the event comprises inserting the identifier into a predefined field in a format corresponding to the event.

14. the context being an object or namespace managed by the database; The method according to any of claims 8 to 13, wherein the identifier is pre-authenticated with respect to the object or namespace.

15. A computer program comprising: receiving event data from an entity; determining that the event data satisfies a signature policy; establishing 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; and validating that the identifier corresponds to a state of the context in the event data is correct.

16. 16. The computer program product of claim 15, wherein the identifier comprises previously generated key information that corresponds to the context of the event data.

17. 17. A computer program product as claimed in claim 15 or 16, wherein the context of the event data references an object managed by the database.

18. 18. The computer program product of claim 15, wherein the context of the event data comprises a tuple containing at least two of a channel name, a namespace, a collection, or a key name corresponding to the database.

19. The computer program product of any one of claims 15 to 18, wherein generating the event comprises inserting the identifier into a predefined field in a format corresponding to the event.

20. the context being an object or namespace managed by the database; A computer program product as claimed in any one of claims 15 to 19, wherein the identifier is pre-authenticated with respect to the object or namespace.

Images