Automatic merging of dlt networks

Abstract

Example operations can include one or more of receiving a request to merge a first blockchain network and a second blockchain network, the request including a script specifying a network structure; synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations; and merging the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, wherein the merging includes merging chaincodes and channels from the first blockchain network and the second blockchain network into merged chaincodes and merged channels.

Description

BACKGROUND

[0001] A centralized platform stores and maintains data in a single location. This location is often a central computer, e.g., a cloud computing environment, a web server, a mainframe computer, etc. Information stored on a centralized platform is typically accessible from multiple different points. Multiple users or client workstations can work on the centralized platform simultaneously, e.g., based on a client / server configuration. Centralized platforms are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized platform, data redundancy is minimized, as the single storage location for all data also means that a given data set has only one primary record. SUMMARY

[0002] One example embodiment provides an apparatus comprising a processor configured to one or more of: receive a request to merge a first blockchain network and a second blockchain network, the request comprising a script specifying a network structure, synthesize the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations, and merge the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, wherein the processor merges chaincodes and channels from the first blockchain network and the second blockchain network into merged chaincodes and merged channels.

[0003] Another example embodiment provides a method comprising one or more of: receiving a request to merge a first blockchain network and a second blockchain network, the request comprising a script specifying a network structure, synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations, and merging the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, wherein the merging comprises merging chaincodes and channels from the first blockchain network and the second blockchain network into merged chaincodes and merged channels.

[0004] Yet another example embodiment provides a non-transitory computer readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a request to merge a first blockchain network and a second blockchain network, the request comprising a script specifying a network structure, synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations, and merging the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, wherein the merging comprises merging chaincodes and channels from the first blockchain network and the second blockchain network into merged chaincodes and merged channels. BRIEF DESCRIPTION OF DRAWINGS

[0005] FIG. 1A is a diagram illustrating a process of merging multiple blockchain networks according to an example embodiment.

[0006] FIG. 1B is a diagram illustrating a process of inputting data for performing merge operations according to an example embodiment.

[0007] FIG. 1C is a diagram illustrating a process of merging elements of multiple blockchain networks according to an example embodiment.

[0008] FIG. 1D is a diagram illustrating a process of converting a script into merge operations according to an example embodiment.

[0009] FIG. 2A is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0010] FIG. 2B is a diagram illustrating a blockchain transaction flow between nodes according to an example embodiment.

[0011] FIG. 3A is a diagram illustrating a permissioned network according to an example embodiment.

[0012] FIG. 3B is a diagram illustrating another permissioned network according to an example embodiment.

[0013] FIG. 3C is a diagram illustrating an un-permissioned network according to an example embodiment.

[0014] FIG. 4A-4C is a diagram illustrating a process of merging chaincodes according to an example embodiment.

[0015] FIG. 5 is a diagram illustrating a method of merging multiple blockchain networks according to an example embodiment.

[0016] FIG. 6A is a diagram illustrating an example system configured to perform one or more operations described herein, according to an example embodiment.

[0017] FIG. 6B is a diagram illustrating another example system configured to perform one or more operations described herein, according to an example embodiment.

[0018] FIG. 6C is a diagram illustrating yet another example system configured to utilize smart contracts, according to an example embodiment.

[0019] FIG. 6D is a diagram illustrating still another example system configured to utilize a blockchain, according to an example embodiment.

[0020] FIG. 7A is a diagram illustrating a process of a new block being added to a distributed ledger, according to an example embodiment.

[0021] FIG. 7B is a diagram illustrating data content of a new block of data, according to an example embodiment.

[0022] FIG. 7C is a diagram illustrating a blockchain for digital content, according to an example embodiment.

[0023] FIG. 7D is a diagram illustrating a block that can represent a block in a blockchain, according to an example embodiment.

[0024] FIG. 8A is a diagram illustrating an example blockchain storing machine learning (artificial intelligence) data, according to an example embodiment.

[0025] FIG. 8B is a diagram illustrating an example quantum secure blockchain, according to an example embodiment.

[0026] FIG. 9 is a diagram illustrating an example system supporting one or more example embodiments. DETAILED DESCRIPTION

[0027] It will be readily understood that the components of the application, as generally described and illustrated in the Figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description, which discloses at least one example embodiment of methods, apparatus, non-transitory computer readable medium, and systems as represented by the Figures, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0028] In one or more embodiments, features, structures, or characteristics of the application as described throughout this specification can be combined or removed in any appropriate manner. For example, use of the phrases "example embodiment," "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment. Thus, appearances of the phrases "example embodiment," "in some embodiments," "in other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any appropriate manner in one or more embodiments. In addition, in the diagrams, any connection can be implemented as a suitable wired or wireless connection and can have one or more wires / wireless connections. Further, any devices described in the diagrams can be distinct devices or the same device. For example, if a mobile device is depicted as sending information, a wired device can also be used to send the information.

[0029] Further, although the term "message" can be used in the description of embodiments, the application can be applied to many types of networks and data. Further, although particular types of connections, messages, and signaling can be depicted in example embodiments, the present application is not limited to particular types of connections, messages, and signaling.

[0030] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks directed to automatically merging distributed ledger networks (e.g., blockchains, etc.) based on scripts.

