JP7324222B2 - Computing system, method and computer program for managing blockchain - Google Patents

Description

TECHNICAL FIELD This application relates generally to partitioning transaction data across multiple blockchains, and more particularly to blockchains implementing cross-chain transactions.

A ledger is generally defined as an accounting book of entries in which transactions are recorded and visible to authorized users. A distributed ledger is a ledger that is wholly or partially replicated on multiple computing systems. One type of distributed ledger is the cryptographic distributed ledger (CDL), which is irreversible (once a transaction is recorded it cannot be discarded), accessible (no party CDL can be accessed partially or partially), chronological and timestamped (all parties know when a transaction was added to the ledger), consensus based (transactions are added only if they are approved, typically unanimously, by the parties on the network), verifiable (all transactions can be cryptographically verified). , can have at least some of the properties Blockchain is an example of a CDL. Although the description and diagrams herein are described in terms of a blockchain, this application applies equally to any CDL.

A distributed ledger is an ever-growing list of records that typically apply cryptographic techniques such as storing cryptographic hashes of other blocks. Although primarily used for financial transactions, blockchain can store other assets such as information about goods and services (i.e. products, packages, status, software, data, etc.). A decentralized scheme brings authority and trust to a decentralized network, allowing its nodes to continuously and sequentially record these transactions on a public "block", creating a unique "chain" called a blockchain. produce. Cryptograms are used to secure the authentication of transaction sources via hashcodes, removing the central middleman. Additionally, each block contains a timestamp and a link to the previous block, creating an immutable chain of transaction history. Since blockchains are decentralized systems, peers must reach a consensus state before a transaction can be added to the blockchain ledger.

Limited transaction throughput and storage are widely believed to be problems with blockchain technology. Certain techniques have attempted to improve transaction throughput. For example, the Bitcoin blockchain uses an easy-to-verify but (deliberately) computationally expensive proof-of-work consensus method, requiring cryptographic puzzles to be solved during processing. As another example, permissioned blockchains use a consensus method based on a variant of the Byzantine fault-tolerant (BFT) state machine. These BFT state machines are chosen for high transaction throughput and low consensus latency, but have not yet delivered the required throughput for many industries. That is, even with these improvements, today's blockchain technology will not reach the large scale commonly found in real-world applications for finance, insurance, software development, supply chain, transportation, and many other things. Not suitable for data processing workloads. What is needed, therefore, is a mechanism for scaling blockchain throughput.

Therefore, there is a need in the art to address the aforementioned problems.

Viewed from a first aspect, the present invention provides a system for managing a blockchain, the system comprising a network interface for receiving requests to perform cross-chain transactions and a processor, comprising: identifying disparate locations on two or more different blockchains that store data for cross-chain transactions; extracting data from data blocks on two or more different blockchains based on the identified disparate locations; Searching respectively, performing cross-chain transactions with retrieved data from two or more different blockchains as input to generate cross-chain results, and via data blocks on a distributed ledger a processor for storing cross-chain results.

Viewed from a further aspect, the present invention provides a method for managing a blockchain, receiving a request to perform a cross-chain transaction; identifying disparate locations on different blockchains of the two or more different blockchains; respectively retrieving data from data blocks of two or more different blockchains based on the identified disparate locations; performing a cross-chain transaction with retrieved data from as input for generating a cross-chain result; and storing the cross-chain result via a data block on a distributed ledger.

Viewed from a further aspect, the invention provides a computer program product for managing a blockchain, the computer program product comprising processing circuitry for performing a method for performing the steps of the invention and processing circuitry. computer readable storage medium readable by stored instructions for execution by;

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

An example embodiment includes receiving a request to perform a cross-chain transaction; identifying disparate locations on two or more different blockchains that store data for the cross-chain transaction; Retrieving data from data blocks of two or more different blockchains, respectively, based on the identified disparate locations, and retrieving data from the two or more different blockchains to generate cross-chain results. and storing cross-chain results via data blocks on a distributed ledger.

Another example embodiment is a network interface for receiving a request to perform a cross-chain transaction and a processor of two or more different blockchains storing data for the cross-chain transaction. identifying disparate locations; respectively retrieving data from data blocks of two or more different blockchains based on the identified disparate locations; crossing retrieved data from two or more different blockchains; to perform one or more of executing cross-chain transactions as inputs to produce chain results and storing cross-chain results via data blocks on a distributed ledger; A system can be provided that includes a configured processor.

A further example of an embodiment is receiving a request to perform a cross-chain transaction and disparate locations on two or more different blockchains containing data for the cross-chain transaction when read by a processor. respectively retrieving data from data blocks of two or more different blockchains based on the identified disparate locations; and cross-chaining the retrieved data from the two or more different blockchains. Causes a processor to perform one or more of executing cross-chain transactions as inputs for generating results and storing cross-chain results via data blocks on a distributed ledger. A non-transitory computer-readable medium can be provided that contains the instructions.

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

1 illustrates a system for managing cross-chain transactions according to an example embodiment; FIG. FIG. 2 illustrates a peer node blockchain architecture configuration according to an example embodiment; 1 illustrates a permissioned blockchain network, according to an example embodiment; FIG. FIG. 4 illustrates the processing of a master chain managing data partitioning across multiple partition blockchains according to an example embodiment; FIG. 4 illustrates the processing of a mixed chain performing cross-chain transactions based on data from multiple partition blockchains according to an example embodiment; FIG. 4 illustrates a method of managing cross-chain transactions according to an example embodiment; FIG. 4 illustrates a method of managing cross-chain transactions according to an example embodiment; FIG. 2 illustrates 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. 2 illustrates a smart contract configuration between contracting parties and an intermediary server configured to enforce the smart contract terms against a blockchain, according to an example embodiment; 1 illustrates a computer system configured to support one or more of the example embodiments; FIG.

