CN112005264A

CN112005264A - Blockchain implementing cross-chain transactions

Info

Publication number: CN112005264A
Application number: CN201980027683.0A
Authority: CN
Inventors: H·T·沃; L·梅赫迪; M·K·莫哈尼亚; 王子元; E·阿贝贝
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2018-05-01
Filing date: 2019-04-29
Publication date: 2020-11-27
Also published as: JP2021520539A; EP3788578A1; WO2019211225A1; JP7324222B2

Abstract

Example operations may include one or more of: receiving a request to execute a cross-chain transaction, identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored, retrieving data from data blocks of the two or more different blockchains, respectively, according to the identified different locations, executing the cross-chain transaction, the cross-chain transaction taking the retrieved data from the two or more different blockchains as input to generate a cross-chain result, and storing the cross-chain result through data blocks of a distributed ledger.

Description

Blockchain implementing cross-chain transactions

Technical Field

The present application relates generally to partitioning transactional (transaction) data across multiple blockchains, and more particularly, to implementing blockchains of cross-chain transactions.

Background

Ledgers (hedgers) are generally defined as entries of ledgers in which transactions are recorded and visible to authorized users. A distributed ledger is a ledger that is replicated, in whole or in part, to multiple computing systems. One type of distributed ledger is a Cryptographic Distributed Ledger (CDL), which may have at least some of the following characteristics: irreversibility (once a transaction is recorded, it cannot be undone), accessibility (any party can access the CDL in whole or in part), chronological and time stamping (parties know when to add the transaction to the ledger), consensus-based (transactions are added only when they are generally agreed to by parties on the network), verifiability (all transactions can be cryptographically verified). A blockchain is an example of a CDL. Although the description and drawings herein are described in terms of a blockchain, the present application is equally applicable to any CDL.

Distributed ledgers are an ever-increasing list of records that typically apply cryptographic techniques, such as storing cryptographic hashes related to other blocks. Although primarily used for financial transactions, the blockchain may store other assets, such as information related to goods and services (i.e., products, packaging, status, software, data, etc.). A decentralized scheme provides authority and trust for a decentralized network and enables its nodes to continuously and sequentially record their transactions on a common "block," thereby creating a unique "chain" called a blockchain. The password is used to ensure authentication of the transaction source and to delete the central intermediary through a hash code. In addition, each block contains a timestamp and a link to the previous block, thereby creating a tamper-resistant chain of transaction records. Since the blockchain is a distributed system, peers need to reach a consensus state before adding a transaction to the blockchain ledger.

Limited transaction throughput and storage are widely understood issues with blockchain technology. Some techniques have attempted to improve transaction throughput. For example, blockchains in bitcoins use a workload proof consensus method that is easy to verify, but computationally expensive (by design), and requires cryptographic challenges to be resolved in the process. Another example is that the licensed blockchain uses a consensus method based on byzantine (byzantine) fault tolerant (BFT) state machine variants. These BFT state machines are selected to provide higher transaction throughput and lower consensus latency, but still do not provide the throughput required by many industries. That is, even with these improvements, current blockchain technology is not suitable for large-scale data processing workloads that are common in many practical applications in finance, insurance, software development, supply chain, transportation industries, and the like. Therefore, a mechanism to extend blockchain throughput is needed.

Accordingly, there is a need in the art to address the foregoing problems.

Disclosure of Invention

Viewed from a first aspect, the present invention provides a system for managing a blockchain, the system comprising: a network interface to receive a request to perform a cross-chain transaction; and a processor for: identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored; retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations; executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and storing the cross-chain result through a data block of a distributed ledger.

Viewed from another aspect, the present invention provides a method for managing a blockchain, the method for managing a blockchain comprising: receiving a request to execute a cross-chain transaction; identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored; retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations; executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and storing the cross-chain result through a data block of a distributed ledger.

Viewed from another aspect the present invention provides a computer program product for managing a blockchain, the computer program product comprising a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing the steps of the present invention.

Viewed from another aspect, the present invention provides a computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, comprising software code portions, when said program is run on a computer, for performing the steps of the invention.

An example embodiment may provide a method comprising one or more of: receiving a request for executing a cross-chain transaction, and receiving a request for executing a cross-chain transaction; identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored; retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations; executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and storing the cross-chain result through a data block of a distributed ledger.

Another exemplary embodiment may provide a system comprising: a network interface to receive a request to perform a cross-chain transaction; and a processor configured to perform one or more of: identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored; retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations; executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and storing the cross-chain result through a data block of a distributed ledger.

Another exemplary embodiment may provide a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a request to execute a cross-chain transaction; identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored; retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations; executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and storing the cross-chain result through a data block of a distributed ledger.

Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 is a diagram illustrating a system for managing cross-chain transactions in accordance with an illustrative embodiment;

fig. 2 is a diagram illustrating a peer node blockchain architecture configuration in accordance with an example embodiment;

fig. 3 is a diagram illustrating a block chain network showing permissions, according to an example embodiment;

FIG. 4A is a diagram illustrating a process of managing a backbone of a data partition across multiple partition blockchains in accordance with an example embodiment;

FIG. 4B is a diagram illustrating a process of performing a hybrid chain of cross-chain transactions based on data from multiple partition blockchains in accordance with an illustrative embodiment;