[0031] According to various aspects, a plurality of blockchain networks can be merged together to form a combined network including a combined blockchain ledger, combined chaincode, combined channels, etc. Organizations included in each of the different blockchains can be provided with increased data access and transaction capabilities. For example, an organization that owns a blockchain peer in the combined blockchain network will have greater visibility than in the previous network, retain the same access controls they had in the previous network, include access to an expanded blockchain ledger of more transactions and transaction peers, etc. As a result, blockchain peers that are merged together can transact between the new / different blockchain peers. Further, the merging process can be automated based on scripts and configuration data from each of the blockchain networks.

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

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

[0034] The application can utilize nodes that are communication entities of a blockchain system. A "node" can perform logical functions in the sense that different types of multiple nodes can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in different ways. Nodes can include different types, such as client or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., orderer nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions, and maintain a state and copy of a ledger of blockchain transactions. A peer can also have the role of an endorser, although it is not required. An orderer-service-node or orderer is a node that runs a communication service for all nodes and implements delivery guarantees, such as broadcasting to every peer node in the system when a transaction is submitted and the world state of the blockchain is modified, which is another name for an initial blockchain transaction that typically includes control and setup information.

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

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

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

[0038] Business needs of organizations can evolve. To address this, the organizations can link the networks and applications they rely on with other organizations. There are different techniques to perform such linking, including activating a linking mechanism or relying on members to act as a conduit for asset and data exchange linked via agents or processes. However, both techniques incur significant engineering overhead.

[0039] Merging networks can provide increased opportunities to the involved organizations without increasing overhead when two networks have a high degree of commonality (e.g., common business purpose, activities, users, etc.). In example embodiments, a host platform can merge multiple blockchain networks together, opening up new opportunities for organizations that have blockchain peers in any of the networks. For example, two blockchain networks that perform similar functions (e.g., financial services, exporters / importers, logistics, supply chain participants, etc.) can be combined into a single network that provides increased access to data and increased transaction processing capabilities.

[0040] As a non-limiting example, two disjoint groups of banks on two separate blockchain networks can be merged together into a unified blockchain network. As such, the two groups of banks can transact together via a single blockchain ledger. In this example, the previous blockchain ledgers can be merged together into one larger blockchain ledger. Likewise, chaincodes on different blockchains that are the same or related to each other can be merged together. Further, data operated on by these chaincodes can be reconfigured / re-named to work with the new merged chaincodes. The merging process can be automatic. Thus, administrators and developers of the different blockchain networks do not need to spend time and risk errors by manually performing the merging operations.

[0041] In some embodiments, different blockchain networks being merged can be built on the same blockchain framework, such as a hyperledger fabric. Chaincode (deployed smart contracts) can be merged horizontally or vertically. In horizontal merging, two blockchain networks can each have chaincode that performs the same function using the same key values or performs the same function using similar key values. Here, the two chaincodes can be merged by keeping one chaincode and deleting the other, while reconfiguring the ledger data (e.g., key-value pairs) created by the deleted chaincode to work with the remaining chaincode. For example, the reconfiguring can include renaming key names of key values to prevent duplicate keys, mapping key values, etc.

[0042] In vertical merging, a host can chain together a first chaincode of a first blockchain network that triggers execution of a second chaincode on a second blockchain network. In this case, the code included in the second chaincode can be aggregated together to form one larger chaincode that has the functionality of both the first chaincode and the second chaincode. Further, when the ledger data (key values) of the first chaincode and the second chaincode refer to the same data item, they can be combined and mapped together.

[0043] FIG. 1A A process 100A of merging multiple blockchain networks 110 and 120 is shown in accordance with example embodiments. Referring to FIG. 1A , a host platform 140, such as a cloud platform, a web server, a user device, etc., can be used to merge multiple blockchain networks together. In FIG. 1A , two blockchain networks 110 and 120 are merged together to create a merged network 130. However, it should also be appreciated that more than two blockchain networks can be merged together. It should also be appreciated that example embodiments are not limited to blockchains, but can merge together any kind of distributed ledger network.

[0044] In FIG. 1A , the blockchain network 110 includes three blockchain peers that transact using chaincode running thereon based on block data from a blockchain of the blockchain network 110. Likewise, the blockchain network 120 includes five blockchain peers (which are disjoint from the three peers of the blockchain network 110) that transact using chaincode running thereon based on block data from a blockchain of the blockchain network 120. As further described with respect to examples in FIG. 1B , FIG. 1C and FIG. 1D , the host platform 140 can merge the two blockchain networks 110 and 120 to create a merged blockchain network 130. During the merging, the host platform 140 can merge chaincode, blockchains, peer membership, consensus protocols, etc.

[0045] FIG. 1B A process 100B is shown for inputting data for performing a merge operation, in accordance with example embodiments. Referring to FIG. 1B The host platform 140 includes a synthesizer 141, an organization merge module 142, a chaincode merge module 143, a ledger merge module 144, and an orderer merge module 145 that can also perform consensus protocol merges. Here, the synthesizer 141 can receive a script 161 from merging the two blockchain networks 110 and 120, the script 161 including user-defined instructions. The script can include declarative statements with instructions on how the two blockchain networks 110 and 120 are to be merged. The script can be in a machine-readable format, such as JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YML), data logic, etc. In some embodiments, a user can develop the script via a development environment on the user device 150. As another example, the host platform 140 can output a user interface on the screen 152 of the user device 150. Here, the user interface can include predefined fields that receive input text from a user. In this case, the input can be fed back to the host platform 140, where it is converted into the script 161 using predefined templates, etc.