It will be readily appreciated that the present components may be arranged and designed in a wide variety of different configurations as generally described and shown in the figures herein. Accordingly, the following detailed description of at least one embodiment of the method, apparatus, non-transitory computer-readable medium, and system, as represented in the accompanying figures, is claimed in the present application. is not intended to limit the scope of, but merely represents selected embodiments.

The present features, structures, or characteristics as described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout the specification, use of the phrases "example embodiments," "some embodiments," or other similar language to describe specific features, structures, or characteristics may be included in at least one embodiment. Thus, when the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language appear, they appear in this specification. do not necessarily all refer to the same group of embodiments throughout, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

Further, although the term "message" may be used in describing embodiments, the present application may also apply to many types of network data such as packets, frames, datagrams, etc. be. The term "message" also includes packets, frames, datagrams, and equivalents of any of these. Furthermore, although certain types of messages and signaling may be depicted in exemplary embodiments, these are not limited to certain types of messages, and the present application describes certain types of signaling. is not limited to

Example embodiments are directed to methods, devices, networks, or systems, or combinations thereof, that support a master blockchain system. The system includes a network of blockchains, including a master blockchain that acts as an orchestrator or transaction router among blockchains, which is a set of partitioned blockchains that store partitioned data. Additionally, the system includes a chain of mixed blockchains that retrieve data from multiple blockchains and perform cross-chain transactions by leveraging data from multiple blockchains. Some of the benefits of blockchain systems are improving the capabilities of blockchain-based systems in terms of both storage and transaction throughput. Specifically, compared to a single blockchain network, multiple (compartmentalized) blockchain networks provide (aggregately) much greater storage capacity for storing transaction data. and can further support a much larger number of concurrent transactions injected by an application.

Blockchains differ from traditional databases in that the blockchain is not a central storage, but rather a decentralized, immutable and secure storage, where nodes are allowed to make changes to records in storage. must share. Some properties that are unique to blockchains and that help enforce them are immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and similar including but not limited to:

According to various aspects, the compartmentalization and cross-chain execution functions are performed by newly defined smart contracts that are unique and specific to blockchains. Further, example embodiments include system-based transaction router smart blockchains configured to manage data partitioning among multiple blockchains through access to system resources such as network interfaces, etc.・Contracts are also provided. In response to receiving a request to execute a transaction, the Transaction Router smart contract (of the master chain) identifies multiple different blockchains that have data to execute the transaction, and ) can provide different blockchain locations for cross-chain handling smart contracts. Cross-chain handling smart contracts can retrieve data from different blockchains, perform cross-chain transactions, and update different blockchains based on the results of cross-chain transactions.

Additionally, additional blockchain attributes such as consensus, endorsement, and decentralized/decentralized nodes are technically part of partition rules that determine which partition (individual blockchain) an arriving transaction should be routed to. It is responsible for the implementation of effects. Specifically, the consensus of the participants (nodes) of the master blockchain is a common common that can be used by smart contracts in the transaction router to route incoming transactions to the appropriate partition chain. may agree with the compartmentalization rules of In one example, single-chain transactions are simply routed to the individual partition chains where the data is stored. As another example, when a transaction involves data from multiple partition chains, the transaction is sent to a mixed-chain blockchain that contains a cross-chain handler that can retrieve the data and perform cross-chain transactions. May be rooted. In some embodiments, the hybrid chain may also maintain its own blockchain containing hash-linked immutable records of cross-chain transactions.

Example embodiments provide numerous benefits over traditional databases. For example, through a network of blockchains, embodiments improve throughput and storage availability while also maintaining the level of trust and accountability required by blockchains. On the other hand, conventional databases cannot be used to implement example embodiments because they do not provide consensus among nodes, which leaves a single You will rely on the actors to judge. In this way, a single actor can change the partitioning scheme at will, not based on the agreed-upon consensus required by the master chain. Furthermore, traditional databases do not carry out blockchain-based transactions, where evidence of transactions is stored in an immutable ledger that can only be modified through consensus and endorsement.

In traditional databases, data partitioning is typically used to combat data scalability, data isolation, and transaction throughput issues within the database. Moreover, newer storage technologies such as blockchain continue to have similar problems. Specifically, business networks face the same technical obstacles as interest grows in using permissioned blockchains (eg, Hyperledger Fabric) to preserve the transaction history of business networks. So far, none of the current blockchain technologies have proposed a viable solution to scaling blockchain transaction throughput by partitioning data across multiple blockchains. This is because data partitioning is not a trivial solution for blockchain-based applications and there are several technical challenges that need to be solved. For example, since blockchain uses consensus among various parties to maintain data immutability and trust, data compartmentalization should also provide the same level of trust, accountability, and traceability. To address this issue, the system described herein supports “cross-chain” transactions when data is partitioned across multiple blockchains, thereby enabling gradually evolving business networks. can be adapted to Additionally, the system can partition data across multiple blockchains to support data partitioning and cross-chain transactions while maintaining trust, accountability, and traceability. Specifically, blockchain systems are designed to (a) compartmentalize data across multiple blockchains, (b) support cross-chain transactions, and (c) maintain trust, provenance, and traceability. can do.

The present application relates, in one embodiment, to partitioning transaction data across multiple blockchains and, in another embodiment, to blockchains that conduct cross-chain transactions.