FIGS. 5A and 5B are diagrams illustrating a method of managing cross-chain transactions according to an example embodiment;

fig. 6A is a diagram illustrating a physical infrastructure configured to perform various operations on a blockchain according to one or more operations described herein, according to an example embodiment;

FIG. 6B is a diagram illustrating a smart contract configuration between a contracting party and a mediation server configured to enforce smart contract terms on a blockchain, according to an example embodiment;

FIG. 7 is a diagram illustrating a computer system configured to support one or more example embodiments.

Detailed Description

It will be readily understood that the instant components, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of at least one of the methods, apparatus, non-transitory computer readable media, and systems, as illustrated in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

The instant features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout the specification, use of the phrase "example embodiments," "some embodiments," or other similar language refers to the fact that: a particular feature, structure, or characteristic described in connection with the embodiment may be included within at least one embodiment. Thus, appearances of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In addition, although the term "message" may have been used in the description of the embodiments, the present application may be applied to many types of network data, such as packets, frames, datagrams, and the like. The term "message" also includes packets, frames, datagrams and any equivalent thereof. Further, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to a particular type of message, and the application is not limited to a particular type of signaling.

Example embodiments are directed to methods, devices, networks, and/or systems supporting a master blockchain system. The system includes a blockchain network including a master blockchain that performs the role of a coordinator or transaction router between blockchains, a set of partition blockchains that store partition data. In addition, the system includes a hybrid blockchain that retrieves data from the multiple blockchains and performs cross-chain transactions by utilizing the data from the multiple blockchains. Some of the benefits of blockchain systems are that it increases the capacity of blockchain based systems in terms of storage and transaction throughput. In particular, a multiple (partitioned) blockchain network may provide greater storage capacity (in the aggregate) to store transactional data than a single blockchain network, and may further support large numbers of concurrent transactions committed from applications.

Blockchains differ from traditional databases in that blockchains are not centrally stored, but are decentralized, immutable, and secure storage, where nodes must share changes to records in the storage. Some attributes inherent to the blockchain that help enable the blockchain include, but are not limited to, immutable ledger, intelligent contracts, security, privacy, decentralization, consensus, approval, accessibility, and the like.

According to various aspects, the partition functions and cross-chain execution functions are implemented by newly defined intelligent contracts that are inherent and unique to the blockchain. Additionally, example embodiments also provide a system-based transaction router intelligence contract configured to manage data partitioning between multiple blockchains by accessing system resources, such as network interfaces. In response to receiving a request to execute a transaction, a transaction router (of the master chain) intelligent contract may identify a plurality of different blockchains having data for executing the transaction and provide locations of the different blockchains to a cross-chain of processing intelligent contracts (of the hybrid chain). A cross-chain that processes an intelligent contract may retrieve data from different blockchains, perform a cross-chain transaction, and update the different blockchains based on the results of the cross-chain transaction.

In addition, additional blockchain attributes, such as consensus, endorsement, and decentralized/distributed nodes, are responsible for implementing the technical effect of partitioning rules that determine which partitions (single blockchain) to route incoming transactions. In particular, consensus of participants (nodes) in the master blockchain may agree on a common partition rule that a transaction router intelligence contract may use to route incoming transactions to the appropriate partition chain. In one example, a single chain transaction is simply routed to the corresponding partition chain that stores the data. As another example, when a transaction involves data from multiple partition chains, the transaction may be routed to a mixed chain block chain that includes a cross-chain processor that may retrieve the data and perform a cross-chain transaction. In some embodiments, the hybrid chain may also maintain its own blockchain in which immutable records of hash links across chain transactions are stored.

The example embodiments provide numerous benefits over traditional databases. For example, over a network of blockchains, embodiments provide increased throughput and storage availability while also maintaining the required level of trust and responsibility for the blockchains. Meanwhile, traditional databases cannot be used to implement the example embodiments because traditional databases do not provide consensus between nodes and therefore will rely on a single participant to decide how to partition the database. In this way, individual participants can modify the partitioning scheme at their discretion, without having to rely on the consensus required by the backbone. Furthermore, traditional databases do not perform blockchain based transactions, where the transaction certificate is stored in an immutable ledger, which can only be modified through consensus and endorsements.

In conventional databases, data partitioning is typically employed to combat data scalability, data isolation, and transaction throughput issues within the database. Furthermore, newer storage technologies such as blockchains continue to suffer from similar problems. In particular, with increasing interest in using licensed blockchains (e.g., Hyperhedger Fabric) to maintain transaction histories for business networks, business networks face the same technical hurdles. Currently, none of the current blockchain techniques suggest a viable solution to extend the transaction throughput of blockchains by dividing data among multiple blockchains. This is because for blockchain based applications, data partitioning is not a simple solution and there are some technical challenges to solve. For example, since blockchains use consensus among parties to maintain data invariance and trust, data partitioning also needs to provide the same level of trust, accountability, and traceability. To address this issue, the system described herein may support "cross-chain" transactions when dividing data into multiple blockchains, thereby accommodating traffic networks that evolve over time. In addition, the system can partition data across multiple blockchains to support data partitioning as well as cross-chain transactions while maintaining trust, accountability, and traceability. In particular, a blockchain system is capable of (a) dividing data between a plurality of blockchains; (b) cross-chain transactions are supported, and (c) trust, provenance, and traceability are maintained.