[0046] The synthesizer 141 can also receive configuration data files 162 and 163 that include configuration data of the blockchain networks 110 and 120, respectively. Examples of configuration data that can be included in the configuration data files 162 and 163 include channel information, peer IDs, certificate authority information, chaincode information, access policy information, consensus protocol information, ordering service information, blockchain ledger information, etc. The configuration data files 162 and 163 can also include connection configuration files. As further described below with respect to FIG. 1D The synthesizer 141 can synthesize the instructions within the script 161 and the configuration data within the configuration files 162 and 163 to produce a series of operations that can be executed by processing devices to automatically merge the two blockchain networks 110 and 120 into the merged network 130.

[0047] FIG. 1C A process is shown for merging elements of the two blockchain networks 110 and 120, in accordance with example embodiments. Referring to FIG. 1B and FIG. 1C The organization merge module 142 can perform a series of merge operations based on the series of merge operations created by the host platform (e.g., the script 161), the configuration data files 162 and 163, and the configuration data within the configuration data files 162 and 163. The organization merge module 142 can perform the series of merge operations to produce a merged organization 131 that includes the merged blockchain networks 110 and 120. FIG. 1DThe merge operation 170) merges the organizational data from the two blockchain networks 110 and 120 together to create merged organizational data 131 of the merged network 130. Here, the merged organizational data 131 can include peer member information, access rights for different peers, unique peer identifiers (e.g., URLs, etc.), and the like. The organizational data 131 can also include channel information for the newly merged blockchain network 130. Here, the organizational merge module 142 can create a channel, join peers from the two blockchain networks 110 and 120 to the created channel, update the configuration of the channel based on the network configuration, add member service providers (MSPs) to the organization, associate certification authorities with peers, and the like.

[0048] The organizational merge module 142 can select the organizations and their peers to include in the merged blockchain network 130 based on the merge operation 170. The certification authorities can remain the same or they can be changed by the organizational merge module 142. The organizational merge module 142 can rename the base organizations, merge the organizations into the base organizations, identify certification authorities to add to the base organizations, update channel information, join peers, and the like based on the merge operation 170. In some embodiments, the organizational merge module 142 can also perform an optimization process that selects peers and reallocates peers and certification authorities among the peers according to an optimization algorithm.

[0049] The chaincode merge module 143 is configured to merge the chaincodes on the two blockchain networks 110 and 120 together to generate merged chaincode 132 based on the merge operation 170. As further described in the example of FIG. 4A-4C As further described in the example of FIG. 1, the chaincode merge module 143 can perform horizontal merging (which eliminates duplicate or similar chaincodes) and vertical merging (which combines the code from chaincodes from two different links together). In some embodiments, the chaincode merge module 143 can parse the original chaincodes, identify features therein, modify any code, merge the code together, modify underlying keys generated by the chaincodes to work with the new / merged chaincode, and the like. After merging, the merged chaincode 132 is able to perform transactions on the blockchain ledger data from the first blockchain network 110 and the second blockchain network 120.

[0050] The ledger merge module 144 is configured to merge two disjoint blockchains in the two blockchain networks 110 and 120 together to create a merged blockchain ledger 133 based on the merge operation 170, which can include a merged chain and a merged state database (world state). For example, the ledger merge module 144 can create a merge block with a hash of the final block on the first blockchain and a hash of the final block of the second blockchain to link the new blockchain to the first and second blockchains. The merge block merges the histories of the two blockchains and enables the previous transactions of the two blockchains to be verified (i.e., via the previous hashes). The ledger merge module 144 can also be configured to install and instantiate chaincode (including merged chaincode) on the merged blockchain peers.

[0051] The merged block can be the first block of the merged blockchain on the merged blockchain ledger 133. The ledger merge module 144 can also propagate the previous blocks of the blockchains to the peers of the other respective networks prior to the merge. Thus, the blockchain peers of the blockchain network 110 can receive the previous blocks of the blockchain peers of the blockchain network 120, and vice versa. The newly added transactions on the merged blockchain network 130 can be added to the merged blockchain.

[0052] The ordering merge module 145 is configured to merge the ordering services (ordering nodes) of the two blockchain networks 110 and 120 together based on the merge operation 170 to generate a merged ordering 134. The ordering merge module 145 can create a cluster of nodes from both the network 110 and 120 ordering nodes and implement the desired consensus protocol. In some cases, the two blockchain networks 110 and 120 can include two different consensus protocols (e.g., quorum requirements, roles of peers, endorser peers, etc.). The ordering merge module 145 can merge the different consensus protocols, resulting in a single consensus protocol between the two blockchain networks 110 and 120.

[0053] FIG. 1D A process 100D to convert a script into a merge operation 170 is shown in accordance with example embodiments. Referring to FIG. 1D The synthesizer 141 of the host platform 140 can receive a script 161 (which includes user-defined instructions) along with configuration files 162 and 163 representing network information of the blockchain networks 110 and 120 and generate a merge operation sequence 170. The merge operation sequence 170 can be executed by a processing device to automatically perform the merge of the blockchain networks 110 and 120 to create the merged network 130.