FIG. 1 illustrates a blockchain system 100 for managing cross-chain transactions, according to various example embodiments. Referring to FIG. 1, system 100 includes a master chain network 110 (master chain), a mixed chain network 120 (mixed chain), and multiple partition blockchain networks. Blockchain networks may be connected together via a network 140 such as a private network, the Internet, or the like, or a combination thereof. The system 100 may use a combination of blockchains to store transactions associated with the partition data model in the business network, so when more storage is needed or transaction data It supports the scalability of business networks, which can both increase storage capacity and transaction throughput dynamically over time as the size of the network grows, or both. Overall, the proposed system includes a master chain 110 for routing incoming transactions and queries to the appropriate partitions (ie, mixed chain 120 or partition chains 132-136) that can process them. On the other hand, partitioned chains 132-136 are each responsible for maintaining data within one partition of the entire data domain. Additionally, mixed chain 120 can also handle transactions that access data across multiple partitions.

Master Chain 110 is a mechanism that routes transactions based on policies that are trusted by all parties in the network. If centralized routers are used instead, the reliability of the entire system will depend on this single entity, which does not meet blockchain requirements. Thus, the master chain 110 can persist and track partition rule changes through a blockchain that includes chains of blocks that are hash-linked together. Once the partitioning policy is stored on the master chain's 110 blockchain, individual blockchain nodes within the master chain 110 can follow other different blockchains based on the partition rules stored on the master chain. • Transactions can be routed through networks (eg, mixed chain 120, partitioned chains 132-136, etc.). The partitioning rules/information stored by the master chain 110 may include data ranges assigned to each of the different partitioned chains 132, 134, and 136, the data ranges corresponding to each partitioned chain. Identifies the data stored in Further, master chain 110 may store the network endpoints of each of partitioned chains 132, 134, and 136, and one or more of partitioned chains 132, 134, and 136. Allows retrieval of data from a node.

According to various aspects, the master chain 110 can receive requests to process transactions involving separate data stored on several different blockchains, referred to herein as cross-chain transactions. . One option for handling cross-chain transactions is to move data from several chains to a specific chain and then execute transactions on this chain. However, this approach introduces unnecessary delays and instabilities into the network and is not a viable solution. Instead, system 100 accesses data from different blockchains to create a mix of transaction data between different chains, and by creating transactions involving different chains of data, provides data from master chain 110. It includes a mixed chain 120 that handles cross-chain transactions that have been processed.

Transaction data may be partitioned across multiple partitioned blockchains 132 , 134 , and 136 . Master Chain 110 can efficiently identify the location of data from these blockchains by building an index based on the smart contracts it queries. For example, a query may provide the master chain 110 with the location of transactional data that has not been previously accessed. Furthermore, the actual routing module, which uses partition rules stored in the master chain 110, must be reliable. Thus, routing modules (ie, transaction routers) may be integrated with blockchain node software. For example, the routing module may be implemented via a special type of smart contract/chaincode, such as the system chaincode available in Hyperledger Fabric 1.0. A system chaincode may be an integral part of a blockchain software module. In contrast to typical smart contracts that access on-chain data, system smart contracts may be designed to allow system-level access, or else be sandboxed. It cannot be used for conventional smart contracts that are supposed to run inside.

FIG. 2 shows a blockchain architecture configuration 200 of a blockchain, according to an example embodiment. Configuration 200 may be an example of a conventional blockchain, such as the compartmentalized blockchain shown in FIG. Referring to FIG. 2, a blockchain architecture 200 may include certain blockchain elements, such as a group of blockchain nodes 202, for example. Blockchain node 202 may include one or more nodes 204-210 (four nodes are depicted by way of example only). These nodes are involved in several activities such as blockchain transaction addition and validation processing (consensus). One or more of blockchain nodes 204 - 210 can endorse transactions and provide an ordering service for all blockchain nodes in architecture 200 . A blockchain node can attempt to initiate a blockchain authentication and write to the blockchain's immutable ledger stored in the blockchain layer 216, a copy of which is also stored in the underlying physical infrastructure 214. can do. The blockchain configuration can be created according to the customized configuration desired by the participants, maintain its own state, control its own assets, and receive external information as stored program/application code 220 ( may include one or more applications 224 linked to an application programming interface (API) 222 for accessing and executing chaincodes, smart contracts, etc.). It is distributed as a transaction and can be installed on all blockchain nodes 204-210 by adding to the distributed ledger.

Blockchain base or platform 212 includes blockchain data, services (e.g., crypto trust services, virtual execution environments, etc.), and auditors seeking to receive and store new transactions and access data entries. may include various layers of underlying physical computer infrastructure that can be used to provide access to Blockchain layer 216 may expose interfaces that allow program code to process and access the virtual execution environment needed to utilize physical infrastructure 214 . Crypto trust services 218 can be used to validate transactions, such as asset exchange transactions, and keep information private.

The blockchain architecture configuration of FIG. 2 can process and execute program/application code 220 via one or more interfaces and services provided by blockchain platform 212. . Code 220 can manage blockchain assets. For example, code 220 can store and transfer data and is executed by nodes 204-210 in the form of chaincode associated with smart contracts and conditions or other code elements to be executed. good too. As a non-limiting example, smart contracts may be created to implement reminders, updates, or other notifications that changes, updates, etc. are made, or a combination thereof. A smart contract can itself be used to identify the rules associated with the ledger's authorization and access requirements and usage. For example, transaction data 226 may be processed by one or more processing entities (eg, virtual machines) included in blockchain layer 216 . Transaction data 226 may include a hash-linked chain of data blocks that link together transactions executed via a blockchain. For example, the most recent transaction may be stored in the last block of the blockchain. Transaction results 228 may include transaction data 226 mixed with data from another blockchain via cross-chain transactions. Physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

