Method and system for distributing consistent ledgers across multiple blockchains

Abstract

A method for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains includes: storing a blockchain including a plurality of blocks, each block including at least a block header and one or more blockchain data values; receiving a base commit from a first node, wherein the first node is included in a first blockchain network; generating a first new block, the first new block including at least the first block header and the received base commit; storing the first new block in the blockchain; receiving state commits from additional nodes included in each of at least two additional blockchain networks; generating additional new blocks, the additional new blocks including at least the additional block header and each received state commit; and storing the additional new blocks in the blockchain.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Non-Provisional Application No. 16 / 576,915, filed September 20, 2019. The entire disclosure of the above application is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to maintaining a consistent blockchain ledger to store commitments across multiple separate blockchains, and in particular, maintaining a global ledger that serves as an immutable ledger of the state of multiple separate and distinct blockchains. Background Art

[0004] Blockchains are often associated with cryptocurrencies, but they have applications far beyond currency transfers and other financial transactions. For example, blockchains have been used to facilitate voting, store land deeds, track the provenance of diamonds and other luxury goods, and are used internally by many organizations and entities as more complex storage solutions. In many cases, blockchains are used because they provide an immutable and auditable record, as the data stored within them cannot be altered when new blocks are added due to the way they are generated and added.

[0005] Typically, when a blockchain is used as part of a problem solution, it is designed and formatted to solve the problem being solved. Consequently, two blockchains created to solve even similar problems may differ significantly in format. Due to format differences and a lack of standardization across blockchains, entities may have difficulty keeping track of multiple blockchains. This ability to track data may be increasingly important in situations where multiple blockchains store common data, such as when currency or other value is fragmented across multiple blockchains. In such situations, an entity may be interested in or need to maintain a record of the value being stored in each blockchain. However, currently, no mechanism exists for entities to maintain such a record. Therefore, there is a need for a technical system that can maintain a consistent ledger across multiple blockchains, particularly one that is agnostic of the blockchain and its format, allowing the solution to be applied to a wide variety of blockchain types and the data stored therein. Summary of the Invention

[0006] This disclosure provides a description of a system and method for maintaining a consistent ledger across multiple separate blockchains. A global ledger receives base submissions from nodes in a first blockchain network, where the base submissions reference data sent to multiple separate blockchain networks. The global ledger then receives state submissions from each of the multiple separate blockchain networks at predetermined time intervals. Each state submission is stored in a new block in the global ledger. This allows any distributed value to be tracked and its location monitored using state submissions. In some embodiments, the state submission can be a hash of the most recent block or block header of the corresponding blockchain, resulting in the global ledger maintaining an auditable record of each blockchain without revealing any information about the blockchain itself. Therefore, even private blockchains can participate in the system and all information remains private, while still maintaining an auditable record of each blockchain's state. Consequently, the solution is blockchain-agnostic and infinitely scalable, while still providing a solution to the problem of maintaining a consistent record for any number of blockchains.

[0007] A method for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains, comprising: storing a blockchain comprising a plurality of blocks in a memory of a processing server, each block comprising at least a block header and one or more blockchain data values; receiving, by a receiver of the processing server, a base commit from a first node, wherein the first node is included in a first blockchain network; generating, by a processor of the processing server, a first new block, the first new block comprising at least a first block header and the received base commit; storing the first new block in the blockchain in the memory of the processing server; receiving, by the receiver of the processing server, state commits from additional nodes included in each of at least two additional blockchain networks; generating, by the processor of the processing server, additional new blocks, the additional new blocks comprising at least an additional block header and each received state commit; and storing the additional new blocks in the blockchain in the memory of the processing server.

[0008] A system for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains, comprising: a processing server; a first node included in a first blockchain network; and at least two additional blockchain networks, each including additional nodes, wherein the processing server includes a memory storing a blockchain including a plurality of blocks, each block including at least a block header and one or more blockchain data values, a receiver receiving a base commit from the first node; and a processor generating a first new block, the first new block including at least the first block header and the received base commit, wherein the memory of the processing server further stores the first new block in the blockchain, the receiver further receives state commits from additional nodes included in each of the at least two additional blockchain networks, the processor further generating additional new blocks, the additional new blocks including at least the additional block header and each received state commit, and the memory further storing the additional new blocks in the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, which include the following figures:

[0010] Figure 1 is a block diagram illustrating a high-level system architecture for maintaining a consistent blockchain ledger across multiple blockchains, according to an exemplary embodiment.

[0011] Figure 2 is a block diagram illustrating a processing server of a system for maintaining a consistent blockchain ledger according to an exemplary embodiment.

[0012] Figure 3 is a diagram showing a cross-sectional view according to an exemplary embodiment. Figure 1 Block diagram of the architecture of a global blockchain ledger maintained by multiple blockchains in a system.

[0013] Figure 4 is a flow chart illustrating an exemplary method for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains, according to an exemplary embodiment.

[0014] Figure 5 is a block diagram illustrating a computer system architecture according to an exemplary embodiment.

[0015] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is intended for illustration purposes only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0016] Glossary