[0054] The script 161 can capture at a high level the user intent of the desired end state of the merged network. Here, the user script can identify the initial state of the two blockchain networks to be merged and the final state of the merged blockchain network including both blockchain networks. The script 161 can include the subject matter (organization, channels, chaincode, etc.) and specify the target of the merged network. The script 161 can identify imports to be renamed, data, peers, channels and chaincode, subject matter to be merged, policies followed (e.g., endorsement, consensus, etc.), etc. The script 161 can be written in a predefined language such as JSON, YAML, XML, Datalog, etc. The script 161 can be generated through a wizard or through a user interface. The configuration files 162 and 163 can be any desired file, e.g., JSON, XML, etc.

[0055] The sequence of operations 170 can include commands (e.g., import, generate, execute, loop, etc.) to be executed by a processing device and including computer readable instructions. For example, the commands can include an import command to input data from the configuration files 162 and 163, a generate command to generate peer identifiers, new configuration files, updated channel information, etc., a “for” loop for processing instructions for each peer in the network, such as adding a peer, renaming a peer, associating a certificate authority to a peer, etc. The result of executing the sequence of operations 170 is the combined network 130 as shown in FIG. 1A

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

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

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

[0059] A smart contract can be created via a high-level application and programming language and then written to a block in the blockchain. A smart contract can include executable code that is registered, stored, and / or replicated with the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of the smart contract logic, which can be executed in response to conditions associated with the smart contract being satisfied. The execution of a smart contract can trigger a trusted modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers by one or more consensus protocols.

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

[0061] Chaincode can include an interpretation of the code (e.g., logic) of a smart contract. For example, chaincode can include a packaged and deployable version of the logic within a smart contract. As described herein, chaincode can be program code deployed on a computing network, where the chaincode is executed and validated by chain validators together during a consensus process. The chaincode can receive a hash and retrieve from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode can write data associated with encryption details to the blockchain.

[0062] FIG. 2B An example of a blockchain transaction flow 250 between nodes of a blockchain in accordance with example embodiments is shown. Referring to FIG. 2B , the transaction flow can include a client node 260 transmitting a transaction proposal 291 to endorsing peers 281. The endorsing peers 281 can validate the client signature and execute chaincode functions to initiate the transaction. The output can include chaincode results, a set of key / value versions read in the chaincode (read set), and a set of keys / values written in the chaincode (write set). Here, the endorsing peers 281 can determine whether to endorse the transaction proposal. If approved, a proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to the ordering service nodes 284. The ordering service nodes 284 then deliver the ordered transaction as a block to all peers 281-283 on the channel. Each peer 281-283 can validate the transaction before committing to the blockchain. For example, the peers can check the endorsement policy to ensure the correct allocation of specified peers have signed the results and validate the signature on the transaction payload 293.

[0063] Referring again to FIG. 2BThe client node initiates the transaction 291 by constructing a request and sending the request to a peer 281 that is an endorser. The client 260 can include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal. A proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., a new key-value pair is written for an asset). The SDK can act as a shim to package the transaction proposal into a suitable architectural format (e.g., protocol buffers over remote procedure calls (RPCs)) and employ the client's cryptographic credentials to produce a unique signature of the transaction proposal.

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

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

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

[0067] These blocks are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The data portion within the block can be verified to ensure that the endorsement policy is satisfied and that the ledger state read by the collection variable has not changed, as the read collection is generated by the transaction execution. Additionally, at step 295, each peer node 281-283 appends the block to the chain of the channel and, for each valid transaction, the write collection is committed to the current state database. An event can be emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain and whether the transaction was validated or invalidated.

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

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

[0070] FIG. 3BAnother example of a permissioned blockchain network 320 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, blockchain users 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be published through a client-side application leveraging an SDK, directly through an API, etc. The network can provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and registering blockchain users 322 as "clients." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

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

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

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

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

[0075] Before a block can be added to the blockchain, the block must be validated. Validation for the unlicensed blockchain 352 can include proof-of-work (PoW), which is a solution to a puzzle derived from the header of the block. While not shown in the example of FIG. 3, another process for validating blocks is proof-of-stake. Unlike proof-of-work, where an algorithm rewards the miner who solves the mathematical problem with proof-of-stake, the creator of a new block is selected in a deterministic manner, depending on its wealth, also defined as “stake.” A similar proof is then performed by the selected node. FIG. 3C

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

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

[0078] FIG. 4A-4C A process of merging chaincode is shown in accordance with example embodiments. For example, FIG. 4A A process 410 of horizontal merge with same code is shown, FIG. 4B A process 420 of horizontal merge with same functional code is shown, and FIG. 4C A process 430 of vertical merge linking two different chaincodes together is shown (e.g., where the first chaincode triggers the second chaincode).

[0079] Referring to FIG. 4A chaincode 411 of a first blockchain network and chaincode 412 of a second blockchain network are merged to create merged chaincode 413. In this example, chaincode 411 and chaincode 412 include the same program code (e.g., with possible minor whitespace differences). Here, the host platform can delete one of chaincode 411 and 412 and select the remaining chaincode for merged chaincode 413. Thus, merged chaincode 413 is a selection of one of the same chaincode 411 and 412. The business logic performed by merged chaincode 413 is the same as the corresponding logic of chaincode 411 and chaincode 412. The merge can be performed based on a predefined template that specifies which code to use, which code to discard / delete, how to merge underlying data used by chaincode 411 and 412 (e.g., stored in state databases 414 and 415), etc.

[0080] For example, the template can refer to modifying certain code features to different code features according to a particular mapping function. A parser can parse the original source code and whenever any part matches a code feature present in the template, the mapping function can be applied to produce a different source code.