Smart contracts in chaincode may be created by high-level applications and programming languages and then written to blocks in the blockchain. A smart contract may include executable code that is registered, stored, and/or replicated by a blockchain (eg, a distributed network of blockchain peers). A transaction is an execution of smart contract code that can be executed upon satisfaction of conditions associated with the smart contract. Execution of smart contracts can trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger made by executing smart contracts may be automatically replicated throughout a distributed network of blockchain peers through one or more consensus protocols.

Smart contracts can write data to the blockchain in the form of key-value pairs. Additionally, the smart contract code can read values stored on the blockchain and use this value when the application is running. Smart contract code can write the output of various logical operations to the blockchain. The code may be used to create temporary data structures within virtual machines or other computing platforms. Data written to a blockchain can be public, encrypted and kept private, or both. Temporary data used/generated by a smart contract is held in memory by a given execution environment and then deleted once data needed by the blockchain is identified.

A chaincode may include a code interpretation of a smart contract with additional features. As described herein, a chaincode may be program code deployed on a computing network and executed together and validated by a chain validator during the consensus process. The chaincode receives the hash and retrieves the hash associated with the data template created using the previously stored feature extractor from the blockchain. If the hash of the hash identifier matches the hash created from the stored template data of the identifier, the chaincode sends the authorization key to the requested service. Chaincode can be written to blockchain data associated with cryptographic details. In FIG. 2, the chaincode can incorporate modifications to assets by storing data blocks representing the results of executing transactions. One function may be adding a new value to an asset, modifying an asset's value, deleting an asset's value, and the like, which may be performed by one or more of the nodes 204-210. They may be distributed or stored by them.

A client can send a request to perform a blockchain transaction (e.g., a cross-chain transaction), supported software development kits (such as NODE, Java(R), PYTHON, and the like) An application that utilizes a software development kit (SDK) may be included that utilizes available application programming interfaces (APIs) to generate cross-chain transaction proposals. Proposals invoke chaincode functions (i.e., create new key-value pairs for assets write). The SDK acts as a shim for packaging transaction proposals into well-designed formats (e.g., protocol buffers for remote procedure calls (RPCs)) and provides unique signatures for transaction proposals. It can be the client's cryptographic credentials to generate. Java(R) and all Java(R)-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

The chaincode may be run against the current state database to produce transactional results including response values, read sets, and write sets. However, no updates to the ledger are made at this point. Rather, the set of values, along with the endorsing peer node's signature, may be returned as a proposal response to the client's SDK, which parses the payload that the application will consume.

In response, the client's application checks/verifies the endorsing peer's signature and compares the proposal responses to determine if they are the same. If the chaincode only queries the ledger, the application will inspect the query response and typically will not submit the transaction to the ordering node service. When a client application attempts to submit a transaction to the ordering node service to update the ledger, the application must check whether the specified endorsement policy has been met (i.e. all required peer node endorsed the transaction). Here, a client may include only one of multiple parties to a transaction. In this case, each client could have its own endorsing node, and each endorsing node would need to endorse the transaction. The architecture ensures that even if an application chooses not to inspect the response or otherwise forwards a transaction that was not endorsed, the endorsement policy is still enforced by the peer and the commit・It will be protected in the validation phase.

After successful verification, the client aggregates the endorsements into a transaction and broadcasts the asset and response transaction proposals in a transaction message to the ordering node. A transaction may contain a read/write set, the endorsing peer's signature, and a channel ID. The ordering node does not need to examine the full contents of the transaction in order to do its work, instead the ordering node simply receives the transactions from all channels in the network and chronologically orders them by channel. , can produce a block of transactions per channel.

FIG. 3 shows an example of a single-blockchain, permissioned blockchain network 300 featuring a decentralized, decentralized peer-to-peer architecture and a certification authority 318 that manages user roles and permissions. Any of the master chain, mixed chain, and partition chain may be a permissioned blockchain network 300 . In this example, blockchain user 302 is able to submit transactions to permissioned blockchain network 310 . Transactions can be deployments, invocations, or queries, and may be issued through client-side applications leveraging the SDK, directly through REST APIs, or the like. A trusted business network can provide access to systems 314 of regulatory agencies such as auditors (eg, the Securities and Exchange Commission of the US stock market). On the other hand, the blockchain network operator's system, which is a node 308, enforces member permissions, such as registering the regulator's system 310 as an "auditor" and the blockchain user 302 as a "client". to manage. Auditors may be limited to querying the ledger only, while clients may be granted permission to deploy, launch, and query certain types of chaincodes.

Blockchain developer system 316 writes chaincode and client-side applications. A blockchain developer's system 316 can deploy chaincode directly to the network through a REST interface. To include credentials from legacy data sources 330 in the chaincode, developer's system 316 can access the data using an out-of-band connection. In this example, blockchain user 302 connects to the network through peer node 312 . Before proceeding with any transaction, peer node 312 retrieves the user's registration and transaction credentials from certificate authority 318 . In some cases, blockchain users must possess these digital certificates in order to transact on permissioned blockchain network 310 . On the other hand, a user attempting to run a chaincode may be required to verify the user's credentials on the traditional data source 330 . To verify user authorization, Chaincode can use an out-of-band connection to this data through the conventional processing platform 320 .