[0017] Blockchain—a shared ledger of all transactions involving blockchain-based digital assets, such as cryptocurrencies. One or more computing devices may constitute a blockchain network, which may be configured to process and record transactions as part of blocks in the blockchain. Once a block is completed, it is added to the blockchain, thereby updating the transaction record. In many cases, a blockchain may be a chronological ledger of transactions, or it may be presented in any other order suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain may include a destination address and an asset amount, such that the blockchain records how much currency is attributable to a particular address. In some cases, transactions are financial while others are not, or may include additional or different information, such as a source address, a timestamp, etc. In some embodiments, a blockchain may also or alternatively include virtually any type of data in the form of transactions that are or need to be placed in a distributed database and that can be validated and verified by the blockchain network through proof-of-work and / or any other suitable verification technology associated therewith. The distributed database maintains a continuously growing inventory of data records that is tamper-proof and cannot be revised, even by its operators. In some cases, data about a given transaction may also include additional data appended to the transaction data that is not directly part of the transaction. In some cases, including such data in a blockchain may constitute a transaction. In such cases, the blockchain may not be directly associated with a specific digital currency, virtual currency, fiat currency, or other type of currency.

[0018] A system for maintaining a consistent global blockchain ledger

[0019] Figure 1 A system 100 is shown for operation and maintenance of a global blockchain ledger that provides consistency across multiple different blockchains operating via separate and distinct blockchain networks.

[0020] System 100 may include a processing server 102. Processing server 102 may be a node in a blockchain network that maintains a global blockchain ledger, referred to herein as a "global ledger" or "global blockchain," wherein the global ledger stores separate and distinct submissions to a plurality of different blockchains. The blockchain network may include a plurality of blockchain nodes. Each node may be a node such as discussed in more detail below. Figure 2 and / or Figure 5 The computing system shown in FIG is configured to perform functions related to the processing and management of a blockchain, including generation of blockchain data values, verification of proposed blockchain transactions, verification of digital signatures, generation of new blocks, verification of new blocks, and maintenance of a copy of the blockchain.