[0081] In addition to merging chaincodes 411 and 412, the host platform can also merge datasets 414 and 415 of chaincodes 411 and 412, respectively. Here, dataset 414 includes key-value pairs created, updated, stored, etc. by chaincode 411, and dataset 415 includes key-value pairs created, updated, stored, etc. by chaincode 412. During the merge, both datasets 414 and 415 can be transferred to a resulting dataset 416 of keys values stored on the merged blockchain network. Here, the host platform can import one of datasets 414 and 415 into the resulting dataset 416 and modify the other remaining dataset based on a predefined function to prevent duplicate key names. For example, the host platform can import dataset 414 into dataset 416 and modify dataset 415 such that each key includes an additional identifier (e.g., a network ID of the second blockchain network, etc.) to distinguish duplicate values of dataset 414.

[0082] In some embodiments, to avoid conflicts with key names already existing in dataset 414 (or another dataset that has been imported into dataset 416), the keys of dataset 415 can be modified based on instructions in the template, e.g., via a schema generator, etc. For example, the key ‘abc123’ can be stored in both datasets 414 and 415. In this example, the key ‘abc123’ in dataset 415 can be modified with a network identifier of the second blockchain network ‘Network2’ stored in the template to generate a modified / re-named key identifier ‘Network2.abc123’. This ensures that the merge does not overwrite data.

[0083] Referring to FIG. 4B , chaincode 421 of the first blockchain network and chaincode 422 of the second blockchain network are merged to create a merged chaincode 423. In this example, chaincode 421 and chaincode 422 include program code that performs the same function, however, the identifiers of the keys used are different. Here, the host platform can delete one of chaincodes 421 and 422 and select the remaining chaincode for merged chaincode 423. Thus, merged chaincode 423 is a selection of one of the same chaincodes 421 and 422. The business logic performed by merged chaincode 423 is the same as the corresponding logic of chaincode 421 and chaincode 422.

[0084] Similar to FIG. 4A the example, the host platform can merge dataset 424 of key-value pairs created by chaincode 421 with dataset 425 of key-value pairs generated by chaincode 422 to generate a merged dataset 426 that is stored in the state database of the merged blockchain network. In this example, the merge can modify the key names of one of the datasets with a network identifier and a user-provided function. The user-provided function can be used to map the key names between dataset 424 and dataset 425, thereby linking data values in the merged ledger together.

[0085] Referring FIG. 4C , the chaincode 431 of the first blockchain network and the chaincode 432 of the second blockchain network are merged to create a merged chaincode 433. In this example, the chaincode 431 and the chaincode 432 include different program codes that have been linked for execution. For example, the output from a function in the chaincode 431 can be the input to a function in the chaincode 432. Here, the host platform can extract the program code from each of the chaincodes 431 and 432 and combine the extracted program codes within the merged chaincode 433. Thus, the two program codes can be added together to create a larger program code that includes the functionality of both the chaincodes 431 and 432. That is, the business logic executed by the merged chaincode 433 is the same as the corresponding logic of the chaincode 431 in conjunction with the corresponding logic of the chaincode 432.

[0086] Merging two different contract programs is analogous to linking two different graphs by adding arrows from nodes (representing states) in one graph to nodes in the other graph. This results in a single graph representing a single program. In terms of code, the final contract code in the merged chaincode 433 will contain code from both chaincodes 431 and 432, with function calls between the two codes inserted at the correct locations in the merged chaincode 433.

[0087] An example of this merged chaincode 433 can be represented in a scenario where a logistics partner is merged with a trade finance partner. In this example, the logistics network can perform the following steps: (al) the importer submits a purchase order to purchase certain goods from the exporter, (a2) the exporter submits an invoice, (a3) the shipment is sent to a marine carrier, (a4) the marine carrier creates a bill of lading, and (a5) the marine carrier delivers the shipment to the importer. Meanwhile, the trade finance partner can need the invoice to trigger a payment process, including the following steps: (bl) the exporter submits an invoice, (b2) the bank validates the invoice and other shipment details, and (b3) payment is initiated from the importer to the exporter.

[0088] These two processes (a) and (b) can be merged by automatically invoking step (bl) in the second network after step (a2) is completed in the first network. The call to (bl) can be made in the example of the script 161 described above. FIG. 1B and FIG. 1D This type of linking can be specified in the script 161 described in the example above. With the information of how the two processes are linked, the host platform can add the call to invoke (bl) when (a2) is completed.

[0089] In addition to merging the chained code 431 and 432, the host platform can merge the data set 434 of key-value pairs created by the chain code 431 with the data set 435 of key-value pairs generated by the chain code 432 to generate a merged data set 436, which is stored in the state database of the merged blockchain network. In this example, the merge can identify keys referring to the same asset in both data sets 434 and 435 and retain only one copy of the key-value in the final data set 436.

[0090] FIG. 5 A method 500 of merging multiple blockchain networks is shown in accordance with example embodiments. As a non-limiting example, the method 500 can be performed by a host platform blockchain network, such as a cloud platform, web server, database, etc. Reference is made to FIG. 1 for an example of a host platform blockchain network. FIG. 5 In 510, the method can include receiving a request to merge a first blockchain network and a second blockchain network, where the request includes a script specifying a network structure. As an example, the script can be a document or file created by a developer using a predefined format (e.g., JSON, XML, YAML, Datalog, etc.). In some embodiments, the system can provide a user interface with fields for user input. In this example, the system can take the inputs and convert them into a script based on a predefined template. The script can include declarative statements that express the user’s intent about how the different blockchain networks should be combined.