FIG. 4 illustrates a process 400A of a master chain 410 managing data partitioning across multiple partition blockchains, according to an example embodiment, and FIG. 5 illustrates a process 400A from multiple partition blockchains, according to an example embodiment. 4 shows a process 400B of a mixed chain 420 executing cross-chain transactions based on data in . Referring to FIG. 4, master chain 410 is a hash-linked chain of blocks of partitioning information about how data is partitioned among different partition blockchains 432, 434, and 436. manages a blockchain 412 including An entire domain may be divided into subdomains or subsets, where each partition blockchain 432, 434, and 436 contains a unique subdomain or subset to the exclusion of other partition blockchains. Blockchain 412 also includes information identifying the network locations (e.g., endpoints, URLs, etc.) of nodes in each partition blockchain 432, 434, and 436 for retrieving and providing transaction data. can be stored.

For example, the functionality of master chain 410 may be implemented via three corresponding smart contracts. In one example, the partitioner's smart contract 414 governs the entire data domain, e.g., the boundaries of the range of data maintained in each partition of the data domain assigned to each partition blockchain 432-436. Maintain consensus among the parties (master chain nodes) on the partitioning function that determines how partitioning can be done. The master chain 410 may further include a transaction router smart contract 416 that routes incoming transactions to the appropriate chain responsible for processing the transaction (according to its partitioning function). For example, a single chain transaction may be routed directly to the single chain on which the transaction data is stored. On the other hand, cross-chain transactions may be routed to mixed chain 420 for processing. Routing information may be identified from the partitioning information stored on blockchain 412 .

The master chain 410 may further include a query federator smart contract 418 responsible for handling queries from clients. In some embodiments, the partitioner smart contract 414 may be a smart contract running inside each peer node in the master chain based on on-chain data, while the transaction - The router 416 and query federator 418 have system-level capabilities to access various other software components within the host node, but are not available to ordinary smart contracts running inside the sandbox; It can also be a special system smart contract (also known as system chaincode). On the other hand, partitioned blockchains 432, 434, and 436 may be conventional blockchain networks that maintain different partitions across data domains without knowing the complete domain. Each compartmentalized chain can receive transaction and query requests from the master chain 410 and run a single chain handler smart contract that executes these requests.

Referring to FIG. 5, mixed chain 420 receives cross-chain transactions from master chain 410 and executes the cross-chain transactions. For example, the request received from master chain 410 may include the network location of the blockchain network where the data for the cross-chain transaction is stored. Accordingly, mixed chain 420 can identify which partitioned blockchain among multiple partitioned blockchains 432, 434, and 436 that has data for cross-chain transactions. can. The mixed chain 420 includes a cross-chain handler smart contract 424 that receives transaction requests from the master chain 410 and is responsible for accessing data across multiple partitions. In addition, cross-chain handler 424 performs cross-chain transactions, thereby mixing data from different partition blockchains together to produce mixed results. Cross-chain handler 424 can store the results of cross-chain transactions on blockchain 422, which links together the results of all cross-chain transactions made in the system. In addition, the cross-chain handler 424 sends the partition blockchain that provided the data for the transaction along with the results of the cross-chain transaction to allow the partition blockchain to update the stored data/assets. It can be updated further.

According to various embodiments, master chain 410 may be initialized with the endpoint information of other blockchains (420, 432, 434, and 436). Within the master chain 410, each party in the network can reach consensus on a partition rule off-network, and one authorized party can use the "setPartitionRule ” method to set the partition rules within the blockchain 412 . Any changes to partition rules are stored on the blockchain 412, allowing them to be tracked. After initialization, the partitioner smart contract 414 can set the enable flag so that any node in this master chain can fetch the partition rule and route transactions according to this rule. Additionally, transaction router smart contract 416 can initially identify what data was accessed by these transactions. For example, the transaction router 416 can look up the partitioning rules from the blockchain through the partitioner's smart contract 414 . According to various embodiments, transaction router 416 then determines to which blockchain network the transaction should be routed. For example, if a transaction only accesses data within a single partition, the transaction will be routed to a specific partitioned blockchain network. Conversely, transactions that access data in multiple partitions are routed to the network of Mixed Chains 420 for processing.

On the one hand, the workflow for processing transactions in the mixed chain 420 involves the cross-chain handler's smart contract 424 receiving transaction and partition information from the master chain's transaction router. In response, the cross-chain handler 424 fetches data from a different chain, persists the fetched data and the new value in its own chain 412, and initiates a separate "setDiff" transaction to update the latest values for different parties in the encrypted chain. For example, if balances for 'X' are fetched from the 'B-chain' 434 and balances for 'Y' are fetched from the 'A-chain' 432, after a balance transfer transaction from X to Y, X and Y will be set using the 'setDiff' transaction in the 'B-Chain' and vice versa. In this way, a 'mixed chain' will contain cross-chain transactions, but also update other related chains with separate 'setDiff' transactions to update values due to delta changes. In some embodiments, if a cross-chain transaction is in progress and there is a newly arriving transaction that accesses some data in common with the cross-chain transaction, this new transaction is held for a defined period of time. may be immediately discarded by the transaction router 416.

As another example, if a query accesses data based on the partitioning attributes included in the partitioning function, query federator 418 routes the query to the particular partitioned chain that maintains the data of interest. Only. In contrast, when queries access data based on non-partitioned attributes, query federator 418 may not be aware of where data is stored among different blockchain partitions. In this case, the query federator 418 can forward queries to any partitioned chains and collect the results returned by those chains before returning them to the client.