[0021] A blockchain may be a distributed ledger comprising at least a plurality of blocks. Each block may comprise at least a block header and one or more data values. Each block header may comprise at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header was generated and may be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references an earlier block in the blockchain (e.g., based on a timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block before the corresponding block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. The data reference value may similarly be a reference to one or more data values ​​stored in the block comprising the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing the one or more data values. For example, the block reference value may be the root of a Merkle tree generated using the one or more data values.

[0022] The use of block reference values ​​and data reference values ​​in each block header renders the blockchain immutable. Any attempted modification of a data value would require the generation of a new data reference value for that block, which in turn would require the generation of a new block reference value for subsequent blocks, which in turn would require the generation of a new block reference value in each subsequent block. This would have to be performed and updated in every single node in the blockchain network before a new block could be generated and added to the blockchain in order to make the intended change permanent. Computational and communication limitations could make such modifications extremely difficult, if not impossible, thereby rendering the blockchain immutable.

[0023] Blockchain data values ​​included in blocks in a blockchain are traditionally used to store data, where the type of data stored may vary based on the purpose and usage of the blockchain. For example, a blockchain used for cryptocurrency stores transaction data such as receiving addresses, sending addresses, amounts of currency transferred, references to past transactions, and the like in blockchain data values. In another example, in a blockchain used to store land deed information, a blockchain data value may store the identifier of the land deed and the ownership data associated therewith. In system 100, the blockchain data values ​​stored in the separate and distinct blockchains for which processing server 102 maintains a consistent global ledger can store any type of data in any format, wherein each separate blockchain can store different types of data in different formats than other blockchains. The states of the separate and distinct blockchains are maintained in the global ledger.

[0024] The system 100 may include an issuer 104. The issuer 104 may be an entity that distributes value across multiple blockchain networks, the states of which are stored as subnetworks 110. Figure 1 The issuing institution 104 may be, for example, a financial institution that issues currency to the entity operating each subnetwork 110, an enterprise service that issues software licenses to the entity operating the subnetwork 110, or any other entity that distributes value to multiple entities that may each operate or otherwise be associated with the subnetwork 110. As an example, in the system 100, the issuing institution 104 may be a financial institution that issues 100 units of currency C, where 50 units of C are to be distributed to each of the subnetworks 110a and 110b.

[0025] The initial value distributed across multiple subnetworks 110 can be stored in a general blockchain ledger, referred to herein as the "general ledger," such as can be maintained by general network 106. General network 106 can be a blockchain network including multiple general nodes 108. The general ledger can be a blockchain that stores data related to the issuance and transfer of value that issuing authority 104 wants to distribute to subnetworks 110. In the above example, the general ledger can be a blockchain that stores transfers of currency C. For example, issuing authority 104 may have 100 units of currency C that they want to distribute to two subnetworks 110. In such an example, the general ledger can record two transactions by issuing authority 104, in which they divide the 100 units of currency C into two groups of 50 units each, so that each group can be distributed to the appropriate subnetwork 110. The general ledger can use traditional blockchain functionality to store this transaction data.

[0026] Through the overall network 106 and its overall node 108, the issuing authority 104 can issue value to each sub-network 110 through its sub-network nodes 112. In some cases, the sub-network node 112 may be the system of the entity to which the value is distributed, where the entity's system may maintain and operate the blockchain of the sub-network 110. In an exemplary embodiment, the number of sub-network nodes 112, the architecture of the sub-network 110, and the type of blockchain (e.g., public, private, permissioned, etc.) may have no impact on the issuing authority 104, the overall network 106, or the processing server 102. In other words, sub-network 110a may be a private blockchain operated by a single sub-network node 112a, while sub-network 110b may be a public blockchain maintained by over a thousand sub-network nodes 112b, without affecting how the issuing authority 104, the overall network 106, and the processing server 102 operate as discussed herein.

[0027] Issuing authority 104 and / or master node 108 may generate a base submission representing a release event for releasing value to subnetwork 110. The release event may include any one or more aspects of the release to be stored in the global ledger, where such aspects may be selected as desired by issuing authority 104, master network 106, processing server 102, subnetwork 110, etc. For example, a release event may include issuing authority 104 initially receiving 100 units of currency C, dividing the 100 units into two groups of 50 units each, and transferring ownership of each group of 50 units to a corresponding subnetwork entity, or may include only a portion of the above, and / or may include any additional data specified by one of the entities or systems involved. In an exemplary embodiment, such as where a hashing algorithm is applied to the release event to generate a hash value, the base submission may be a hash of the release event, where the hash value may be the base submission.

[0028] A base commit can be submitted to processing server 102, a node that maintains and operates the global ledger. The base commit can be included in new blocks added to the global ledger. Storage of the base commit means there is an immutable record of the value issued to each subnetwork 110. In the above example, the base commit is a hash that can be used to verify that issuing authority 104 issued 50 units of currency C to each subnetwork 110 via the overall network 106. As a result, any disputes regarding how many units of currency C were distributed to which entities can be easily resolved by hashing the relevant data and comparing the hash with the base commit stored in the global ledger.

[0029] Each subnetwork 110 is free to take any action they desire with the value it receives, and to store any such action in its own respective blockchain. In the case where a subnetwork 110 operates a private blockchain, the distribution or transfer of value in that private blockchain can be performed without any such information being known to anyone not authorized by the subnetwork 110, including the processing server 102, the issuing authority 104, or other subnetworks 110. For example, subnetwork 110a may operate a private blockchain and distribute 50 units of its currency C among its subnetwork nodes 112a, members, authorized recipients, etc. Subnetwork 110b may operate a public blockchain in which its participants conduct a series of transactions using 50 units of currency C, with each transaction being transparent on the public blockchain.

[0030] The global ledger can be used to maintain consistency regarding the ownership and possession of value distributed to subnetworks 110 through state submissions. At predetermined time periods, each subnetwork 110 can submit a state submission via subnetwork node 112 to a processing server 102, which is a node of the network operating the global blockchain ledger. The state submission can represent the state of the subnetwork's blockchain at a specific time (e.g., a specific time relative to the predetermined time period). In an exemplary embodiment, the state can be represented by hashing a specific portion of the subnetwork's blockchain, such as applying a hash algorithm to the block header of the latest block in the blockchain to generate a hash value, where the hash value is used as the state submission. In another example, the latest block itself can be hashed, where the resulting hash value is used as the state submission.

[0031] Processing server 102 can receive state submissions from each subnetwork 110 and store them as blockchain data values ​​in a new block generated and added to the global ledger. By storing these state submissions, each subnetwork's 110 ownership and possession of these units of currency C can be verified, if necessary. For example, if there is a dispute regarding the ongoing ownership of these units of currency C, the subnetwork can disclose block headers or other information related to these units of currency C in its blockchain and provide hashed block headers to generate the state submission, thereby proving the claimed ownership. Furthermore, by using hashes for state submissions, the data stored in the global ledger does not reveal any specific information about each subnetwork 110, thereby not compromising private blockchains or disclosing any information that a subnetwork 110 may wish to remain private, even though the global ledger is publicly available. Furthermore, using hashes for state submissions ensures that each subnetwork 110 can operate its own blockchain in any format and at any activity level without impacting the operation and maintenance of the global ledger.

[0032] Although Figure 1While system 100 in FIG. 1 shows two subnetworks 110a and 110b, there is no theoretical limit to the number of subnetworks 110 that can be included in the global ledger, as processing server 102 may be able to receive any number of state submissions from any number of subnetworks 110 for inclusion in the global ledger. Furthermore, in some cases, a subnetwork 110 may itself be a global blockchain network operating its own global ledger for its members, or its own overall network 106 within system 100. For example, subnetwork node 112a may be a node of the global ledger, where the state submission it submits to processing server 102 may be a hash of the most recent block header in its own global ledger. Nodes within subnetworks of subnetwork 110a may also be servers of their own global ledgers, where the state submission provided to subnetwork node 112a may itself be a hash of a block header in the global ledger. In other words, global ledgers may be nested within other global ledgers, and so on, involving any number of subnetworks 110 at any level, with the only limitations being based on available computing power, network bandwidth, or file size.

[0033] In some embodiments, subnetworks 110 in system 100 can be enabled to directly exchange value issued to them with one another. In exemplary embodiments, atomic swaps can be used to perform these swaps. In an atomic swap, the sending subnetwork 110 may be prohibited from sending any value to which it has not been issued. Verification of ownership of the value being transferred can be performed by the receiving subnetwork 110 and / or a third-party mediator, which may be an issuing authority 104, a master node 108, or a processing server 102. This can be performed using the initial basis commitment used to issue the value to the subnetwork 110. In some embodiments, when an atomic swap is performed, a new basis commitment can be generated for the swap, which is stored in the global ledger as an updated record of how much value each subnetwork 110 controls. For example, in the example above, subnetwork 110a can transfer 30 units of currency C to subnetwork 112. In such an example, the new basis commitment can reflect subnetwork 110a's ownership of 20 units of currency C and subnetwork 110b's ownership of 80 units of currency C. In another such example, the new base submission may reflect only the transfer of 30 units of currency C from subnetwork 110a to subnetwork 112a.

[0034] In some embodiments, the base commits and state commits stored in the global ledger may be stored in separate partitions of the global ledger. More information regarding the use of partitions in blockchains can be found in U.S. patent application Ser. No. 15 / 211,111, filed July 15, 2016, by Steven Charles Davis, entitled “Method and System for Partitioned Blockchains and Enhanced Privacy for Permissioned Blockchains,” which is incorporated herein by reference in its entirety. In such embodiments, the base commits and state commits may each be stored in different subnets included in a single block.

[0035] In some embodiments, the global ledger may include audit and verification data related to data stored in subnetwork 110's blockchain. For example, if subnetwork 110 operates a private blockchain, data related to proof of custody, ownership verification, and the like may be collected and stored in the global ledger. Such proofs can be provided without sacrificing the privacy and private state of the blockchain by using time-bound queries, as described in U.S. patent application Ser. No. 16 / 221,992, filed December 17, 2018, by Rakesh Yadav et al., entitled "Method and System for Consent to Time-Bound Queries in a Blockchain," the entire contents of which are incorporated herein by reference. Data collected from such queries can be stored as a separate type of submission in the global ledger. If partitions are used in the global ledger, such submissions can be stored in their own partition, separate from the partitions used for base and state submissions.

[0036] The methods and systems discussed herein enable data from multiple different subnetworks 110 to be stored in a global ledger that is consistent across all multiple blockchains operated by the subnetworks 110. Using base commits and state commits to maintain the global ledger ensures that each subnetwork 110 can operate its own type of blockchain in a blockchain-agnostic manner, where each subnetwork 110 can operate different types of blockchains with varying transaction volumes without impacting the operation and success of the global ledger. The solution provided by the methods and systems discussed herein is also scalable and works for any number of subnetworks 110, and also works in situations where the subnetworks 110 themselves can operate a global ledger for their own subnetworks, etc. The result is a horizontally and vertically scalable solution that is agnostic to blockchain format and type, providing a consistent and auditable ledger for the state of each blockchain operated by all subnetworks 110 involved in the system 100.

[0037] Processing Server

[0038] Figure 2 An embodiment of the processing server 102 in the system 100 is shown. It will be clear to those skilled in the relevant art that Figure 2 The illustrated embodiment of the processing server 102 is provided for illustration only and may not be exhaustive of all possible configurations of the processing server 102 suitable for performing the functions discussed herein. Figure 5 The computer system 500 shown in FIG and discussed in more detail below may be a suitable configuration for the processing server 102. In some cases, the overall node 108 and the sub-network nodes 112 in the system 100 may be connected to Figure 2 Processing server 102 or Figure 5 The computer system 500 in FIG. 1 is similarly configured, such as to include the components shown therein.

[0039] The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data via one or more networks via one or more network protocols. In some cases, the receiving device 202 may be configured to receive data from the master node 108, the sub-network node 112, and other systems and entities via one or more communication methods (such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, the Internet, etc.). In some embodiments, the receiving device 202 may include multiple devices, such as different receiving devices for receiving data via different networks, such as a first receiving device for receiving data via a local area network and a second receiving device for receiving data via the Internet. The receiving device 202 may receive an electronically transmitted data signal, wherein the data may be superimposed on the data signal or otherwise encoded on the data signal and received by the receiving device 202 and decoded, parsed, read, or otherwise obtained. In some cases, the receiving device 202 may include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, receiving device 202 may include a parser program configured to receive data signals and transform the received data signals into usable inputs for functions executed by a processing device to perform the methods and systems described herein.

[0040] The receiving device 202 may be configured to receive data signals electronically transmitted by the master node 108, the data signals being superimposed with or otherwise encoded with the base submission. The receiving device 202 may also be configured to receive data signals electronically transmitted by the sub-network node 112, the data signals being superimposed with or otherwise encoded with the state submission of the sub-network blockchain. In the event that additional submissions may be received in connection with time-limited queries, the receiving device 202 may receive data signals superimposed with or otherwise encoded with them, which may be received from the sub-network node 112 or a third-party system (such as a regulatory body that audits and oversees the sub-network blockchain).

[0041] Processing server 102 may also include a communication module 204. Communication module 204 may be configured to transfer data between modules, engines, databases, memories, and other components of processing server 102 for performing the functions discussed herein. Communication module 204 may include one or more communication types and utilize various communication methods for communication within the computing device. For example, communication module 204 may include a bus, contact pin connectors, wires, etc. In some embodiments, communication module 204 may also be configured to facilitate communication between internal components of processing server 102 and components external to processing server 102 (such as externally connected databases, display devices, input devices, etc.). Processing server 102 may also include a processing device. As will be apparent to those skilled in the relevant art, the processing device may be configured to perform the functions of processing server 102 discussed herein. In some embodiments, the processing device may include and / or be composed of multiple engines and / or modules specifically configured to perform one or more functions of the processing device (such as query module 210, generation module 212, hashing module 214, etc.). As used herein, the term "module" can be software or hardware that is specifically programmed to receive input, perform one or more processes using the input, and provide output. Based on this disclosure, the input, output, and processes performed by the various modules will be clear to those skilled in the art.

[0042] Processing server 102 may include a query module 210. Query module 210 may be configured to execute queries against a database to identify information. Query module 210 may receive one or more data values ​​or query strings and execute the query strings against a designated database (such as memory 218 of processing server 102) to identify information stored therein. Query module 210 may then output the identified information to an appropriate engine or module of processing server 102 as needed. For example, query module 210 may execute a query against blockchain data 206 in processing server 102 to identify the block header of a recent block in the global ledger to use in generating the block header of a new block.

[0043] The processing server 102 may also include a generation module 212. The generation module 212 may be configured to generate data for use by the processing server 102 in performing the functions discussed herein. The generation module 212 may receive instructions as input, may generate data based on the instructions, and may output the generated data to one or more modules of the processing server 102. For example, the generation module 212 may be configured to generate new block headers, blocks, and other data for use in operating and maintaining the global ledger.

[0044] The processing server 102 may also include a hash module 214. The hash module 214 may be configured to apply hashing algorithms to data to generate hash values, which may be used to perform the functions of the processing server 102 discussed herein. The hash module 214 may receive data as input, and may apply one or more hashing algorithms to the data to obtain hash values, and may output the resulting hash values ​​to another module or engine of the processing server 102. For example, the hash module 214 may be configured to hash block headers, hash blockchain data values ​​(e.g., base commits, state commits, etc.), and other data discussed herein.

[0045] The processing server 102 may also be configured to store blockchain data 206. The blockchain data 206 may include all data associated with the global ledger and used in the system 100, including the global ledger itself (e.g., the plurality of blocks comprising the global blockchain ledger) and any other data used therein. The global ledger may include a plurality of blocks, wherein each block includes at least a block header and one or more blockchain data values, the blockchain data values ​​including at least one of a base commit, a state commit, or a compliance (comp) commit (which may represent the results of a time-limited query as discussed above).

[0046] Processing server 102 may also include memory 218. Memory 218 may be configured to store data, such as public and private keys, symmetric keys, and the like, for use by processing server 102 in performing the functions discussed herein. Memory 218 may be configured to store data using suitable data formatting methods and schemas and may be any suitable type of memory, such as read-only memory, random access memory, and the like. As will be apparent to those skilled in the relevant art, memory 218 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications of processing devices, and other data that may be suitable for use by processing server 102 in performing the functions discussed herein. In some embodiments, memory 218 may be comprised of or otherwise include a relational database that uses a structured query language for storing, identifying, modifying, updating, accessing, and the like structured data sets stored therein. Memory 218 may be configured to store, for example, cryptographic keys, salts, nonces, communication information between master node 108 and sub-network nodes 112, data for predetermined time periods of status submissions, and the like.

[0047] The computing device 102 may also include a transmitting device 216. The transmitting device 216 may be configured to transmit data over one or more networks via one or more network protocols. In some cases, the transmitting device 216 may be configured to transmit data to the master node 108, the sub-network node 112, and other entities via one or more communication methods, such as a local area network, a wireless local area network, a cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmitting device 216 may include multiple devices, such as different transmitting devices for transmitting data over different networks, such as a first transmitting device for transmitting data over a local area network and a second transmitting device for transmitting data over the Internet. The transmitting device 216 may electronically transmit a data signal superimposed with data that can be parsed by the receiving computing device. In some cases, the transmitting device 216 may include one or more modules for superimposing, encoding, or otherwise formatting data into a data signal suitable for transmission.

[0048] The transmitting device 216 may be configured to electronically transmit a data signal to the master node 108, which may be superimposed with or otherwise encoded with a request for base submission data. The transmitting device 216 may also be configured to electronically transmit a data signal to the sub-network node 112, which may be superimposed with or otherwise encoded with a request for state submission, such as at predetermined time periods. Some transmissions to the sub-network node 112 may include requests for compliance submissions, which may be forwarded to a verification entity to perform a time-limited query to confirm compliance with regulations or perform other verification of blockchain data. In some cases, such verification may only be performed if the sub-network blockchain is a private or permissioned blockchain.

[0049] Operation and maintenance of the global blockchain ledger

[0050] Figure 3 Shown in Figure 1 An example process for maintaining a consistent global blockchain ledger performed in the system 100 includes receiving and including base submissions, compliance submissions, and state submissions in the global ledgers of two subnetworks 110.

[0051] like Figure 3As shown, issuing authority 104 may execute the issuance of a value, such as 100 units of COIN, which may be recorded in a ledger 302, such as that operated by the overall network 106 in system 100. Ledger 302 may store that issuing authority 104 possesses 100 units of COIN and that the 100 units of COIN have been divided into two groups of 50 units each. Issuing authority 104 may then distribute each of the two groups of 50 units of COIN to subnetworks 110a and 110b. Ledger 302 may store data regarding the issuance of COIN and submit a base commit of the issuance event to processing server 102 for storage in global ledger 306. Global ledger 306 may include a new block, in which the base commit may be stored in its BASE partition.

[0052] Each subnetwork 110 may receive distributed COIN, which may be stored in and used by its corresponding subledger 304. At predetermined time periods, each subnetwork 110 may generate a state submission representing the state of its subledger 304, such as by hashing the most recent block header in the subledger 304. The state submission may be submitted to the processing server 102 and included in a new block added to the global ledger 306, where the state submission may be stored in the STAT partition of the global ledger 306.

[0053] Atomic swaps can be performed to allow subnetworks 110 to transfer COIN between each other. When performing an atomic swap, the issuing authority 104 can act as a mediator to ensure that the subnetwork 110 transferring COIN is issued a sufficient amount to make such a transfer. Information about the transfer can be reflected in a new base submission provided to the general ledger 302 and the global ledger 306 for storage in the BASE partition.

[0054] In embodiments where compliance submissions can be collected, a validator 308 can be used to validate information stored in a subledger 304. Such information can be included in a compliance submission submitted to the processing server 102 by a subnetwork node 112 operating the corresponding subledger or by the validator 308. The compliance submission can be stored in a new block added to the global ledger 306, where, if partitioning is used, the compliance submission can be stored in a COMP partition included in the global ledger 306.

[0055] Example Method for Maintaining a Consistent Blockchain Ledger

[0056] Figure 4 A method 400 is shown for maintaining a consistent blockchain ledger for storing commits across multiple blockchains in a manner that is agnostic to the type of blockchain and that is vertically and horizontally scalable for any number of blockchains.

[0057] In step 402, a blockchain (e.g., global ledger 306) including a plurality of blocks may be stored in a memory (e.g., blockchain data 206, memory 218, etc.) of a processing server (e.g., processing server 102), each block including at least a block header and one or more blockchain data values. In step 404, a base submission may be received by a receiver (e.g., receiving device 202) of the processing server from a first node (e.g., master node 108), wherein the first node is included in a first blockchain network (e.g., master network 106).

[0058] In step 406, a first new block may be generated by a processor of the processing server (e.g., generation module 212), the first new block including at least a first block header and the received base commit. In step 408, the first new block may be stored in a blockchain in a memory of the processing server. In step 410, a receiver of the processing server may receive state commits from additional nodes (e.g., subnetwork node 112) included in each of at least two additional blockchain networks (e.g., subnetwork 110).

[0059] In step 412, an additional new block may be generated by the processor of the processing server, wherein the additional new block includes at least the additional block header and each received state commit. In step 414, the additional new block may be stored in the blockchain in the memory of the processing server.

[0060] In one embodiment, a state submission may be received at a predetermined time. In some embodiments, each state submission may be a hash value generated by applying a hash algorithm to the header of a most recent block included in a blockchain associated with the corresponding additional blockchain network. In one embodiment, each of the at least two additional blockchain networks may include at least one public blockchain and at least one private blockchain. In some embodiments, the base submission may be a hash value generated by applying a hash algorithm to a grant event describing a grant of cryptocurrency to the at least two additional blockchain networks.

[0061] In one embodiment, method 400 may further include repeating, by the processing server, the second receiving step, the generating step, and the storing step for new state submissions from additional nodes included in each of the at least two additional blockchain networks. In another embodiment, the second receiving step, the generating step, and the storing step may be repeated after a predetermined period of time. In some embodiments, the first new block and the additional new blocks may be stored in separate partitions within a single block added to the blockchain.

[0062] Computer system architecture

[0063] Figure 5 A computer system 500 is shown in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the present disclosure may be implemented in the computer system 500 using hardware, software, firmware, a non-transitory computer-readable medium having instructions stored thereon, or a combination thereof. Figure 1 The processing server 102 and backend system in the embodiment of the present invention may be implemented in one or more computer systems or other processing systems. Figure 1 The processing server 102 and backend system in the hardware, software or any combination thereof can be embodied to implement Figure 3 and Figure 4 Modules and components of the method.

[0064] If programmable logic is used, such logic can be executed on a commercially available processing platform configured by executable software code to become a special-purpose computer or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). One of ordinary skill in the art will recognize that the embodiments of the disclosed subject matter can be practiced using a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functionality, and microcomputers that are ubiquitous or embeddable in virtually any device. For example, the above-described embodiments can be implemented using at least one processor device and memory.