In one embodiment, the present application relates to partitioning transactional data across multiple blockchains, and in another embodiment, to a blockchain implementing a cross-chain transaction.

Fig. 1 illustrates a blockchain system 100 for managing cross-chain transactions, in accordance with various example embodiments. Referring to fig. 1, a system 100 includes a backbone network 110 (backbone), a hybrid chain network 120 (hybrid chain), and a plurality of partitioned blockchain networks. The blockchain networks may be connected to each other via a network 140, such as a private network, the internet, and the like. The system 100 can use a combination of block chains to store transactions related to a partitioned data model in a business network, thereby supporting the scalability of the business network, which can dynamically extend storage capacity and transaction throughput over time as more storage space is required and/or transaction data grows. In general, the proposed system includes a main chain 110 for routing incoming transactions and queries to the appropriate partition (i.e., hybrid chain 120 or partition chain 132-136) where they can be processed. Meanwhile,

partition chains

132 and 136 are each responsible for maintaining data in partitions throughout the data domain. Further, hybrid chain 120 may handle transactions that access data across multiple partitions.

The backbone 110 is a mechanism for routing transactions based on policies that are trusted by each party in the network. If instead a centralized router is used, the trustworthiness of the entire system will depend on a single entity not meeting the block chain requirements. Thus, the main chain 110 may maintain and track changes in partitioning rules via a blockchain that includes chains of blocks that are hash-linked together. Once the partitioning policy is stored in the blockchain of the main chain 110, the various blockchain link points in the main chain 110 may route transactions to other different blockchain networks (e.g., hybrid chain 120,

partition chain

132, 136, etc.) based on the partition rules stored in the main chain. The partition rules/information stored by the main chain 110 may include a range of data assigned to each of the

different partition chains

132, 134, and 136 that identifies the data stored on each partition chain. Further, the main chain 110 may store the network endpoints of each

partition chain

132, 134, and 136, enabling data to be retrieved from one or more nodes of the

partition chains

132, 134, and 136.

According to various aspects, the backbone 110 may receive requests to process transactions involving different data stored in several different blockchains, referred to herein as cross-chain transactions. One option for handling cross-chain transactions is to migrate data from multiple chains to a particular chain and then execute the transaction on that chain. However, this approach is not a viable solution as it would introduce unnecessary delay and instability in the network. Rather, the system 100 includes a hybrid chain 120, which hybrid chain 120 processes cross-chain transactions provided by the main chain 110 by accessing data from different blockchains and creating transactions involving different data chains to create a mix of transactional data between the different chains.

Transactional data may be partitioned among multiple partitioned

blockchains

132, 134, and 136. The main chain 110 may efficiently identify the location of data from these blockchains by building an index based on the intelligent contract of the query. For example, the query may provide the backbone 110 with locations for previously unaccessed transaction data. Furthermore, the actual routing module, although using the partitioning rules stored in the backbone 110, still needs to be trusted. Thus, the routing module (i.e., transaction router) may be integrated with the block-node software. For example, the routing module may be implemented by a special type of intelligent contract/chaining code, such as the system chaining code available in HyperLegendr Fabric 1.0. The system chain code may be an integral part of the blockchain software modules. In contrast to typical intelligent contracts that access data on a chain, system intelligent contracts may be designed with system-level access rights that would otherwise not be available for traditional intelligent contracts that should run in a sender-box (sandbox).

Fig. 2 shows a block chain architecture configuration 200 of a block chain according to an example embodiment. Configuration 200 may be an example of a conventional blockchain, such as the partitioned blockchain shown in fig. 1. Referring to fig. 2, the blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain link points 202. Block chain node 202 may include one or more nodes 204 and 210 (4 nodes are described by way of example only). These nodes are involved in many activities such as blockchain transaction addition and verification processes (consensus). One or more of the blockchain nodes 204-210 may approve the transaction and may provide subscription (ordering) services for all blockchain link points in the architecture 200. The blockchain link point may initiate blockchain authentication and attempt to write a blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may 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., chain code, intelligent contracts, etc.), which may be created according to custom configurations sought by participants, and may maintain their state, control their assets, and receive external information. It may be deployed as a transaction and installed on all blockchain nodes 204 and 210 by attaching into the distributed ledger.

Blockchain foundation or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors that are seeking to access data entries. The blockchain layer 216 may expose an interface that provides access to the virtual execution environment necessary to process program code and use the physical infrastructure 214. The cryptographic trust service 218 may be used to validate transactions such as asset exchange transactions and keep information private.

The blockchain architecture configuration of fig. 2 may process and execute program/application code 220 through one or more interfaces exposed and services provided by blockchain platform 212. Code 220 may control blockchain assets. For example, code 220 may store and transmit data and may be executed by node 204 and 210 in the form of intelligent contracts and associated chain code, with the associated chain code having conditions or other code elements constrained by its execution. By way of non-limiting example, a smart contract may be created to perform reminders, updates, and/or other notifications of changes, updates, and the like. The smart contracts themselves may be used to identify rules related to authorization, access requirements, and ledger usage. For example, transaction data 226 may be processed by one or more processing entities (e.g., virtual machines) included in blockchain layer 216. Transaction data 226 may include hash-linked data block chains that link together transactions executed through the blockchain. For example, the latest transaction may be stored at the end of the blockchain. Transaction results 228 may include transaction data 226 that is mixed with data from another blockchain through cross-chain transactions. Physical infrastructure 214 may be used to retrieve any data or information described herein.