As described, mixed chain 420 is capable of executing transactions across different partitioned blockchains 432-436. For example, transaction router 414 can read user information contained in incoming transactions and partition rules maintained within its blockchain 412 (i.e., master chain or partition smart contract). . As a non-limiting example, transaction router 414 determines that data records associated with user "U1" are in partition A 432, while data records associated with user "U2" are in partition B 434. can be identified. In this example, transaction router 414 may update its lock table with the information that a cross-chain transaction is in progress for 'U1' and 'U2'. This transaction may then be transferred to the mixed chain 420 along with the details of 'U1', 'U2', and the URLs of these blockchain nodes. In response, cross-chain handler 424 may fetch data for 'U1' from partition A 432 and data for 'U2' from partition B 434 . In addition, the cross-chain handler 424 creates a transaction within its own blockchain 422 and also sends a "SetDiff" transaction to U1's blockchain (partition A 432) with the delta of U1's balance and A separate "SetDiff" transaction can be sent to U2's blockchain (Partition B 434).

FIG. 6 illustrates a method 500 of routing transactions for cross-chain processing, according to an example embodiment. For example, method 500 may be implemented via smart contracts executed by blockchain nodes within a master blockchain network. As another example, method 500 may be performed by a group of computing nodes within a master blockchain network. Referring to FIG. 6, at 510, the method may include storing partition information linking storage together across multiple blockchains via the master chain. For example, the partition information may include partition rules generated by consensus of the nodes of the master chain. Partition rules can identify the extent of data stored by each of multiple different blockchains, and location information for each blockchain, such as a Uniform Resource Locator (URL) or the like. In some embodiments, the method may include establishing partition information in response to finding consensus on partition information from multiple blockchain nodes managing a master chain.

At 520, the method may include receiving a request from a client to perform a blockchain transaction. For example, a client can request a transaction that leverages data from a single blockchain, or a transaction that leverages data from multiple different blockchains. At 530, the method determines whether blockchain transactions are associated with data stored on one blockchain or data stored separately on different blockchains based on partition information stored on the master chain. may include determining, via the master chain, whether it is associated with For example, a transaction can identify a particular asset or data item, and partition information is where the asset or data item is stored, based on the master chain and partitioner smart contracts that manage the partitioning information. can identify

In response to determining that the blockchain transaction is associated with data separately stored on different blockchains, at 540 the method transfers the location of each blockchain from among the different blockchains to the master chain. and transmitting the location to a system configured to perform blockchain transactions. In some embodiments, transmitting is on a mixed chain configured to retrieve individual data from each of the different blockchains and execute blockchain transactions based on the data retrieved from the different blockchains. may include sending the location to a cross-chain handler smart contract running in .

In some embodiments, the partition information identifies the entire domain or range of transactional data managed by the master chain and the individual sub-chains assigned to each individual blockchain among the multiple blockchains. Further identify the domain. Here, the partition information or subdomain information can identify the boundary extents of the transaction data maintained by each blockchain in the multiple blockchains.

In some embodiments, the method includes at least one block storing data for a blockchain transaction when the master chain does not contain identification information of the blockchain storing the data for the blockchain transaction. It may further include querying the plurality of blockchains individually to determine one blockchain. For example, queries may be made by a query federator smart contract running on a blockchain node, while decisions are made by a transaction routing smart contract running on a blockchain node. good too. In some embodiments, the method may further include detecting an availability flag set by the master chain and fetching partition information in response to detecting the availability flag.

FIG. 7 illustrates a method 550 of performing cross-chain transactions based on data from multiple blockchain networks, according to an example embodiment. For example, method 550 may be performed by nodes of a mixed chain network. Referring to FIG. 7, at 551 the method may include receiving a request to perform a cross-chain transaction. For example, a request may be received from a master chain that identified a blockchain transaction requiring data from a different blockchain. At 552, the method may include identifying distinct locations on two or more different blockchains that store data for cross-chain transactions. For example, a hybrid chain may identify the network locations of blockchain nodes that have been registered for communication with the hybrid chain and have location information (e.g., URLs, endpoints, etc.) stored in the master chain. can be done. In this example, identifying may include respectively identifying different network locations for accessing two or more different blockchains based on two or more URLs included in the request.

At 553, the method may include respectively retrieving data from data blocks of two or more different blockchains based on the identified distinct locations. For example, searching may include sending requests from the mixed chain to respective blockchain nodes of different blockchains requesting different data items (e.g., data ranges) of data stored on different blockchains. . Here, the data is unique to each individual blockchain and does not have to be obtained from the same blockchain. At 554, the method may include performing a cross-chain transaction with retrieved data from two or more different blockchains as input for generating a cross-chain result. For example, performing cross-chain transactions involves retrieving from two or more different blockchains, such as through exchanging data, combining data, subtracting data, adding data, modifying data, and the like. data can be mixed together.

At 555, the method may include storing cross-chain results via data blocks on a distributed ledger. For example, storing may include inserting a new data block containing information about the result of the cross-chain into each of two or more different blockchains. In this example, the storing means new data storing information about the cross-chain result to update the transaction data obtained from the first blockchain with the difference value resulting from the cross-chain result. • It may involve inserting a block into a first blockchain from among two or more different blockchains. In some embodiments, the storing includes inserting a new data block containing information about the cross-chain results into the mixed-chain blockchain based on the generated cross-chain results. It's okay. In some embodiments, storing links a new data block inserted on the mixed-chain blockchain to the cross-chain result of another cross-chain transaction previously stored on the mixed-chain blockchain. It may further include:

FIG. 8 illustrates an example physical infrastructure configured to perform various operations on a blockchain, according to one or more of the example methods of operation, according to an example embodiment. Referring to FIG. 8, an example configuration 600A includes a physical infrastructure 610 with a blockchain 620 and a smart contract 640 to perform any of the operational steps 612 included in any of the example embodiments. be able to. For example, smart contract 640 can execute a transaction and initiate changes to different blockchain ledgers as a result of a cross-chain transaction being executed, thereby allowing any Update states simultaneously (ie all at once). In this example, steps/actions 612 may include one or more of the steps described or depicted in one or more flowcharts and/or logic diagrams. The steps include information written or read, output or written from one or more smart contracts 640 and/or blockchain 620 in the physical infrastructure 610 of the computer system configuration. can be represented. Data can be output from executed smart contract 640 and/or blockchain 620 . Physical infrastructure 610 may include one or more computers, servers, processors, memory, or wireless communication devices, or a combination thereof.

FIG. 9 illustrates an example smart contract configuration between contracting parties and an intermediary server configured to enforce the smart contract terms to a blockchain, according to an example embodiment. Referring to FIG. 9, configuration 650B implements a process or procedure driven by smart contract 640 that explicitly identifies a communication session, asset transfer session, or one or more user devices 652 and/or 656. can be represented. The execution, actions, and results of smart contract execution may be managed by server 654 . The contents of smart contract 640 may require digital signature by one or more of entities 652 and 656 that are parties to the smart contract transaction. The results of smart contract execution may be written to the blockchain as blockchain transactions.

Examples of smart contracts include regular smart contracts that make decisions based on data stored on-chain. For example, the master chain's compartmentalization smart contract can identify and store the compartmentalization rules via the blockchain on the master chain. Another example of a smart contract is a smart contract for a system configured to access data and functionality of a computing system outside the chain (also called off-chain). For example, a transaction router can identify network information and interact with the system's network interface to route transactions to a single-partition blockchain or mixed chain. As another example, a query federator can interact with network information and the system's network interfaces to send queries to and receive responses from other blockchain systems.

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

An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage medium may reside in an application specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium may exist as separate components. For example, FIG. 10 illustrates an example computer system architecture 700 that may represent or be integrated with any of the components and others described above.

FIG. 10 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein. In any event, computing node 700 may be implemented and/or perform any of the functions set forth above.

Computing node 700 includes a computer system/server 702 that operates in numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system/server 702 include personal computer systems, server computers, Systems, Thin Clients, Thick Clients, Handheld or Laptop Devices, Multiprocessor Systems, Microprocessor Based Systems, Set Top Boxes, Programmable Consumer Electronics, Network PCs, Minicomputer Systems, Including, but not limited to, mainframe computer systems and distributed cloud computing environments including 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 the 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 also 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. 10, computer systems/servers 702 in cloud computing node 700 are shown in the form of general-purpose computing devices. Components of computer system/server 702 may include one or more processors or processing units 704 , system memory 706 , and a bus coupling various system components including system memory 706 to processor 704 . Good but not limited to these.

A bus can be any type of bus 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. Any one or more of the structures. 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 can be accessed by computer system/server 702 and includes both volatile and nonvolatile media, removable and non-removable media. . System memory 706, in one embodiment, implements the flowcharts of other figures. The system memory 706 can 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/non-volatile 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 but typically referred to as "hard drives"). Although not shown, a magnetic disk drive for reading and writing to removable nonvolatile magnetic disks (eg, "floppy disks") and removable media such as CD-ROMs, DVD-ROMs, or other optical media An optical disc drive can be provided for reading and writing non-volatile optical discs. In such cases, each may be connected to the bus by one or more data medium interfaces. As will be further delineated and explained below, memory 706 has at least a set of program modules (eg, at least one) configured to perform the functions of various embodiments of the present application. It may include one program product.

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

As will be appreciated by those 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 refer to entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.) or as referred to herein as "circuits," "modules." Embodiments may take the form of a combination of software and hardware aspects, all collectively referred to as the "system", or the "system". Furthermore, aspects of the present application may be in the form of a computer program product embodied in one or more computer-readable media containing computer-readable program code.

Computer system/server 702 also has one or more external devices 720 , such as keyboards, pointing devices, displays 722 , etc., that allow users to interact with computer system/server 702 . , or any device (e.g., network card, modem, etc.), or combination thereof, that enables computer system/server 702 to communicate with one or more other computing devices. good too. Such communication can occur via I/O interface 724 . Additionally, computer system/server 702 may be connected to one or more networks such as a local area network (LAN), a general wide area network (WAN), or a public network (eg, the Internet), or combinations thereof. , can communicate via network adapter 726 . As depicted, network adapter 726 communicates with other components of computer system/server 702 via a bus. Although not shown, it will be appreciated that other hardware and/or software components may be used 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 in the master chain described herein. In this example, memory 704 may store a master chain that includes partition information such as rules, URLs, and the like that link storage across multiple different blockchains together. Processor 704 receives a request from a client to execute a blockchain transaction, and based on the partition information stored in the master chain, executes the blockchain transaction with the data stored in one single blockchain. It can be determined whether they are associated or with data stored separately on different blockchains. In response to determining that a blockchain transaction is associated with data stored separately on different blockchains, processor 704 transmits the location of each blockchain among the different blockchains via the master chain. , and transmit the location to a system such as a mixed chain configured to perform cross-chain blockchain transactions.

While exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are illustrated in the accompanying drawings and described in the foregoing detailed description, the present application discloses Rather than being limited to the specific embodiments, it will be understood that numerous rearrangements, modifications and substitutions may be made as indicated and defined by the following claims. For example, the capabilities of the systems of various figures can be performed by one or more of the modules or components described herein, or in a distributed architecture, including transmitters, receivers, Or it may contain both pairs. For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Moreover, the functions described herein may be performed inside or outside a module or component many times and in connection with various events. Also, information sent between the various modules may be sent via at least one of a data network, the Internet, a voice network, an Internet Protocol network, wireless devices, wired devices, or via multiple protocols. and/or can be sent between modules. Also, messages sent or received by any of the modules may be sent or received either directly or through one or more of the other modules, or both.

"System" means a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices One skilled in the art will appreciate that it can be embodied as Showing the above-described functions as performed by the "system" is not intended to limit the scope of this application in any way, but rather shows one example of many embodiments. is intended to be Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

Note that some of the features of the systems described herein have been presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integrated (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, image processors, or the like.

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

In fact, a module of executable code can be a single instruction, or many instructions, distributed across several different code segments, between different programs, and across several memory devices. can even let you. Similarly, although operational data may be identified and illustrated herein within modules, it 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 across different locations, including different storage devices, and exist at least partially as mere electronic signals on a system or network. good too.

It will be readily appreciated that the components of the present application may be arranged and designed in a wide variety of different configurations as generally described and shown in the figures herein. Accordingly, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but merely represents selected embodiments of the present application.

Those skilled in the art will readily appreciate that the above may be practiced by a different order of steps and/or by a different arrangement of hardware elements than those disclosed. Thus, while this application has been described in terms of these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will become apparent.

Although preferred embodiments of the application have been described, the described embodiments are exemplary only, and the scope of the application covers the full range of equivalents and modifications (e.g., protocols, hardware, device, software platform, etc.) will be defined solely by the appended claims.

Claims (18)

A computing system for managing a blockchain, comprising:
a network interface for receiving queries from clients;
a processor,
identifying two or more different blockchains that store data for the query;
retrieving the data for the query from data blocks of the two or more different blockchains, respectively, via a hybrid blockchain smart contract independent of the two or more different blockchains;
performing a cross-chain transaction using the retrieved data from the two or more different blockchains as input to generate a cross-chain result; and the cross-chain via distributed ledger data blocks. a processor for storing the results of
the identification is based on bounds of ranges of partitioned data of the two or more different blockchains stored by the mixed blockchain;
system. 2. The computing system of claim 1, wherein executing the cross-chain transaction causes retrieved data from the two or more different blockchains to be mixed together by the processor. 3. The processor of claim 1 or 2, wherein the processor is configured to insert a new data block containing information about the result of the cross-chain into each of the two or more different blockchains. computing system. The processor divides the two new data blocks storing information about the cross-chain result in order to update the transaction data obtained from the first blockchain with the difference value of the cross-chain result. 4. The computing system of claim 3, configured to insert into said first blockchain from among said different blockchains. 5. The processor is configured, based on the generated cross-chain result, to insert a new data block containing information about the cross-chain result into a blockchain of the hybrid chain. A computing system according to any of the preceding claims. The processor is further configured to link the new data block inserted into the mixed-chain blockchain to a cross-chain result of another cross-chain transaction previously stored on the mixed-chain blockchain. 6. The computing system of claim 5, wherein: The processor retrieves the data for the cross-chain blockchain transaction from individual target blockchain nodes of the two or more different blockchains identified by the request to perform the cross-chain transaction. 7. A computing system according to any one of claims 1 to 6, adapted to control said network interface to search for . The processor respectively identifies different network locations of the two or more different blockchains based on two or more uniform resource locators (URLs) included in the request to perform the cross-chain transaction. A computing system as claimed in any preceding claim, configured to: A method for managing a blockchain, comprising:
to the computer,
receiving a query from a client;
identifying two or more different blockchains that store data for the query;
retrieving the data for the query from data blocks of the two or more different blockchains, respectively, via a hybrid blockchain smart contract independent of the two or more different blockchains;
performing cross-chain transactions using the retrieved data from the two or more different blockchains as input for generating cross-chain results;
storing the cross-chain results via data blocks on a distributed ledger;
the identification is based on bounds of ranges of partitioned data of the two or more different blockchains stored by the mixed blockchain;
Method. 10. The method of claim 9, wherein the executing of the cross-chain transaction mixes together the retrieved data from the two or more different blockchains. 11. A method according to any of claims 9 or 10, wherein said storing comprises inserting a new data block containing information about said cross-chain result into each of said two or more different blockchains. Method. The storing causes a new data block containing information about the cross-chain result to update transaction data obtained from the first blockchain with a difference value resulting from the cross-chain result. 12. The method of claim 11, comprising inserting into the first blockchain from among the two or more different blockchains. 13. The storing step comprises inserting a new data block storing information about the cross-chain result into a mixed-chain blockchain based on the generated cross-chain result. The method according to any one of The storing comprises linking the new data block inserted into the mixed-chain blockchain to a cross-chain result of another cross-chain transaction previously stored on the mixed-chain blockchain. 14. The method of claim 13, further comprising: The retrieving executes the cross-chain blockchain transaction from respective target blockchain nodes of the two or more different blockchains identified by the request to execute the cross-chain transaction. 15. A method as claimed in any one of claims 9 to 14, comprising retrieving the data for. different networks for accessing said two or more different blockchains, said identifying based on two or more uniform resource locators (URLs) included in said request to perform said cross-chain transaction; - A method according to any one of claims 9 to 15, comprising identifying each location. A computer program product for causing a computer to perform the steps of the method according to any one of claims 9 to 16. 18. A computer readable medium recording the computer program according to claim 17.

Images