[0065] The processor unit or processor device discussed herein may be a single processor, a plurality of processors, or a combination thereof. A processor device may have one or more processor "cores." As discussed herein, the terms "computer program medium," "non-transitory computer-readable medium," and "computer-usable medium" are generally used to refer to tangible media, such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512.

[0066] Various embodiments of the present disclosure are described with reference to this example computer system 500. After reading this specification, it will become clear to those skilled in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processes, some operations may actually be performed in parallel, concurrently, and / or in a distributed environment, with program code stored locally or remotely for access by single or multiple processor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0067] Processor device 504 can be a dedicated processor device or a general purpose processor device specially configured to perform the function discussed herein. Processor device 504 can be connected to communication infrastructure 506, such as bus, message queue, network, multi-core message transmission scheme etc. Network can be any network suitable for performing the function disclosed herein, and can include local area network (LAN), wide area network (WAN), wireless network (for example, WiFi), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be clear to those skilled in the art. Computer system 500 can also include main memory 508 (for example, random access memory, read-only memory etc.), and can also include auxiliary storage 510. Auxiliary storage 510 can include hard disk drive 512 and removable storage drive 514, such as floppy disk drive, tape drive, optical disk drive, flash memory etc.

[0068] Removable storage drive 514 can read from and / or write to removable storage unit 518 in a well-known manner. Removable storage unit 518 can include removable storage media that can be read from and written to by removable storage drive 514. For example, if removable storage drive 514 is a floppy disk drive or a universal serial bus port, removable storage unit 518 can be a floppy disk or a portable flash drive, respectively. In one embodiment, removable storage unit 518 can be a non-transitory computer-readable recording medium.