In chain code, intelligent contracts can be created by high-level applications and programming languages and then written into blocks in a blockchain. The smart contract may include executable code that is registered, stored, and/or replicated by a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of intelligent contract code that may be executed in response to a condition associated with an intelligent contract being satisfied. Execution of the intelligent contract may trigger a trusted modification of the digital blockchain ledger state. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

The intelligent contract may write data to the blockchain in a key-value pair format. In addition, the intelligent contract code may read values stored in the blockchain and use them in application operations. The intelligent contract code may write the output of various logical operations into a blockchain. The code may be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain may be public and/or may be encrypted and maintained private. Temporary data used/generated by the smart contracts is saved in memory by the provided execution environment and, once the data needed by the blockchain is identified, it is deleted.

The chain code may include a code interpretation of the intelligent contract with additional features. As described herein, the chain code can be program code deployed on a computing network where the chain code executes and is verified by a chain code verifier in a consensus process. The chain code receives the hashes and retrieves the hashes from the blockchain associated with the data template created using the previously stored feature extractor. If the hash value of the hashed identifier matches the hash value created from the stored identifier template data, the chain code sends the authorization key to the requesting service. The chain code may write data associated with the cryptographic details to the block chain. In FIG. 2, chain code may introduce modifications to an asset by storing a data block representing the result of executing a transaction. One function may be to add new values to the asset, change the value of the asset, delete the value of the asset, etc., which may be assigned to and stored by one or more of the nodes 204 and 210.

The client may send a request to execute a blockchain transaction (e.g., a cross-chain transaction), and may include an application that utilizes a supported Software Development Kit (SDK), such as a NODE,

PYTHON, etc., which utilizes available Application Programming Interfaces (APIs) to generate cross-chain transaction offers. The proposal is a request to invoke a chain code function so that data can be read and/or written to one or more ledgers for different blockchains (i.e., to write new key-value pairs for the asset). The SDK may act to package the transaction offer asA wedge in an appropriate architectural format (e.g., a proposal buffer via Remote Procedure Call (RPC)), and generates a unique signature for the transaction proposal using the client's cryptographic credentials. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its branches.

The chain code may be executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates to the account book have been made at this time. Instead, these value sets, as well as signatures of endorsed peer nodes, may be passed back to the client's SDK as a response to the proposal, which resolves the payload used by the application.

In response, the client's application checks/verifies the endorsed peer's signature and compares the proposed responses to determine if the proposed responses are the same. If the chain code only queries the ledger, the application will check the query response and will not typically submit the transaction to the subscribing node for service. If the client application intends to submit the transaction to the subscribing node service to update the ledger, the application will determine if the specified endorsement policy has been satisfied prior to submission (i.e., all peer nodes necessary for the transaction are endorsed on the transaction). Here, the customer may include only one of the parties to the transaction. In this case, each client may have its own approval node, and each approval node needs to approve the transaction. The architecture is such that the approval policy will be enforced by the peer and retained during the commit validation phase even if the application chooses not to check the response or otherwise forward the non-approved transaction.

After a successful check, the customer assembles the endorsement into a transaction and broadcasts the transaction proposal for the asset and the response within the transaction message to the subscribing nodes. The transaction may contain a read/write set, an endorsed peer signature, and a channel ID. The subscribing node need not examine the entire contents of the transaction to perform its operations, but rather the subscribing node may simply receive transactions from all channels in the network, order them in chronological order by channel, and create a transaction block for each channel.

Fig. 3 illustrates an example of a single blockchain licensed blockchain network 300 featuring a distributed, decentralized peer-to-peer architecture and a certificate authority 318 that manages user roles and licenses. Any of the main chain, hybrid chain, and partition chain may be a licensed blockchain network 300. In this example, blockchain user 302 may submit a transaction to an allowed blockchain network 310. The transaction may be a deployment, call, or query, and may be issued directly through a REST API or the like, through a client application that utilizes the SDK. The trusted business network may provide access to a supervisor system 314, such as an auditor (e.g., the securities business commission in the U.S. stock market). At the same time, the blockchain network operator system 308 of the node manages member permissions, such as registering the supervisor system 310 as an "auditor" and registering the blockchain user 302 as a "client. Auditors may be limited to querying the ledger, and customers may be authorized to deploy, invoke, and query certain types of chain codes.

Blockchain developer system 316 writes chain code and client applications. Blockchain developer system 316 can deploy the chain code directly to the network through the REST interface. To include the credentials from the legacy data source 330 in chain code, the developer system 316 may access the data using an out-of-band connection. In this example, blockchain user 302 connects to the network through peer node 312. Before any transaction is conducted, peer node 312 retrieves the user's registration and transaction credentials from certificate authority 318. In some cases, the blockchain user must possess these credentials in order to conduct transactions on the licensed blockchain network 310. At the same time, a user attempting to drive the chain code may be required to verify their credentials on the legacy data source 330. To confirm the user's authorization, the chain code may be coupled to the data using out-of-band by the legacy processing platform 320.