[0091] In 520, the method can include synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations. Here, the configuration data can include network topology, smart contract (chain code) information, peer member information, blockchain ledger information, organization information, etc. The configuration data can be merged with the script to generate a plurality of operations (or commands) that can be executed by a processor to automatically merge the first blockchain network and the second blockchain network together. In some embodiments, the synthesizing can include parsing the script to generate an initial state of the first blockchain network and the second blockchain network prior to the merge and a final state of the merged blockchain network after the merge, and determining a sequence of operations to be executed to transform the initial state into the final state.

[0092] In 530, the method can include merging the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, where the merging includes merging chain codes and channels from the first blockchain network and the second blockchain network into merged chain codes and merged channels. In some embodiments, merging the chain codes can include merging a first chain code from the first blockchain network with a second chain code from the second blockchain network, and combining key-value pairs of the first chain code and the second chain code into a state database of the merged chain code.

[0093] In some embodiments, the merging can include detecting a first chaincode of a first blockchain network that includes the same code as a second chaincode of a second blockchain network; deleting the second chaincode; and configuring the first chaincode to operate on key-value pairs created by the second chaincode. In some embodiments, the merging can include detecting that an output of a first chaincode of a first blockchain network is linked to an input of a second chaincode of a second blockchain network; adding the first chaincode to the second chaincode to generate a merged chaincode; and configuring the merged chaincode to operate on key-value pairs created by the first chaincode and the second chaincode. In some embodiments, the merging can include merging blockchain peers from a first blockchain network and blockchain peers from a second blockchain network onto a common channel in a merged blockchain network. In some embodiments, the merging can include merging a first blockchain of a first blockchain network and a second blockchain of a second blockchain network on a merged channel of a merged blockchain network via a merge block.

[0094] In some embodiments, the merging can include merging at least three blockchain networks including a first blockchain network and a second blockchain network, and at least one more blockchain network, to produce one larger combined blockchain network. Here, the system can merge the three or more blockchain networks simultaneously or sequentially, e.g., one at a time, to generate the larger combined blockchain network.

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

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

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

[0098] FIG. 6D A system 660 including a blockchain, according to example embodiments, is shown. Referring to FIG. 6D In the example, an application programming interface (API) gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, the API gateway 662 is a public interface for performing transactions (invocations, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., the server 654). Here, the server 654 is a blockchain network peer component that holds a copy of the world state and distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions into the blockchain network, where endorsing peers will run the smart contract 630 according to the smart contract 630 and endorsement policies.

[0099] The above embodiments can be implemented in hardware, computer program executed by a processor, firmware or a combination thereof. The computer program can be embodied on a computer readable medium, such as a storage medium. The computer program can reside, for example, in random access memory ("RAM"), flash memory, read only memory ("ROM"), erasable programmable read only memory ("EPROM"), electrically erasable programmable read only memory ("EEPROM"), registers, hard disk, a removable disk, a compact disk read only memory ("CD-ROM"), or any other form of storage medium known in the art.

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

[0101] FIG. 7A A process 700 of a new block being added to a distributed ledger 720 is shown in accordance with example embodiments, FIG. 7B The contents of a new data block structure 730 for a blockchain in accordance with example embodiments are shown. Reference is made to FIG. 7A A client (not shown) can submit a transaction to the blockchain nodes 711, 712, and / or 713. The client can be an application acting on behalf of a requestor (such as a device, person, or entity) to propose a transaction on the blockchain 720. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) can maintain the state of the blockchain network and a copy of the distributed ledger 720. There can be different types of blockchain nodes / peers in the blockchain network, including peers that endorse and endorse simulated transactions proposed by clients and peers that commit validated endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 can perform the role of an endorser node, a committer node, or both.

[0102] 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 can be a distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which it is a member. The blockchain 722 is a transaction log, structured as a hash-linked chain of blocks, where each block contains a sequence of N transactions. A block can include various components, such as shown in FIG. 3B. The link of blocks (by FIG. 7B FIG. 7A ​The block header of the current block (shown by the arrow in FIG. 7B) can be generated by adding the hash of the header of the previous block within the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash chain. Moreover, because of the chaining, the latest block in the blockchain 722 represents every transaction that occurred before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0103] The current state of the blockchain 722 and distributed ledger 722 can be stored in a state database 724. Here, the current state data represents the latest values of all keys that were ever included in the chain transaction log of the blockchain 722. Chain invocations execute transactions against the current state in the state database 724. To make these chain code interactions extremely efficient, the latest values of all keys are stored in the state database 724. The state database 724 can include an indexed view of the transaction log that goes into the blockchain 722, so it can be regenerated from the chain at any time. The state database 724 can be automatically restored (or generated if needed) at peer startup, before transactions are accepted.

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

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