[0069] In some embodiments, secondary memory 510 may include optional means for allowing computer programs or other instructions to be loaded into computer system 500, such as a removable storage unit 522 and interface 520. As will be apparent to those skilled in the relevant art(s), examples of such means may include a program cartridge and cartridge interface (e.g., as found in video game systems), a removable memory chip (e.g., EEPROM, PROM, etc.) and associated socket, and other removable storage units 522 and interfaces 520.

[0070] The data stored in the computer system 500 (e.g., in the main memory 508 and / or the secondary memory 510) can be stored on any type of suitable computer-readable medium, such as an optical storage device (e.g., a compact disk, a digital versatile disk, a Blu-ray disk, etc.) or a tape storage device (e.g., a hard drive). The data can be configured in any type of suitable database configuration (e.g., a relational database, a structured query language (SQL) database, a distributed database, an object database, etc.). Suitable configurations and storage types will be clear to those skilled in the relevant art.

[0071] The computer system 500 may also include a communication interface 524. The communication interface 524 may be configured to allow software and data to be transferred between the computer system 500 and external devices. Exemplary communication interfaces 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, and the like. The software and data transferred via the communication interface 524 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals that will be apparent to those skilled in the relevant art. The signals may travel via a communication path 526, which may be configured to carry the signals and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, and the like.