Fig. 4A illustrates a process 400A of a main chain 410 managing data partitioning across multiple partition blockchains according to an example embodiment, and fig. 4B illustrates a process 400B of a hybrid chain 420 performing a cross-chain transaction based on data from multiple partition blockchains according to an example embodiment. Referring to FIG. 4A, backbone 410 manages blockchain 412, which blockchain 412 includes a chain of hashed linked blocks of partition information about how data is divided between

different partition blockchains

432, 434, and 436. The entire domain may be divided into subzones or subsets, with each chain of partition blocks 432, 434, and 436 including a unique subzone or subset that does not include other chains of partition blocks. In addition, blockchain 412 may store information identifying the network location (e.g., endpoint, URL, etc.) of the nodes of each

partition blockchain

432, 434, and 436 for use in retrieving and providing transaction data.

For example, the functionality of the backbone 410 may be implemented via three corresponding smart contracts. In one example, partition intelligence contracts 414 maintain consensus among parties (backbone nodes) on partition functionality that determines how an entire data domain may be partitioned, e.g., range boundaries of data maintained in each partition of the data domain assigned to each

partition block chain

432 and 436. Backbone 410 may also include transaction router intelligence contracts 416, which transaction router intelligence contracts 416 route incoming transactions to the appropriate chain responsible for processing the transactions (according to the partition function). For example, a single chain transaction may be routed directly to a single chain storing transaction data. Meanwhile, cross-chain transactions may be routed to hybrid chain 420 for processing. The routing information may be identified from the partition information stored in the blockchain 412.

Backbone 410 may also include query federation intelligence contracts 418 that are responsible for processing queries from clients. In some embodiments, partition intelligent contracts 414 may be intelligent contracts that run within each peer node in the backbone based on-chain data, while transaction routers 416 and query federators 418 may be special system intelligent contracts (a.k.a. system chain code) that have system-level functionality to access various other software components in the host node, but are not available to conventional intelligent contracts running in the send box (Sendbox). Also,

partition blockchains

432, 434, and 436 may be a traditional blockchain network that maintains different partitions of the entire data domain without knowledge of the entire domain. Each partition chain may run an intelligent contract for a single chain of processors that receives transaction and query requests from the backbone 410 and executes those requests.

Referring to FIG. 4B, hybrid chain 420 receives a cross-chain transaction from backbone 410 and executes the cross-chain transaction. For example, the request received from the backbone 410 may include a network location of a blockchain network in which data for the cross-chain transaction is stored. Thus, hybrid chain 420 may identify which of

multiple partition blockchains

432, 434, and 436 have data for cross-chain transactions. Hybrid chain 420 includes cross-chain processor intelligence contracts 424, which receive transaction requests from backbone 41 and are responsible for accessing data across multiple partitions. In addition, the cross-chain processor 424 executes cross-chain transactions, mixing data from different partition blockchains together to create a mixed result. Cross-chain processor 424 may store the results of cross-chain transactions in blockchain 422, which links the results of all cross-chain transactions executed in the system together. In addition, the cross-chain processor 424 may also update the partition blockchain that provided the data for the transaction with the results of the cross-chain transaction to enable the partition blockchain to update the data/assets stored therein.

According to various embodiments, the main chain 410 may be initialized with information of the endpoints of the other blockchains (420, 432, 434, and 436). In backbone 410, each party in the network may reach a consensus of out-of-network partition rules, and one authority may invoke the "setPartitionRule" method in partitioner intelligence contracts 414 to set partition rules in blockchain 412. Any changes to the partition rules are also stored in blockchain 412 so that they are traceable. After initialization, partition intelligence contract 414 may set an enable flag so that each node in the backbone can obtain the partition rules and route transactions according to the rules. Additionally, transaction router intelligence contract 416 may first identify which data these transactions access. For example, transaction router 416 may look up partition rules from the blockchain via partition intelligence contracts 414. According to various embodiments, the transaction router 416 next determines to which blockchain network the transaction should be routed. For example, if a transaction only accesses data within a single partition, it will be routed to a particular partition blockchain network. Instead, transactions that access data in multiple partitions are routed to the hybrid chain 420 network for processing.

Meanwhile, the workflow for processing transactions in hybrid chain 420 includes cross-chain processor intelligence contracts 424, which receive transaction and partition information from the transaction routers of the backbone. In response, cross-chain handler 424 retrieves data from a different chain, retains the retrieved data and the new value in its own chain 412, and initiates a separate "setDiff" transaction to update the latest values of different parties in the chain for different partitions. For example, if the balance of "X" is retrieved from "B chain" 434 and the balance of "Y" is retrieved from "a chain" 432, then after the balance is transferred from X to Y, the final difference between X and Y is set for the "setDiff" transaction in "B chain" to be used, and vice versa. Thus, a "mixed chain" will contain cross-chain transactions, but will also update other related chains using a separate "setDiff" transaction to update the values by incremental changes. In some embodiments, if a cross-chain transaction is ongoing and a new incoming transaction accesses some of the same data as the cross-chain transaction, the new transaction may be retained by the transaction router 416 for a determined period of time or discarded immediately.