[0106] The ordering service 710 can be composed of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 can accept endorsed transactions and designate the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network can be designed such that the specific implementation of the 'ordering' (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

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

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

[0109] REFERENCE FIG. 7B The new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 can include multiple data segments, such as a block header 740, block data 750 (block data segment), and block metadata 760. It should be understood that the various described blocks and their contents (e.g., the new data block 730 and its contents) are merely examples and are not intended to limit the scope of the example embodiments. In a regular block, the data portion can store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750. FIG. 7B

[0110] The new data block 730 can include a reference to a previous block (e.g., the block 720) within the block header 740. The block header 740 can include a block number, a block hash, a previous block hash, a transaction count, a timestamp, and a sequence number. The block number can be a number that identifies the block. The block hash can be a hash of the block data 750. The previous block hash can be a hash of the previous block (e.g., the block 720). The transaction count can be a number that identifies the number of transactions in the block data 750. The timestamp can be a time that the block was created. The sequence number can be a number that identifies the order of the block in the blockchain 722. FIG. 7A ​The block header 740 can include a link to the previous block (e.g., a link to the previous block in the blockchain 722). Specifically, the block header 740 can include a hash of the header 741 of the previous block. According to different embodiments, if the new data block 730 is a merge block for merging multiple blockchains together, the block header 740 can also include a hash of the header 742 of a second previous block (or more depending on how many blockchains are merged together). The block header 740 can also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 can be unique and assigned in different orders, such as an increasing / continuous order starting from zero.

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

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

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

[0114]

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

[0116]

[0117]

[0118] In FIG. 7C an example embodiment, the blockchain 770 includes a plurality of blocks 7781, 7782,..., 778 N where N > 1. The encryption used to link the blocks 7781, 7782,..., 778 N may be any of a plurality of keyed or non-keyed hash functions. In one embodiment, the blocks 7781, 7782,..., 778 N are subjected to a hash function that produces an n-bit alphanumeric output from an input based on the information in the block (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, time-based algorithms, and non-collision resistant PRF algorithms. In another embodiment, the blocks 7781, 7782,..., 778 N may be encrypted linked by a function other than a hash function. For purposes of illustration, the following description refers to a hash function (e.g., SHA-2).

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

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

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

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

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

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

[0125] 2) an originating device ID

[0126] 3) a start timestamp of the original file

[0127] 4) an initial storage location of the original file

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

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

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

[0131] The file 7742 to 774 N in the other blocks can be equal to the original file or can be a modified version of the original file in the genesis block, depending on, e.g., the type of processing performed. The type of processing performed can vary from block to block. The processing can involve, e.g., any modification to the files in the preceding blocks, such as editing information or otherwise changing the contents of the files, taking information away from these files, or adding or appending information to these files.

[0132] Additionally or alternatively, the processing can involve copying the files from the preceding blocks only, changing the storage location of the files, analyzing the files from one or more preceding blocks, moving the files from one storage or memory location to another, or performing an action with respect to the files of the blockchain and / or their associated metadata. The processing involving analyzing the files can include, e.g., appending, including, or otherwise associating different analytics, statistics, or other information associated with the file.

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

[0134] For example, consider the case where a portion of a file in a previous block is edited, blocked, or pixelated in order to protect the identity of a person shown in the file. In this case, a block that includes the edited file will include metadata associated with the edited file, e.g., how the edit was performed, who performed the edit, a timestamp when the edit occurred, etc. The metadata can be hashed to form 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 can be recovered upon decryption.

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

[0136] a) if the file has been processed in any way (e.g., if the file is edited, copied, changed, accessed, or takes some other action), the hash value of the new SHA-2 calculation

[0137] b) the new storage location of the file

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

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

[0140] FIG. 7D An embodiment of a block that can represent a block structure in a blockchain 790 is shown in accordance with one embodiment. The block block i includes a header 772 i , a file 774 i , and a value 776 i .

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

[0142] The file 774 iincludes multiple data, such as data 1, data 2,..., data N in order. The data is tagged with metadata 1, metadata 2,..., metadata N describing content and / or characteristics associated with the data. For example, the metadata for each data can include a timestamp indicating the data, processing data, keywords indicating a person or other content depicted in the data, and / or other features that can contribute to establishing the validity and content of the file as a whole, and in particular its use of digital evidence, e.g., as described in connection with the embodiments discussed below. In addition to the metadata, each data can be tagged with references to prior data, reference 1, reference 2,..., reference N, indicating the data that the data is referencing. The references can be in the form of a hash value, a pointer to a location in the file, or other reference to the data being referenced. The references can be used to establish the chain of custody of the file, and in particular the data being referenced, and to establish the authenticity of the file and the data being referenced. N to prevent tampering, gaps in the file, and sequential references through the file.

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

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

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

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

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

[0148] FIG. 8A and FIG. 8B Further examples of use cases in which a blockchain can be incorporated and used are shown. In particular, FIG. 8A An example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models in order to make accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to mine non-intuitive patterns.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0167] The computer system / server 902 can also communicate with one or more external devices 920 such as a keyboard or a pointing device, displays 922, etc.; and / or one or more other computers or devices using any means including a network. Such communication can occur via I / O interface(s) 924. Still yet, computer system / server 902 can communicate with one or more networks using network interface 926, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter. As depicted, network interface 926 communicates with the other components of computer system / server 902 via the bus. It should be appreciated that although not shown, other hardware and / or software components could be used in conjunction with computer system / server 902. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0168] While example embodiments of at least one of a system, method, and non-transitory computer readable medium have been illustrated and described in the drawings and detailed description above, it will be understood that the application is not limited to the embodiments disclosed, but instead has many rearrangements, modifications, and substitutes within its scope as set forth and defined by the following claims. For example, the capabilities of the systems of the different figures can be performed by one or more modules or components described herein or in the distributed architecture, and can include transmitter, receiver, or both. For example, all or a portion of the functions performed by separate modules can be performed by one or more of the modules. Further, the functions performed by the modules can be performed at different times and in relation to different events than depicted and described herein. Moreover, the information sent between the various modules can be sent via data networks, the Internet, telephone networks, Internet Protocol networks, wireless devices, wired devices, and / or between the modules via at least one of a plurality of protocols. Also, messages sent by any of the modules can be sent directly and / or via one or more other modules.

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

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

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

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

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

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

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