[0072] The computer system 500 may also include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a High-Definition Multimedia Interface (HDMI), a Digital Video Interface (DVI), a Video Graphics Array (VGA), or the like. The display 530 may be any suitable type of display for displaying data transferred via the display interface 502 of the computer system 500, including cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light emitting diode (LED) displays, capacitive touch displays, thin film transistor (TFT) displays, and the like.

[0073] Computer program media and computer usable media may refer to memories, such as main memory 508 and secondary memory 510, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be a means for providing software to the computer system 500. Computer programs (e.g., computer control logic) may be stored in the main memory 508 and / or the secondary memory 510. The computer program may also be received via the communication interface 524. Such a computer program, when executed, may enable the computer system 500 to implement the present methods discussed herein. In particular, the computer program, when executed, may enable the processor device 504 to implement the methods discussed herein. Figure 3 and Figure 4 Thus, such a computer program may represent a controller of the computer system 500. Where software is used to implement the present disclosure, the software may be stored in a computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard drive 512 or the communication interface 524.

[0074] The processor device 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware, and in some cases may also utilize software such as corresponding to program code and / or programs stored in the main memory 508 or the auxiliary memory 510. In such a case, the program code may be compiled by the processor device 504 (e.g., by compiling the module or engine) before being executed by the hardware of the computer system 500. For example, the program code may be source code written in a programming language that is converted into a low-level language such as assembly language or machine code for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-guided conversion, code generation, code optimization, and any other technology that may be suitable for converting the program code into a low-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. It will be apparent to those skilled in the relevant art that such a process results in the computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions discussed above.