As another example, if the query accesses data based on partition attributes included in the partition function, the query federator 418 routes the query only to the particular partition chain that maintains the data of interest. Conversely, if the query data is accessed based on non-partition attributes, the query federator 418 may not know where the data is stored between different blockchain partitions. In this case, the query federator 418 may forward the query to each partition chain and aggregate the results returned by the chains before returning to the client.

As depicted, hybrid chain 420 may perform transactions across different partition block chains 432- "436. For example, transaction router 414 may read the subscriber information contained in the incoming transaction as well as the partition rules maintained in its blockchain 412 (i.e., the backbone or partition intelligence contracts). By way of non-limiting example, transaction router 414 may identify the data record associated with user "U1" located in partition A432, rather than the data record associated with user "U2" located in partition B434. In this example, router 414 may update its lock table with information that cross-chain transactions for "U1" and "U2" are ongoing. The transaction may then be forwarded to hybrid chain 420 with details of "U1", "U2", and its blockchain node URLs. In response, cross-chain handler 424 may obtain data for "U1" from partition A432 and "U2" from partition B434. In addition, the cross-chain processor 424 may create transactions in its own blockchain 422. And sends a "SetDiff" transaction to the U1 blockchain (partition a432) with the balance difference of U1 and a separate "SetDiff" transaction to the U2 blockchain (partition B434) with the balance difference of U2.

FIG. 5A illustrates a method 500 of routing transactions for cross-chain processing, according to an example embodiment. For example, method 500 may be implemented via an intelligent contract executed by a block link point within a master block chain network. As another example, method 500 may be performed by a set of computing nodes within a master blockchain network. Referring to fig. 5A, at 510, the method may include storing partition information via a backbone, the partition information linking storage across a plurality of block chains together. For example, the partition information may include partition rules resulting from consensus of the nodes of the backbone. The partitioning rule may identify a range of data stored by each of a plurality of different blockchains and location information, such as a Uniform Resource Locator (URL), for each blockchain. In some embodiments, the method may comprise: the partition information is established in response to detecting a consensus of the partition information from the plurality of block link points of the management backbone.

At 520, the method may include receiving a request from a client to perform a blockchain transaction. For example, a client may request transactions that utilize data from a single blockchain or transactions that utilize data from multiple different blockchains. At 530, the method may include determining, via the backbone, whether a blockchain transaction is associated with data stored on one blockchain or with data separately stored on a different blockchain based on partition information stored on the backbone. For example, a transaction may identify a particular asset or data item, and partition information may identify a storage location of the asset or data item based on a partitioner intelligence contract that manages the backbone and partition information.

In response to a determination that the blockchain transaction is associated with data separately stored on different blockchains, in 540, the method may further include: the location of each blockchain is identified from the different blockchains by the backbone and transmitted to a system configured to perform blockchain transactions. In some embodiments, the transferring may include transferring the location to a cross-chain processor intelligence contract executing on a hybrid chain configured to retrieve respective data from each of the different blockchains and to execute blockchain transactions based on the data retrieved from the different blockchains.

In some embodiments, the partition information identifies an entire domain or range of transaction data managed by the backbone and also identifies a respective subdomain assigned to each respective blockchain of the plurality of blockchains. Here, the partition information or sub-domain information may identify a boundary range of the transaction data maintained by each of the plurality of blockchains.

In some embodiments, the method may further comprise: when the backbone does not include an identification of a blockchain storing data for a blockchain transaction, the plurality of blockchains are individually queried to determine at least one blockchain for storing data for the blockchain transaction. For example, the query may be performed by a query federation intelligence contract executing on a blockchain node, while the determination may be performed by a transaction routing intelligence contract executing on the blockchain node. In some embodiments, the method may further comprise: detecting an enable flag that has been set via the backbone; and obtaining partition information in response to detection of the enable flag.

Fig. 5B illustrates a method 550 of performing a cross-chain transaction based on data from multiple blockchain networks, according to an example embodiment. For example, the method 550 may be performed by a node of a hybrid chain network. Referring to FIG. 5B, in 551, the method may include receiving a request to perform a cross-chain transaction. For example, the request may be received from a backbone that has identified blockchain transactions that require data from different blockchains. At 552, the method can include identifying different locations of two or more different blockchains in which data for the cross-chain transaction has been stored. For example, the hybrid chain may identify a network location of a blockchain node that registers communications with the hybrid chain and has location information (e.g., URL, endpoint, etc.) stored in the backbone. In this example, identifying may include identifying different network locations for accessing two or more different blockchains, respectively, based on two or more URLs included in the request.

In 553, the method may comprise: based on the identified different locations, data is retrieved from data blocks of two or more different blockchains, respectively. For example, retrieving may include transmitting a request from the hybrid chain to blockchain nodes requesting different data items (e.g., data ranges) of data stored on different blockchains for each different blockchain. Here, the data may be unique for each respective blockchain and may not be available from the same blockchain. At 554, the method may include performing a cross-chain transaction that takes as input retrieved data from two or more different blockchains to generate a cross-chain result. For example, performing a cross-chain transaction may result in data retrieved from two or more different blockchains being mixed together, such as by exchanging data, combining data, subtracting data, adding data, modifying data, and so forth.