Claims

1. An apparatus comprising: a processor configured to receive a request to merge a first blockchain network and a second blockchain network, the request including a script specifying a network structure, synthesize the script with the configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations, and merge the first blockchain network with the second blockchain network based on the plurality of merge operations to create a merged blockchain network, wherein the processor merges chaincode and channels from the first blockchain network and the second blockchain network into merged chaincode and merged channels; wherein the processor is further configured to configure the merged chaincode including first chaincode of the first blockchain network and second chaincode of the second blockchain network to operate on key-value pairs created by the first chaincode and the second chaincode.

2. The apparatus of claim 1, wherein, the processor is further configured to construct the script based on user input received via a user interface.

3. The apparatus of claim 1, wherein, the processor is configured to parse the script to generate an initial state of the first blockchain network and the second blockchain network prior to the merge and a final state of the merged blockchain network after the merge, and determine a sequence of operations to be performed to transform the initial state into the final state.

4. The apparatus of claim 1, wherein, the processor is configured to merge first chaincode from the first blockchain network with second chaincode from the second blockchain network and combine key-value pairs of the first chaincode and the second chaincode into a state database of the merged chaincode.

5. The apparatus of claim 1, wherein, the processor is configured to detect that first chaincode of the first blockchain network includes the same code as second chaincode of the second blockchain network, delete the second chaincode, and configure the first chaincode to operate on key-value pairs created by the second chaincode.

6. The apparatus of claim 1, wherein, the processor is configured to detect that an output of the first chaincode of the first blockchain network is linked to an input of the second chaincode of the second blockchain network, add the first chaincode to the second chaincode to generate the merged chaincode.

7. The apparatus of claim 1, wherein, the processor is configured to merge blockchain peers from the first blockchain network and blockchain peers from the second blockchain network onto a common channel in the merged blockchain network.

8. The apparatus of claim 1, wherein, the processor is configured to merge a first blockchain of the first blockchain network with a second blockchain of the second blockchain network via a merge block on a merged channel of the merged blockchain network.

9. The apparatus of claim 1, wherein, the processor is configured to merge three or more blockchain networks including the first blockchain network and the second blockchain network to generate one combined blockchain network.

10. A method comprising: receiving a request to merge a first blockchain network and a second blockchain network, the request including a script specifying a network structure; synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations; and and based on the plurality of merge operations, merging the first blockchain network and the second blockchain network to create a merged blockchain network, wherein the merging includes merging chaincode and channels from the first blockchain network and the second blockchain network into merged chaincode and merged channels; wherein the merged chaincode, including first chaincode of the first blockchain network and second chaincode of the second blockchain network, is configured to operate on key-value pairs created by the first chaincode and the second chaincode.

11. The method of claim 10, further comprising building the script based on user input received via a user interface.

12. The method of claim 10, wherein, the synthesizing includes parsing the script to generate initial states of the first blockchain network and the second blockchain network prior to the merging and final states of the merged blockchain network after the merging, and determining a sequence of operations to be performed to transform the initial states into the final states.

13. The method of claim 10, wherein, the merging chaincode includes merging first chaincode from the first blockchain network with second chaincode from the second blockchain network, and combining key-value pairs of the first chaincode and the second chaincode into a state database of the merged chaincode.

14. The method of claim 10, wherein, the merging includes: detecting a first chaincode of the first blockchain network that includes the same code as a second chaincode of the second blockchain network, deleting the second chaincode, and configuring the first chaincode to operate on key-value pairs created by the second chaincode.

15. The method of claim 10, wherein, the merging includes: detecting that an output of the first chaincode of the first blockchain network is linked to an input of the second chaincode of the second blockchain network, adding the first chaincode to the second chaincode to generate the merged chaincode.

16. The method of claim 10, wherein, the merging includes merging blockchain peers from the first blockchain network and blockchain peers from the second blockchain network onto a common channel in the merged blockchain network.

17. The method of claim 10, wherein, the merging includes merging a first blockchain of the first blockchain network and a second blockchain of the second blockchain network via a merge block on a merged channel of the merged blockchain network.

18. The method of claim 10, wherein, the merging includes merging three or more blockchain networks, including the first blockchain network and the second blockchain network, to generate one combined blockchain network.

19. A non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform a method comprising: receiving a request to merge a first blockchain network and a second blockchain network, the request including a script specifying a network structure; synthesizing the script with configuration data of the first blockchain network and the second blockchain network to generate a plurality of merge operations; and based on the plurality of merge operations, merging the first blockchain network and the second blockchain network to create a merged blockchain network, wherein the merging includes merging chaincode and channels from the first blockchain network and the second blockchain network into merged chaincode and merged channels; The merged chaincode that includes the first chaincode of the first blockchain network and the second chaincode of the second blockchain network is configured to operate on key-value pairs created by the first chaincode and the second chaincode.

20. The non-transitory computer-readable medium of claim 19, wherein, The method further includes constructing the script based on user input received via a user interface.

Images