[0075] Among other features, technology consistent with the present disclosure provides systems and methods for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains. While various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they have been presented for purposes of illustration only and not limitation. They are not intended to be exhaustive and do not limit the disclosure to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosure without departing from its breadth or scope.

Claims

1. A method for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains, comprising the following steps: storing, in a memory of the processing server, a blockchain comprising a plurality of blocks, each block comprising at least a block header and one or more blockchain data values; receiving, by a receiver of the processing server, a base submission from a first node included in a first blockchain network, the base submission referencing transmission of data to a plurality of separate blockchain networks; generating, by a processor of the processing server, a first new block, the first new block including at least a first block header and a base commit received from a first node included in a first blockchain network; storing a first new block in the blockchain in a memory of the processing server; receiving, by a receiver of the processing server, a state submission from each of the plurality of separate blockchain networks referenced by the base submission, wherein the state submission represents a state of a blockchain respectively associated with the plurality of separate blockchain networks; generating, by a processor of the processing server, an additional new block, the additional new block comprising at least an additional block header and each received state commit; and Storing the additional new block in the blockchain in a memory of the processing server.

2. The method according to claim 1, wherein The status submission is received at a predetermined time.

3. The method according to claim 1, wherein Each state commit is a hash value generated by applying a hashing algorithm to a header of a most recent block included in a blockchain associated with a corresponding blockchain network of the plurality of separate blockchain networks.

4. The method according to claim 1, wherein Each of the plurality of separate blockchain networks includes at least one public blockchain and at least one private blockchain.

5. The method according to claim 1, wherein The base submission is a hash value generated by applying a hashing algorithm to a release event describing a release of cryptocurrency to the plurality of separate blockchain networks.

6. The method of claim 1 , further comprising: The steps of receiving the state submission, generating an additional new block, and storing the additional new block are repeated by the processing server for a new state submission from each of the plurality of separate blockchain networks.

7. The method according to claim 6, wherein: The steps of receiving a state submission, generating an additional new block, and storing the additional new block are repeated after a predetermined period of time.

8. The method of claim 1, wherein: The first new block and the additional new blocks are stored in separate partitions in a single block that is added to the blockchain.