In 555, the method may include storing the cross-chain result via a data block of the distributed ledger. For example, storing may include inserting a new data block in which information about the cross-chain result is stored into each of two or more different blockchains. In this example, storing may include inserting a new data block, in which information about the cross-chain result is stored, into the first blockchain from among the two or more different blockchains to update the transaction data obtained from the first blockchain with an increment value obtained from the cross-chain result. . In some embodiments, storing may include inserting a new data chunk, in which information about the cross-chain result is stored, into the mixed-chain blockchain based on the generated cross-chain result. In some embodiments, storing may also include linking the new data block inserted into the mixed-chain blockchain to a cross-chain result of another cross-chain transaction previously stored in the mixed-chain blockchain.

Fig. 6A illustrates an example physical infrastructure configured to perform various operations on a blockchain in accordance with example embodiments. Referring to FIG. 6A, an exemplary configuration 600A includes a physical infrastructure 610 having a blockchain 620 and an intelligent contract 640 that may perform any of the operational steps 612 included in any of the exemplary embodiments. For example, as a cross-chain transaction is performed, the smart contracts 640 may execute the transaction and invoke changes to multiple different blockchain ledgers, thereby updating the world state of multiple blockchains at the same time (i.e., simultaneously). In this example, step/operation 612 may include one or more steps described or depicted in one or more flowcharts and/or logic diagrams. These steps may represent output or written information written or read from one or more intelligent contracts 640 and/or blockchains 620 residing on physical infrastructure 610 configured by the computer system. Data may be output from the executing intelligent contracts 640 and/or blockchain 620. The physical infrastructure 610 may include one or more computers, servers, processors, memory, and/or wireless communication devices.

Fig. 6B illustrates an example intelligent contract configuration between a contracting party and an intermediary server configured to enforce intelligent contract terms on a blockchain, according to an example embodiment. Referring to FIG. 6B, configuration 650B may represent a communication session, asset transfer session, or flow or process driven by intelligent contract 640, which intelligent contract 640 explicitly identifies one or more user devices 652 and/or 656. The execution, operations, and results of the smart contract execution may be managed by the server 654. The contents of intelligent contract 640 may need to be digitally signed by one or more of

entities

652 and 656 that are parties to the intelligent contract transaction. The results of the intelligent contract execution may be written into the blockchain as blockchain transactions.

Examples of intelligent contracts include generic intelligent contracts that perform decisions based on data stored on a chain. For example, a partition intelligence contract for a backbone may identify and store partition rules through a blockchain on the backbone. Another example of an intelligent contract is a system intelligent contract that is configured to access data and functionality of computing systems outside of a chain (also referred to as out-of-chain). For example, a transaction router may identify network information and interact with a network interface of the system to route transactions to a single partition blockchain or a hybrid chain. As another example, the query federator may interact with network information and network interfaces of the system to transmit queries to other blockchain systems and receive responses.

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

An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components. For example, fig. 7 illustrates an example computer system architecture 700 that may represent or be integrated within any of the above components, and/or the like.

FIG. 7 is not intended to suggest any limitation as to the scope of use or functionality of embodiments of applications described herein. In any event, the computing node 700 is capable of being implemented and/or performing any of the functions set forth above.

In computing node 700, there is a computer system/server 702 that 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 may be suitable for use with computer system/server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or portable devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the above systems or devices, and the like.

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

As shown in fig. 7, computer system/server 702 in cloud computing node 700 is shown in the form of a general purpose computing device. Components of computer system/server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processors 704.

The bus 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.

Computer system/server 702 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system/server 702 and includes both volatile and nonvolatile media, removable and non-removable media. In one embodiment, the system memory 706 implements the flow diagrams of the other figures. The system memory 706 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)710 and/or cache memory 712. Computer system/server 702 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 714 may be provided for reading from and writing to non-removable, nonvolatile magnetic media (not shown and commonly referred to as "hard disk drives"). Although not shown, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk such as a CD-ROM, DVD-ROM, or other optical media may be provided. In which case each may be connected to the bus by one or more data media interfaces. As will be further depicted and described below, memory 706 may include at least one program product having a set (e.g., at least one) of program modules configured to carry out the functions of the various embodiments of the application.

A program/utility 716 having a set (at least one) of program modules 718, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory 706 by way of example, and not limitation. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networked environment. The program modules 718 generally perform the functions and/or methods of the various embodiments of the present application described herein.

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

Computer system/server 702 may also communicate with one or more external devices 720, such as a keyboard, pointing device, display 722, etc.; one or more devices that enable a user to interact with computer system/server 702; and/or any device (e.g., network card, modem, etc.) that enables computer system/server 702 to communicate with one or more other computing devices. Such communication may occur via I/O interfaces 724. However, computer system/server 702 may still communicate with one or more networks (e.g., a Local Area Network (LAN), a general Wide Area Network (WAN), and/or a public network) via network adapter 726. As shown, network adapter 726 communicates with the other components of computer system/server 702 over a bus. It should be appreciated that although not shown, other hardware and/or software components may be used in conjunction with computer system/server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, and the like.

According to various embodiments, in one example, computing system 702 may be a blockchain node included within a backbone as described herein. In this example, memory 704 may store a backbone that includes partition information such as rules, URLs, etc., that links storage across multiple different chains of blocks together. Processor 704 can receive a request from a client to perform a blockchain transaction and can determine whether the blockchain transaction is associated with data stored on a single blockchain or data stored separately on different blockchains based on partition information stored on the backbone. In response to determining that blockchain transactions are associated with data separately stored on different blockchains, the processor 704 can identify a location of each blockchain from the different blockchains via the backbone and communicate the location to a system, such as a hybrid chain configured to perform cross-chain blockchain transactions.