9. A system for maintaining a consistent blockchain ledger to store commits across multiple separate blockchains, comprising: Processing Server; A first node, included in a first blockchain network; and Multiple separate blockchain networks, each comprising additional nodes, where The processing server includes A memory for storing a blockchain comprising a plurality of blocks, each block comprising at least a block header and one or more blockchain data values, a receiver that receives a base submission from a first node included in a first blockchain network, the base submission referencing the transmission of data to the plurality of separate blockchain networks, and A processor generates a first new block, the first new block including at least a first block header and a base commit received from a first node included in a first blockchain network, wherein The memory of the processing server further stores the first new block in the blockchain, The receiver further receives a state submission from each of the plurality of separate blockchain networks referenced by the base submission, wherein the state submission represents a state of a blockchain associated with each of the plurality of separate blockchain networks, and the processor further generates an additional new block, the additional new block including at least an additional block header and each received state submission, and The memory also stores the additional new block in the blockchain.

10. The system of claim 9, wherein: The status submission is received at a predetermined time.

11. The system of claim 9, wherein: Each state commit is a hash value generated by applying a hashing algorithm to a header of a most recent block included in a blockchain associated with a corresponding blockchain network of the plurality of separate blockchain networks.

12. The system of claim 9, wherein: Each of the plurality of separate blockchain networks includes at least one public blockchain and at least one private blockchain.

13. The system of claim 9, wherein: The base submission is a hash value generated by applying a hashing algorithm to a release event describing a release of cryptocurrency to the plurality of separate blockchain networks.

14. The system of claim 9, wherein: The processing server repeats, for each of the plurality of separate blockchain networks, the operations of receiving a state submission, generating an additional new block, and storing the additional new block.

15. The system of claim 14, wherein: The operations of receiving the state submission, generating an additional new block, and storing the additional new block are repeated after a predetermined period of time.

16. The system of claim 9, wherein: The first new block and the additional new blocks are stored in separate partitions in a single block that is added to the blockchain.

17. A method for maintaining a consistent blockchain ledger, comprising the steps of: receiving, by a receiver of the processing server, a base submission from a first node included in a first blockchain network, the base submission referencing transmission of data to a plurality of separate blockchain networks; generating, by a processor of the processing server, a first new block including at least the base submission; receiving, by a receiver of a processing server, a state submission from each of the plurality of separate blockchain networks referenced by the base submission, wherein the state submission represents a state of a blockchain respectively associated with the plurality of separate blockchain networks; and An additional new block is generated by a processor of the processing server, the additional new block including at least each received state submission.

18. The method of claim 17, wherein: The status submission is received at a predetermined time.

19. The method of claim 17, wherein: Each state commit is a hash value generated by applying a hashing algorithm to a header of a most recent block included in a blockchain associated with a corresponding blockchain network of the plurality of separate blockchain networks.

20. The method of claim 17, wherein: Each of the plurality of separate blockchain networks includes at least one public blockchain and at least one private blockchain.

21. The method of claim 17, wherein: The base submission is a hash value generated by applying a hashing algorithm to a release event describing a release of cryptocurrency to the plurality of separate blockchain networks.

22. The method of claim 17, further comprising: The steps of receiving the state submission and generating an additional new block are repeated by the processing server for a new state submission from each of the plurality of separate blockchain networks.

23. The method of claim 22, wherein: The steps of receiving state submissions and generating additional new blocks are repeated after a predetermined period of time.

24. The method of claim 17, wherein: The first new block and the additional new blocks are stored in separate partitions in a single block that is added to the blockchain.

25. The method of claim 17, further comprising: The blockchain including the first new block is stored in a memory of the processing server.

26. The method of claim 17, further comprising: The blockchain including the appended new block is stored in a memory of the processing server.

27. A system for maintaining a consistent blockchain ledger, comprising: Processing Server; A first node, included in a first blockchain network; and Multiple separate blockchain networks, each comprising additional nodes, where The processing server includes a receiver that receives a base submission from a first node included in a first blockchain network, the base submission referencing the transmission of data to the plurality of separate blockchain networks, and A processor generates a first new block including at least the received base submission, wherein The receiver also receives a state submission from each of the plurality of separate blockchain networks referenced by the base submission, wherein the state submission represents a state of a blockchain respectively associated with the plurality of separate blockchain networks, and The processor also generates an additional new block that includes at least each received state commit.

28. The system of claim 27, wherein: The status submission is received at a predetermined time.

29. The system of claim 27, wherein: Each state commit is a hash value generated by applying a hashing algorithm to a header of a most recent block included in a blockchain associated with a corresponding blockchain network of the plurality of separate blockchain networks.

30. The system of claim 27, wherein: Each of the plurality of separate blockchain networks includes at least one public blockchain and at least one private blockchain.

31. The system of claim 27, wherein: The base submission is a hash value generated by applying a hashing algorithm to a release event describing a release of cryptocurrency to the plurality of separate blockchain networks.

32. The system of claim 27, wherein: The processing server repeats the operations of receiving state submissions and generating additional new blocks for new state submissions from each of the plurality of separate blockchain networks.

33. The system of claim 32, wherein: The operations of receiving the state submission and generating an additional new block are repeated after a predetermined period of time.

34. The system of claim 27, wherein: The first new block and the additional new blocks are stored in separate partitions in a single block that is added to the blockchain.

35. The system of claim 27, wherein: The processor also includes a memory configured to store a blockchain including the first new block.

36. The system of claim 27, wherein: The processor also includes a memory configured to store the blockchain including the appended new block.

Images