Although an exemplary embodiment of at least one of the systems, methods, and non-transitory computer readable media is illustrated in the accompanying drawings and described in the foregoing detailed description, it should be understood that the application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or both in pairs. For example, all or part of the functions performed by the various modules may be performed by one or more of the modules. Further, the functions described herein may be performed at various times, and in relation to various events, inside or outside of a module or component. Also, information sent between the various modules may be sent between the various modules via at least one of: data networks, the internet, voice networks, internet protocol networks, wireless devices, wired devices, and/or via multiple protocols. Also, messages sent or received by any module may be sent or received directly and/or via one or more other modules.

Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, a server, a console, a Personal Digital Assistant (PDA), a cell phone, a tablet computing device, a smart phone, or any other suitable computing device or combination of devices. The presentation of the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather is intended to provide one example of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in local and distributed forms consistent with computing techniques.

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 may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units or the like.

Modules may also be implemented, at least in part, 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, which 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 may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, the modules may be stored on a computer readable medium, which may be, for example, a hard disk drive, a flash memory device, a Random Access Memory (RAM), a magnetic tape, or any other such medium for storing data.

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

It will be readily understood that the components of the present application, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application.

One of ordinary skill in the art will readily appreciate that the above may be practiced with steps in a different order and/or with hardware elements in configurations other than those disclosed. Thus, while the present application has been described based upon these preferred embodiments, it would be apparent to those skilled in the art that certain modifications, variations, and alternative constructions would be apparent.

While the preferred embodiments of the present application have been described, it is to be understood that the described embodiments are exemplary only, and that the scope of the present application is to be limited only by the appended claims when all equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.) are considered.

Claims

1. A computing system for managing blockchains, the system comprising:

a network interface to receive a request to perform a cross-chain transaction; and

a processor to:

identifying different locations of two or more different blockchains in which data of the cross-chain transaction is stored;

retrieving data from the data blocks of the two or more different block chains, respectively, according to the identified different locations;

executing the cross-chain transaction that takes as input the retrieved data from the two or more different blockchains to generate a cross-chain result; and

and storing the cross-chain result through a data block of the distributed account book.

2. The computing system of claim 1, wherein execution of the cross-chain transaction causes the processor to blend together data retrieved from the two or more different blockchains.

3. The computing system of any one of the preceding claims, wherein the processor is configured to insert a new chunk of data into each of the two or more different blockchains in which information about the cross-chain result has been stored.

4. The computing system of claim 3, wherein the processor is configured to insert the new data block having information stored therein regarding the cross-chain result into a first blockchain from among the two or more different blockchains to update transaction data obtained from the first blockchain with a delta value obtained from the cross-chain result.

5. The computing system of any one of the preceding claims, wherein the processor is configured to insert a new data chunk, in which information about the cross-chain result has been stored, into a mixed-chain blockchain based on the generated cross-chain result.

6. The computing system of claim 5, wherein the processor is further configured to link the new data chunk inserted into the mixed-chain blockchain to a cross-chain result of another cross-chain transaction previously stored in the mixed-chain blockchain.

7. The computing system of any preceding claim, wherein the processor is configured to control the network interface to retrieve data for the cross-chain blockchain transaction from respective target blockchain link points of the two or more different blockchains identified by the received request.

8. The computing system of any of the preceding claims, wherein the processor is configured to identify different network locations of the two or more different blockchains, respectively, based on two or more Uniform Resource Locators (URLs) included in the request.

9. A method of managing blockchains, comprising:

receiving a request to execute a cross-chain transaction;

10. The method of claim 9, wherein execution of the cross-chain transaction causes data retrieved from the two or more different blockchains to be mixed together.

11. The method of claim 9 or 10, wherein the storing comprises: inserting a new data block having information stored therein about the cross-chain result into each of the two or more different blockchains.

12. The method of claim 11, wherein the storing comprises: inserting the new data block having information stored therein about the cross-link result into a first blockchain from among the two or more different blockchains to update transaction data obtained from the first blockchain with an increment value obtained from the cross-link result.

13. The method of any of claims 9 to 12, wherein the storing comprises: inserting a new data chunk, in which information about the cross-chain result has been stored, into a mixed-chain blockchain based on the generated cross-chain result.

14. The method of claim 13, wherein the storing further comprises: linking the new data chunk inserted into the mixed-chain blockchain to a cross-chain result of another cross-chain transaction previously stored in the mixed-chain blockchain.

15. The method of any of claims 9 to 14, wherein the retrieving comprises: retrieving data for performing a cross-chain blockchain transaction from respective target blockchain link points of the two or more different blockchains identified by the received request.

16. The method of any of claims 9 to 15, wherein the identifying comprises: identifying, based on two or more Uniform Resource Locators (URLs) included in the request, different network locations for accessing the two or more different blockchains, respectively.

17. A computer program product for managing blockchains, the computer program product comprising:

a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing the method of any of claims 9-16.

18. A computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, comprising software code portions, when said program is run on a computer, for performing the method of any of claims 9 to 16.