Customized Blockchain Infrastructure

Abstract

Various aspects of the subject technology relate to a system, method, and machine-readable medium for generating a heterogeneous network of blockchains. The method includes generating a platform blockchain having a single replicated state machine. The method includes generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and generating causes merging or burning of underlying assets of the platform blockchain. The method includes designating validators for the at least one subnet. The platform blockchain includes a source of truth for transactions across the subnet.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This disclosure is related to and claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 63 / 405,322 by Kevin SEKNIQI et al., entitled CUSTOMIZED BLOCKCHAIN ​​INFRASTRUCTURE, filed September 9, 2022, the contents of which are incorporated herein by reference in their entirety for all purposes.

[0002] The present disclosure relates generally to blockchain technology, and more particularly to customized blockchain infrastructure. [Background technology]

[0003] Traditional blockchain technology includes a growing list of records called blocks that are linked together using cryptography. Each block contains a cryptographic hash of the previous block and additional fields for modifying the state of the blockchain. Such fields may include, but are not limited to, a timestamp, transaction data, and a concise summary of the current state (often represented as the root hash of a Merkle tree). If a timestamp is provided, it serves as an upper bound on the time at which the block and all its fields were published. Blocks form a chain because each contains information about its previous block. Thus, blockchains are resistant to data changes because, once recorded, the data in any given block cannot be retroactively changed without changing all subsequent blocks. However, traditional blockchain technology is rigid, making it difficult to scale or otherwise customize blockchains without writing them from scratch or making significant modifications to existing implementations. Summary of the Invention

[0004] The present disclosure provides systems and methods for creating customized blockchain infrastructures. In one aspect, a single replicated state machine is created as the source of truth for validator sets for all subnets. The validator sets are sufficient for each set to coordinate and validate dynamically specified blockchain definitions. Additionally, these validator sets are sufficient for the sets to define customized communication protocols between different validator sets. For example, a subnet includes a dynamic set of validators that collaborate to achieve consensus on the state of the blockchain set. According to aspects, any user of a network (e.g., the AVALANCHE network) can create a subnet. This creation may result in the merging (or burning) of underlying assets (e.g., cryptocurrency). The cost of running a subnet may be associated with the number of validators on the subnet and the number of intra- and inter-subnet transactions the subnet performs. According to aspects, validators are designated for the subnet on a single replicated state machine. According to aspects, each subnet may utilize a common reward module. According to aspects, the state of the subnet can be kept private. In one implementation, cross-subnet transfers can be built on top of existing cross-chain interactions by utilizing a threshold signature scheme (e.g., a multi-signature scheme, a threshold signature scheme, or other cryptographic proof of participation).

[0005] According to one embodiment of the present disclosure, a computer-implemented method for generating a heterogeneous network of blockchains is provided. The method includes generating a platform blockchain having a single replicated state machine. The method also includes generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and generating triggers merging or burning of underlying assets of the platform blockchain. The method also includes designating validators for the at least one subnet. The platform blockchain includes a source of truth for transactions across the subnet.

[0006] According to one embodiment of the present disclosure, a system is provided that includes a processor and a memory containing instructions stored thereon, which, when executed by the processor, cause the processor to perform a method for generating a heterogeneous network of blockchains. The method includes generating a platform blockchain having a single replicated state machine. The method includes generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating triggers merging or burning of underlying assets of the platform blockchain. The method includes designating a validator for the at least one subnet. The platform blockchain includes a source of truth for transactions across the subnet.

[0007] According to one embodiment of the present disclosure, a non-transitory computer-readable storage medium is provided that includes instructions (e.g., a stored sequence of instructions), which, when executed by a processor, cause the processor to perform a method for generating a heterogeneous network of blockchains. The method includes generating a platform blockchain having a single replicated state machine. The method includes generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating triggers the merging or burning of underlying assets of the platform blockchain. The method includes designating a validator for the at least one subnet. The platform blockchain includes a source of truth for transactions across the subnet.

[0008] According to one embodiment of the present disclosure, a system is provided that includes means for storing instructions and means for executing the stored instructions, the instructions, when executed by the means, causing the means to perform a method for generating a heterogeneous network of blockchains. The method includes generating a platform blockchain having a single replicated state machine. The method includes generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating triggers merging or burning of underlying assets of the platform blockchain. The method includes designating a validator for the at least one subnet. The platform blockchain includes a source of truth for transactions across the subnet.

[0009] In yet another embodiment, a computer-implemented method for managing a blockchain network architecture includes receiving, from a first network node, a hashed data block for addition to a first blockchain in the network. The computer-implemented method also includes requesting one or more validators in the network to validate the hashed data block, receiving validation credentials from each of the one or more validators, selecting a first validator based on the validation credentials, generating a hash of the first blockchain and the hashed data block using a first key when the first validator validates the hashed data block, and providing the first key to a first network subscriber to access the first blockchain. [Brief explanation of the drawings]

[0010] To easily identify the discussion of any particular element or act, the most significant digit(s) of a reference number refers to the number of the figure in which that element is first introduced.

[0011] [Figure 1] 1 illustrates a network architecture that supports applications for managing blockchain assets, according to some embodiments. [Figure 2] 1 illustrates an exemplary blockchain system for practicing some implementations of the present disclosure. [Figure 3] 1 illustrates a blockchain infrastructure in accordance with certain aspects of the present disclosure. [Figure 4] 1 illustrates a system configured to create a heterogeneous network of blockchains, according to one or more implementations. [Figure 5A] 1 illustrates a proof-of-work process for adding and validating blocks in a blockchain that is part of a customized blockchain network, according to some embodiments. [Figure 5B]1 illustrates a proof-of-stake process for adding and validating blocks in a blockchain that is part of a customized blockchain network, according to some embodiments. [Figure 6] 1 illustrates a threshold signature scheme (TSS) for generating digital signatures from multiple participants in a customized blockchain, according to some embodiments. [Figure 7] 1 illustrates an example flow diagram for generating a blockchain network, according to certain aspects of the present disclosure. [Figure 8] 1 illustrates an example flow diagram for managing a blockchain network, according to certain aspects of the present disclosure. [Figure 9] 1 is a block diagram illustrating an exemplary computer system (e.g., representing both a client and a server) in which aspects of the subject technology may be implemented.

[0012] In one or more implementations, not all of the components depicted in each figure may be required, and one or more implementations may include additional components not shown in the figures. The arrangement and types of components may be changed without departing from the scope of the present disclosure. Additional, different, or fewer components may be utilized within the scope of the subject disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and techniques are not shown in detail so as not to obscure the present disclosure.

[0014] Traditional blockchain technology includes a growing list of records called blocks that are linked using cryptography. Each block contains a cryptographic hash of the previous block and additional fields for modifying the state of the blockchain. Such fields may include, but are not limited to, a timestamp, transaction data, and a concise summary of the current state (often represented as the root hash of a Merkle tree). If a timestamp is provided, it serves as an upper bound on the time at which the block and all its fields were published. Because blocks each contain information about their predecessor, they form a chain. Thus, blockchains are resistant to data changes because, once recorded, the data in any given block cannot be retroactively changed without changing all subsequent blocks. However, traditional blockchain technology is rigid, making it difficult to scale or otherwise customize blockchains without writing them from scratch or making significant modifications to existing implementations.

[0015] Subnets allow networks to scale beyond a single replicated state, providing scalability beyond traditional blockchain technology, for example, by hosting multiple blockchains on customized virtual machines. However, as these systems become more widespread, their validator requirements increase significantly due to state and execution requirements. As a result, traditional blockchain approaches suffer from various drawbacks, including limited flexibility in the execution engine due to the amount of computation performed, which prevents validators from actively choosing what they are validating. Other drawbacks include a limited number of supported subnets (e.g., 100 subnets or less), no validator set or reward management, the requirement that the virtual machine be able to compile to a specific code language (e.g., WebAssembly or WASM), and a very limited execution engine.

[0016] The present subject disclosure overcomes the above-described shortcomings by providing systems and methods for creating customized blockchain infrastructures. In one aspect, a single replicated state machine is created as the source of truth for validators in all subnets. In some embodiments, a single replicated state machine may be created as the source of truth for validators and their rewards. In some embodiments, a single replicated state machine may be created as the source of truth for cross-subnet interactions (e.g., on a platform chain) for all managed subnets, guaranteeing delivery receipt for senders. For example, a subnet includes a dynamic set of validators that collaborate to achieve consensus on the state of a set of blockchains. According to an aspect, any user of a blockchain network disclosed herein can create a subnet. This creation may result in the merging (or burning) of underlying assets (e.g., cryptocurrency or other digital assets). The cost of running a subnet may be associated with the number of validators on the subnet and the number of intra- and inter-subnet transactions the subnet performs. According to an aspect, validators are designated for the subnet on a single replicated state machine. According to an aspect, each subnet may utilize a common reward module. According to aspects, the state of the subnets can be kept private. In one implementation, cross-subnet transfers can be built on top of existing cross-chain interactions by utilizing a threshold signature scheme.

[0017] According to aspects, there are multiple ways to specify who can be a validator for a subnet, including, but not limited to, proof-of-stake, where an asset is named by the creator of the subnet, proof-of-authority, where an authority is designated by the creator of the subnet, etc. This allows all other subnets to know who the validators are for the subnet. If other subnets do not know the validators for the subnet, they cannot validate cross-subnet transactions.

[0018] According to an aspect, each subnet may utilize a common reward module. The common reward module allows validators to discover the profitability of validating a subnet. This results in a significantly better validator experience for choosing which subset to validate.

[0019] According to an aspect, because the state of a subnet does not have to conform to any pre-specified format, the logic implemented in that subnet can be entirely generic and kept private. This creates a heterogeneous network of state managers. Additionally, participants in different subnets may be required to have additional requirements beyond the basic requirements of the primary network.

[0020] According to aspects, since subnets can specify their own logic, fee structures can be implemented by subnet creators (e.g., users). In one implementation, fees can be paid in custom assets, fees can be paid via proof-of-work, and / or any other programmable fee implementation. In one aspect, there may be no fees.

[0021] According to aspects, a subnet does not necessarily need to implement a consensus protocol, since it utilizes an existing consensus engine (e.g., provided via a software development kit (SDK) / plug-in interface). In some implementations, the subnet 302 can additionally define a network protocol. For example, the subnet may implement a distributed hash table (DHT) using membership knowledge instead of or in addition to consensus.

[0022] According to aspects, cross-subnet transfers can build on existing cross-chain interactions by utilizing a threshold signature scheme. Specifically, by posting a threshold-signed transaction to a single shared state, the results of that transaction can be consumed by all chains on the network.

[0023] The disclosed system addresses a traditional blockchain problem tied to computer technology: the technical problem of bringing scalability and extensibility to a blockchain. The disclosed system solves this technical problem by providing a solution that is also rooted in computer technology: a system and method for creating a customized blockchain infrastructure. The disclosed system also improves the functionality of the computer itself, reducing the cost of system resources and improving data processing.

[0024] As used herein, the term "blockchain" generally refers to an open, distributed, public ledger containing a growing list of records that are linked using cryptography. By design, blockchains are resistant to data modifications. Blockchains can include auditable databases that provide a decentralized, replicated ledger of cryptographically authenticated artifacts. The content of the artifacts is very difficult to tamper with without detection, thus providing a high probability of being a true copy of the intended content, and the content is open for inspection via a suitable query interface.

[0025] As used herein, the term "block" generally refers to a record maintained within a blockchain. For example, each block contains a cryptographic hash of the previous block and additional fields for modifying the state of the blockchain. The additional fields may include, but are not limited to, a timestamp, transaction data, and a concise summary of the current state (often represented as the root hash of a Merkle tree).

[0026] As used herein, the terms "subnet" or "subnetwork" generally refer to a dynamic set of validators that cooperate to achieve consensus on the state of a set of blockchains. For example, each blockchain is validated by exactly one subnet. A subnet can validate arbitrarily many blockchains. A validator node can be a member of arbitrarily many subnets. A subnet may manage its own membership and may require its constituent validators to have certain properties.

[0027] As used herein, the term "primary network" generally refers to a special subnet that validates an embedded blockchain. Members of the subnet may be members of the primary network. In some embodiments, subjects that are members of the primary network stake (e.g., acquire or "purchase") one or more tokens from the primary network. As a result, blockchain validators can validate the embedded blockchain on the primary network and have staked primary network tokens.

[0028] According to aspects, subnets enable the creation of heterogeneous networks of blockchains that can communicate with each other. In embodiments disclosed herein, multiple validators supporting different blockchains can interact with each other. Thus, the system disclosed herein coordinates subnet interactions by learning the source of truth of the blockchain state (the validator set) and the interactions of the blockchain states. Additionally, the system incentivizes subnets to economically sustain validators.

[0029] While both forks and subnets support diverse underlying virtual machines (VMs) and their participants, subnets enable interoperability of different types of virtual machines from a main network (e.g., a primary network). Forks, on the other hand, split the network into isolated historical versions of the main network, making it difficult to maintain and communicate with the code base. Thus, in some embodiments, forking is temporal, while subnets are spatial.

[0030] Embodiments disclosed herein include subnets to facilitate operation and management of customized blockchains by reducing development time (e.g., from years to just weeks, days, or hours, depending on existing knowledge). Subnets also provide performance isolation, such that performance impacts on one of the subnets cannot affect other subnets unless the subnets are in communication with each other. Subnets also allow creators, minors, or administrators (e.g., users) to restrict, manage, and assign validators.

[0031] In some embodiments, a customized blockchain may include a VM marketplace with subnets served by unique VM modules that allow users to create sets of features targeted to specific needs. For example, a gaming application in a VM marketplace will have a different VM module than a financial application.

[0032] Exemplary System Architecture FIG. 1 illustrates a network architecture 100 supporting applications for managing a blockchain infrastructure, according to some embodiments. A server 130 and a database 152 are communicatively coupled to a client device 110 via a network 150. The server 130 may host applications running within the client device 110 that bridge subnets across multiple blockchains and handle their assets and transactions. The client device 110 may be used by blockchain users and administrators, including blockchain contributors, transaction validators, miners, smart contract parties, and the like. The client device 110 may include smartphones, laptops, mobile devices, palm devices, and even desktops. The network 150 may include, for example, any one or more of a local area network (LAN), a wide area network (WAN), the Internet, and the like. Furthermore, the network 150 may include any one or more of network topologies, including, but not limited to, a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, and the like. Database 152 may store backup files from blockchain transactions, smart contracts, signatures, and digital assets, including tokens, cryptocurrencies, smart contracts, and financial data. Additionally, database 152 may contain encrypted keys that may be distributed to each, many, and all of the blockchain users.

[0033] FIG. 2 illustrates an example blockchain 200 according to certain aspects of the present disclosure. For example, the blockchain system 200 may include a primary network. As shown, the blockchain system 200 includes several blocks 210a, 210b, and 210c (collectively referred to as "blocks 210"). For simplicity, three blocks 210 are shown. Each block 210 includes a previous hash 202a, 202b, and 202c (collectively referred to as "hashes 202"), a transaction root 204a, 204b, and 204c (collectively referred to as "transaction roots 204"), timestamps 206a, 206b, and 206c (collectively referred to as "timestamps 206"), and nonce 208a, 208b, and 208c (collectively referred to as "nonce 208"). According to one aspect of the present disclosure, nonce 208 may include a 32-bit field whose value is used as a mathematical challenge for users (e.g., contributors, users, or miners) of blockchain 200 to add new blocks (e.g., block 210b). The value of nonce 208 may be adjusted to speed up or slow down the addition of new blocks 210. When one of the miners discovers nonce 208b, the value is verified by other users (e.g., nodes) every time before block 210 is added to blockchain 200.

[0034] The previous hash 202 is a value obtained by hashing the previous block 210 in the blockchain system 200. For example, if block 210b is the Nth block of the blockchain 200, the previous hash 202b is the value of the hash of block N-1, which in this case is block 210a. Similarly, the previous hash 202c is the value of the hash of block 210b.

[0035] Transaction root 204 is the root hash value of a hash tree 220 (e.g., a Merkle tree) that spans all transactions 212a, 212b, 212c, and 212d (hereinafter collectively referred to as "transactions 212") added to block 210. For example, transaction 212 is added to block 210b. According to one aspect of the present disclosure, transaction 212 may be any type of transaction and may include any type of data of any length, such as a photograph, video, or audio recording. To add transactions 212 to blockchain system 200, each of transactions 212 is hashed to obtain hashed transactions 214a, 214b, 214c, and 214d (hereinafter collectively referred to as "hashed transactions 214"). For example, hashing transaction 212a produces hashed transaction 214a, hashing transaction 212b produces hashed transaction 214b, and so on.

[0036] Hashed transactions 214 are then hashed together to obtain hashes 216a and 216b (hereinafter collectively referred to as "hash 216"). For example, hashed transaction 214a is hashed with hashed transaction 214b to obtain hash 216a, and hashed transaction 214c is hashed with hashed transaction 214d to obtain hash 216b. Finally, hash 216a is hashed with hash 216b to obtain transaction root 204b. While hash tree 220 for block 210b is shown, it will be understood that transaction root 204 for block 210 in blockchain 200 may include a corresponding similar hash tree 220. As a result, each block 210 added to blockchain 200 is a confirmation of all transactions that occurred previously. Thus, the validity of blockchain 200 is permanent and immutable. In other words, it would be computationally impractical or impossible to secretly modify a block 210 in the blockchain 200 without the knowledge that the data has been altered.

[0037] In some embodiments, hashing may be accomplished using a cryptographic hash function, including but not limited to Secure Hash Algorithm (SHA) 0, SHA-1, SHA-2, SHA-3, ..., SHA-256, etc., or Digital Signature Hash Algorithm (DSA).

[0038] In some embodiments, blockchain 200 can include public distributed block headers, a technique known to meet the requirement of storing replicated artifacts in a publicly available distributed storage facility that cannot be tampered with and is readily available for inspection. According to one aspect, blockchain 200 can be a public blockchain or a private blockchain.

[0039] 3 illustrates an example customized blockchain 300 according to certain aspects of the present disclosure. For example, the blockchain infrastructure 300 may include a first subnet 302-1, a second subnet 302-2, a third subnet 302-3, and a fourth subnet 302-4 (collectively referred to herein as "subnets 302"), and a primary network 302-1 (e.g., "subnet 0") may comprise the primary network. In one implementation, the customized blockchain infrastructure 300 may be built on any given technology stack. Each subnet 302 includes general-purpose logic for conducting transactions within the blockchain 300.

[0040] In some embodiments, each subnet 302 may include multiple validators (e.g., nodes) for validating blockchain transactions. For example, second subnet 302-2 may include validators 304A, 304B, and 304C. Third subnet 302-3 may include validators 304C and 304D. Fourth subnet 302-4 may include validators 304E and 304F. As illustrated, second subnet 302-2 and third subnet 302-3 share validators 304C and 304D. Hereinafter, validators 304A, 304B, 304C, 304D, 304E, and 304F are collectively referred to as "validators 304." In one implementation, first subnet 302-1 may include subnets 302-2, 302-3, and 302-4. It is understood that more or fewer validators 304 and / or subnets 302 may be included without departing from the scope of the present disclosure. It is further understood that subnets 302 may have more or fewer validators 304 in common without departing from the scope of the present disclosure.

[0041] In some embodiments, validators 304 may stake one or more native tokens 308 or assets within a subnet as collateral for validating transactions, e.g., for proof-of-stake (PoS) validation. Native tokens 308 are minted or generated by the creator of the associated subnet (e.g., the validator itself) and collected in an asset pool 306. In some embodiments, validators 304 include a proof of authority (PoA) to back up their validation credentials. The authority is designated by the creator of the subnet and may include a reputable individual or network address that is recognized by consensus within the network. In some embodiments, validators 304 back up their validation credentials by solving complex mathematical puzzles, e.g., in proof-of-work (PoW) validation.

[0042] In some embodiments, each of the subnets 302 may be managed by a platform blockchain (P-Chain) 310. For example, the P-Chain 310 may track balances / transactions 312 across each of the subnets 302. The P-Chain 310 may also include core functionality, including, but not limited to, a staking module 314 and / or a rewards module 316. For example, the rewards module 316 may provide rewards based on uptime management to incentivize users to validate the subnet. In one implementation, the P-Chain 310 may be the administrator of the validators for the subnet.

[0043] In some embodiments, each subnet 302 may utilize a native token 308 to pay for transactions across the subnets 302. For example, a first subnet 302-1 may utilize a first virtual token, a second subnet 302-2 may utilize a second virtual token, a third subnet 302-3 may utilize a third virtual token, and a fourth subnet 302-4 may utilize a fourth virtual token. Each of the virtual tokens may be different from one another or may be the same. In one implementation, the first virtual token may include the platform's native token (e.g., a cryptocurrency). In one implementation, transferring / trading tokens between / across subnets may be managed by the P-Chain 310.

[0044] Some of the subnets 302 may be high-performance zones. For example, a user may target performance goals without targeting the stability of the larger, customized network 300. The customized network 300 allows for trade-offs between fault tolerance, performance, and other attributes of the subnets 302. In some embodiments, the P-chain 310 may implement a "sharding" process. Sharding is the process of functionally dividing separate activities or subnets and allowing them to proceed in parallel. This allows different rules to apply to different transactions.

[0045] In one implementation, one validator 304 may participate in multiple subnets. For example, validator 304 participates in at least one of subnets 302 in addition to primary network 302-1 ("subnet 0"). Alternatively, validators 304C and 304D belong to subnets 302-2 and 302-3. In this way, users may enhance the functionality / guarantees provided by subnets that would otherwise be more burdensome to the rest of the network. Additionally, subnets 302 may interoperate with other subnets 302.

[0046] In some embodiments, a shared memory module 352 may be utilized for data transfer across subnets 302. Entries in the shared memory module 352 may be populated through the P-chain 310. For example, the shared memory module 352 may reuse baked-in logic to accomplish this. In some embodiments, transactions may be injected into the shared memory module 352, and aggregated signatures are published for consensus verification. According to aspects, one or more subnets 302 may generate native tokens 308 that are stored in the asset pool 306. Thus, transactions across subnets 302 may involve the exchange and conversion of native tokens 308 (e.g., “underlying assets”) across subnets 302.

[0047] In some embodiments, a single replicated state machine (e.g., a P-chain 310 replicated by the entire network) may be created as the source of truth (e.g., controller) for validators 304. In some embodiments, a single replicated state machine may be created as the source of truth for validators and their rewards. In some embodiments, a single replicated state machine may be created as the source of truth for cross-subnet interactions between one or more subnets 302. In one aspect, the replicated state may not include the state of individual subnets 302. In some embodiments, a single replicated state machine may act as a global source of truth for metadata across subnets 302.

[0048] In some embodiments, users of primary network 302-1 can create subnets 302. This may result in the bonding (or burning) of underlying assets 308 (e.g., cryptocurrencies and other native tokens). The cost of running a subnet 302 may be tied to the number of transactions made and the number of validators 304 on each subnet 302. In some embodiments, validators 304 may be designated for a subnet 302 on a single replicated state machine.

[0049] In some embodiments, the state of a subnet 302 may not conform to a pre-specified format, and the logic implemented on each subnet 302 may be kept private. This creates a heterogeneous network of state managers for subnets 302. Participants in different subnets 302 may be required to have additional requirements beyond the basic requirements of primary network 302-1. Thus, subnets 302 may specify their own logic, including fee structures. In some embodiments, fees may be paid in native token 308 via PoW, PoS, and / or any other programmable fee implementation. Some transactions may be free.

[0050] In some embodiments, subnet 302 utilizes an existing consensus engine of one or more blockchains that subnet 302 is validating, provided, for example, via a software development kit (SDK) / plug-in interface. In some implementations, subnet 302 may additionally define a network protocol. For example, subnet 302 may implement a DHT, utilizing membership knowledge instead of or in addition to consensus.

[0051] In some embodiments, the subnets 302 may include at least one of a private subnet, a proof-of-authority subnet, a permissionless subnet, or a non-consensus subnet. The blockchain 300 supports cross-subnet operations such as the transfer of basic assets 308, general subnet rewards, or hashtag distribution. In some embodiments, a cross-subnet transfer includes an export operation on the source subnet 302 that places the digital asset 308 into the shared memory module 352. An import operation on the destination subnet 302 checks and moves the digital asset 308 from the shared memory module 352 to a particular blockchain. In some embodiments, at least one of the subnets 302 may be interoperable with one or more other subnets 302.

[0052] 4 illustrates a system 400 configured to create a heterogeneous network of blockchains coupled via a network 450, according to one or more implementations. In some implementations, the system 400 may include one or more computing platforms 402. The computing platforms 402 may be configured to communicate with one or more remote platforms 404 according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. The remote platforms 404 may be configured to communicate via the computing platforms 402 and / or with other remote platforms according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. A user may access the system 400 via the remote platforms 404.

[0053] The computing platform 402 may be configured with machine-readable instructions 406. The machine-readable instructions 406 may include one or more instruction modules, which may include computer program modules, including one or more of a generation module 408, a designation module 410, an initiation module 412, a customization module 414, a determination module 416, a fee / reward module 418, a verification module 420, and / or a signature module 422, and / or other instruction modules.

[0054] The creation module 408 can be configured to create a platform blockchain that includes a single replicated state machine. The creation module 408 can also be configured to create at least one subnet based in part on the platform blockchain. For example, the subnet can include at least one blockchain. The creation module 408 can also cause the merging or burning of underlying assets of the platform blockchain.

[0055] The designation module 410 can be configured to designate a validator for at least one subnet. In some embodiments, the system 400 can include a source of truth for transactions across subnets (e.g., main subnet 302-1).

[0056] The initiation module 412 can be configured to initiate at least one transaction from at least one subnet of the platform blockchain to another subnet.

[0057] The customization module 414 can be configured to customize a subnet by the creator of the subnet by specifying a virtual machine that implements the cloned state machine of the subnet.

[0058] The determination module 416 may be configured to determine a fee structure for the subnet and implement the fee structure by the creator of the subnet. According to an embodiment, the virtual machine implements a fee structure for its own application-specific purposes.

[0059] The fees / rewards module 418 can be configured to reward participants based on an implementation of a fee structure defined by the creator of the subnet. The rewards module 418 may include a fee structure to discourage participants from creating copies of the main network code and starting communication through cumbersome bridges. Rather, participants would be incentivized to create their own subnets instead. In some embodiments, the fees / rewards module 418 allows validators to discover the profitability of validating a subnet. This results in a significantly better validator experience for choosing which subnets to validate. The fees / rewards module 418 may include a fee structure to combine / select from the following schemes: 1) introducing fee-free transactions that may utilize proof-of-work (PoW); 2) periodically charging for running the subnet paid in the subnet's native token; or 3) taxing the subnet in native token (e.g., cryptocurrency) per invocation of platform functions such as staking reward determination, e.g., preferred consensus on the platform chain. In one implementation, taxation is performed by paying for each unique transaction on the P-chain. Fees collected from any of the above processes could potentially be redistributed to other subnets on the platform (e.g., the primary network).

[0060] In some embodiments, the fees / rewards module 418 may tax the use of key platform features. For example, the platform may include sophisticated mechanisms for rewarding users based on uptime. In one implementation, rewards may occur outside of the VM on the primary blockchain network. Because there is overhead for the P-chain to reward validators based on sub-validation periods, all awarded validators may be forced onto the P-chain, and the subnet may pay more native tokens to achieve this. In some embodiments, the subnet interfaces with the fees / rewards module 418 to reward users.

[0061] The validation module 420 makes validator lists (e.g., network addresses) public, allowing other subnets to learn about validators in other subnets, which allows other subnets to validate cross-subnet transactions.

[0062] The signing module 422 generates keys for validating transactions across multiple parties in a heterogeneous blockchain network (e.g., subnets, miners, users, contributors, validators, etc.) as disclosed herein. Accordingly, the signing module 422 provides the generated keys to selected parties for authorization and validation of transactions (e.g., smart contracts, asset transfers, cross-subnet transactions, block appends, etc.). In some embodiments, the signing module 422 provides a threshold signature scheme (TSS) for key generation and distribution of signatures to selected parties. In a TSS, verification proceeds to approve the transaction once a predetermined threshold of selected parties have signed. The TSS disclosed herein avoids a single point of failure in the blockchain network disclosed herein. A TSS may include, but is not limited to, a multi-signature scheme, a threshold signature scheme, or other cryptographic proof of participation.

[0063] In some implementations, the computing platform 402, the remote platform 404, and / or the external resources 424 may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via a network, such as the Internet and / or other networks. This is not intended to be limiting, and it will be understood that the scope of the present disclosure includes implementations in which the computing platform 402, the remote platform 404, and / or the external resources 424 may be operatively linked via some other communication medium.

[0064] A given remote platform 404 includes one or more processors configured to execute computer program modules that can be configured to enable a professional or user associated with the given remote platform 404 to interface with the system 400 and / or external resources 424 and / or to provide the remote platform 404 with other functionality attributed herein. By way of non-limiting example, a given remote platform 404 and / or a given computing platform 402 may include one or more of a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms.

[0065] External resources 424 include information sources external to system 400, external entities participating in system 400, and / or other resources. In some implementations, some or all of the functionality attributed to external resources 424 herein may be provided by resources included in system 400.

[0066] Computing platform 402 includes electronic storage 426, one or more processors 428, and / or other components. Computing platform 402 includes communication lines or ports that enable the exchange of information with a network and / or other computing platforms. The illustration of computing platform 402 is not intended to be limiting. Computing platform 402 includes multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to computing platform 402 herein. For example, computing platform 402 may be implemented by a cloud of computing platforms that work together as computing platform 402.

[0067] Electronic storage 426 may include non-transitory storage media that electronically store information. The electronic storage media of electronic storage 426 may include one or both of system storage provided integrally (i.e., substantially non-removably) with computing platform 402 and / or removable storage that is removably connectable to computing platform 402, for example, via a port (e.g., a USB port, a Firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 426 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. Electronic storage 426 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage 426 may store software algorithms, information determined by processor 428, information received from computing platform 402, information received from remote platform 404, and / or other information that enables computing platform 402 to function as described herein.

[0068] The processor 428 can be configured to provide information processing capabilities in the computing platform 402. As such, the processor 428 includes one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. While the processor 428 is shown as a single entity, this is for illustrative purposes only. In some implementations, the processor 428 includes multiple processing units. These processing units can be physically located within the same device, or the processor 428 can represent the processing functions of multiple devices acting in concert. The processor 428 can be configured to execute modules 408, 410, 412, 414, 416, 418, 420, and / or 422 and / or other modules. Processor 428 may be configured to execute modules 408, 410, 412, 414, 416, 418, 420, and / or 422 and / or other modules by software; hardware; firmware; some combination of software, hardware, and / or firmware; and / or other mechanisms for configuring processing power on processor 428. As used herein, the term "module" may refer to any component or set of components that perform the functionality attributed to a module. This includes one or more physical processors in execution of processor-readable instructions, processor-readable instructions, circuitry, hardware, storage media, or any other component.

[0069] Although modules 408, 410, 412, 414, 416, 418, 420, and / or 422 are illustrated as being implemented within a single processing unit, it should be understood that in implementations in which processor 428 includes multiple processing units, one or more of modules 408, 410, 412, 414, 416, 418, 420, and / or 422 may be implemented remotely from the other modules. The descriptions of functionality provided by different modules 408, 410, 412, 414, 416, 418, 420, and / or 422 described below are for purposes of illustration and are not intended to be limiting, as any of modules 408, 410, 412, 414, 416, 418, 420, and / or 422 may provide more or less functionality than described. For example, one or more of modules 408, 410, 412, 414, 416, 418, 420, and / or 422 may be eliminated, and some or all of its functionality may be provided by other of modules 408, 410, 412, 414, 416, 418, 420, and / or 422. As another example, processor 428 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed to one of modules 408, 410, 412, 414, 416, 418, 420, and / or 422, including:

[0070] The techniques described herein may be implemented as methods performed by a physical computing device, as one or more non-transitory computer-readable storage media that store instructions that, when executed by a computing device, cause the method to be performed, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0071] 5A and 5B illustrate a proof-of-work (PoW) 505A process and a proof-of-stake (PoS) 505B process (collectively referred to herein as "process 505") for validating block 510b in a blockchain 500 that is part of a customized blockchain network, according to some embodiments. Process 505 is issued by a validation module 520. Blockchain 500 includes a previous block 510a and multiple contributors 501a, 501b, 501c, and 501d (collectively referred to herein as "miners 501") who wish to add block 510b and submit bids. Block 510b may include the most recent batch of data or transactions in blockchain 500. The system includes a validation module 520 for overseeing and validating the bids of miners 501.

[0072] In some embodiments, the blockchain network includes a competitive validation method for verifying transactions and adding a new block 510b to the blockchain 500. Accordingly, the validation module 520 issues a PoW 505A challenge to the miner 501. The PoW 505A may include a complex mathematical puzzle for the miner 501 to solve within a specific timeline 540 (see nonce 108). The winner of this race (e.g., miner 501b) is selected to add block 510b to the blockchain 500.

[0073] In some embodiments, a reward may be issued to miner 501b for adding block 510b to blockchain 500. The reward may include a monetary fee or other incentive that may be spent either internally or externally to blockchain 500. PoW 505A maintains fairness in reward distribution and ensures the integrity of blockchain 500. Although a PoW mechanism is described, some embodiments may include other decentralized consensus protocols for authorizing contributors and assigning validators.

[0074] FIG. 5B includes a PoS process 505B for approving validator 511b from among validators 511a, 511b, and 511c (collectively referred to herein as "validators 511"). There are multiple ways for validation module 520 to specify which validator 511 may be selected. POS 505B includes validating assets or tokens for each of validators 511. This may include reviewing the native token asset pool for the subnet associated with validator 511 (e.g., asset pool 306 and native token 308 in subnet 302). In some embodiments, process 505B may include a Proof of Authority (PoA), in which validation module 520 verifies the authority specified by the creator of the subnet.

[0075] In some embodiments, the Proof-of-Stake (PoS) process 505B utilizes randomly selected miners to validate transactions. In some embodiments, the PoS process 505B may include a set of nodes (e.g., stakers) that have decided to stake their own cryptocurrency (e.g., virtual currency / currency) for transaction validation. The larger the stake amount and the longer the duration of the stake, the more likely the staker will receive responsibility for validating the transaction from the validation module 520.

[0076] As a safeguard against fraud, in some embodiments, PoS process 505B requires traders to "stake" cryptocurrency value 508 (e.g., assets) as collateral, which is then locked in memory 552 (see shared memory module 352). When block 510b approved by validator 511b is deemed invalid by other validators (e.g., 511a and 511c), validator 511b may lose a portion of value 508.

[0077] Some embodiments may include a floor limit on how much a validator 511 can stake in value 508. After exceeding this floor, a validator 511 can stake as much as they wish. In some embodiments, the validation module 520 is more likely to select a validator 511b with a higher value 508. For example, if 10 validators bid to validate a blockchain transaction with an equal stake, all other considerations being equal, each validator has an equal 10% chance of being selected by the validation module 520.

[0078] 6 illustrates a threshold signature scheme (TSS) performed by signing module 622 to generate digital signatures 650 for transactions from multiple participants 611a, 611b, and 611c (hereinafter collectively referred to as “participants 611”) in blockchain 600, according to some embodiments. In some embodiments, the transaction may include the addition of block 610b in blockchain 600 from contributor 601. Participant 611 may be a validator (see validator 304), a miner, or a contributor to blockchain 600.

[0079] The signing module 622 provides a portion of the key 605B to each of the participants 611. Once a preselected threshold number of participants (e.g., two out of three) return their signed portions, the signing module 622 completes the signing 650. The transaction (e.g., adding a new block 610b to an existing block 610a in the blockchain 600, approving a smart contract, etc.) is completed, and the blockchain 600 is updated accordingly.

[0080] More generally, a transaction may include any transfer of assets across different subnets in a blockchain infrastructure as disclosed herein (see subnet 302). Specifically, signing module 622 may post a threshold-signed transaction to a single shared state, the results of which may be consumed by one or more blockchains on the network via access to signature 650 from memory 652 (see shared memory module 352).

[0081] FIG. 7 illustrates an example flow diagram (e.g., process 700) for generating a blockchain network according to certain aspects of the present disclosure. For purposes of explanation, the example process 700 is described herein with reference to FIGS. 1-4. For example, at least one or more steps of method 700 may be performed by a computer platform including electronic storage and one or more processors, where the one or more processors execute machine-readable instructions and are communicatively coupled to a remote platform and external resources via a network (see computing platform 402, processor 428, machine-readable instructions 406, remote platform 404, external resources 424, and network 450). Additionally, the machine-readable instructions may be part of a generation module, a designation module, an initiation module, a customization module, a determination module, a fee / reward module, a verification module, and a signature module, as disclosed herein (see generation module 408, designation module 410, initiation module 412, customization module 414, determination module 416, fee / reward module 418, verification module 420, and signature module 422). Additionally, for purposes of explanation, the steps of exemplary process 700 are described herein as occurring sequentially or linearly. However, multiple instances of exemplary process 700 may occur in parallel. Furthermore, in embodiments consistent with the present disclosure, at least one or more steps of method 700 may be performed in a different order, simultaneously, quasi-simultaneously, or overlapping in time.

[0082] A platform blockchain including a single replicated state machine is generated in step 702. In some embodiments, step 702 includes generating a platform blockchain (e.g., PChain 410) including a single replicated state machine.

[0083] In step 704, at least one subnet is generated (e.g., via generation module 408) based in part on the platform blockchain. For example, the subnet includes at least one blockchain, or a base blockchain. In some embodiments, step 704 may also include merging or burning base assets of the platform blockchain. In some embodiments, step 704 includes generating at least one subnet (e.g., subnet 302) based in part on the platform blockchain. For example, the subnet may include at least one blockchain (e.g., blockchain 200). In some embodiments, step 704 further includes customizing the subnet by the creator of the subnet by specifying a virtual machine that implements the subnet's replicated state machine. In some embodiments, the subnet includes at least one of a private subnet, a proof-of-authority subnet, a permissionless subnet, or a non-consensus subnet, and step 704 may include conducting cross-subnet transfers, conducting a general subnet reward, or distributing hashtags among the subnets.

[0084] In step 706, validators are designated for at least one subnet. According to aspects, the platform blockchain comprises the source of truth for transactions across subnets. In some embodiments, step 706 includes minting virtual currency with the validators. In some embodiments, step 706 includes offering the virtual currency as PoW or PoS to qualify as a validator for blockchain transactions. In some embodiments, step 706 includes designating validators (e.g., validators 304A, 304B, 304C, 304D, 304E, 304F) ...

[0085] Step 708 includes initiating at least one transaction from at least one subnet of the platform blockchain to another subnet. The platform blockchain includes a source of truth for transactions across subnets. In some embodiments, step 708 further includes initiating at least one transaction from at least one subnet of the platform blockchain to another subnet. In some embodiments, step 708 further includes determining a fee structure for the subnet and implementing the fee structure by the creator of the subnet. For example, participants may be rewarded based on an implementation of the fee structure defined by the creator of the subnet. According to an aspect, the virtual machine implements a fee structure for its own application-specific purposes.

[0086] In some embodiments, step 708 includes performing a cross-subnet transfer via inter-subnet communication. In some embodiments, step 708 includes exporting the digital asset from the source subnet to a database and importing the digital asset from the database to a destination subnet, where the digital asset is checked and placed into a particular blockchain.

[0087] FIG. 8 illustrates an example flow diagram (e.g., process 800) for managing a blockchain network in accordance with certain aspects of the present disclosure. For purposes of explanation, example process 800 is described herein with reference to FIGS. 1-4. For example, at least one or more steps of method 800 may be performed by a computer platform including electronic storage and one or more processors, where the one or more processors execute machine-readable instructions and are communicatively coupled to a remote platform and external resources via a network (see computing platform 402, processor 428, machine-readable instructions 406, remote platform 404, external resources 424, and network 450). Additionally, the machine-readable instructions may be part of a creation module, a designation module, an initiation module, a customization module, a determination module, a fee / reward module, a verification module, and a signature module, as disclosed herein (see creation module 408, designation module 410, initiation module 412, customization module 414, determination module 416, fee / reward module 418, verification module 420, and signature module 422). Additionally, for purposes of explanation, the steps of the exemplary process 800 are described herein as occurring sequentially or linearly. However, multiple instances of the exemplary process 800 may occur in parallel. Furthermore, in embodiments consistent with the present disclosure, at least one or more steps of the method 800 may be performed in a different order, simultaneously, quasi-simultaneously, or overlapping in time.

[0088] Step 802 includes receiving a hashed block of data from a first network node for addition to a first blockchain in the network.

[0089] Step 804 involves requesting one or more validators in the network to validate the hashed data block.

[0090] Step 806 includes receiving validation credentials from each of the one or more validators.

[0091] Step 808 includes selecting a first validator based on the validation credentials. In some embodiments, step 808 includes providing a first version of a first key to the first validator. The first key may define access controls for viewing and / or accessing the subnet or the first blockchain (thus keeping the blockchain state private), for example. The first key may be an encrypted key. In some embodiments, step 808 includes providing an encrypted identifier to each of the one or more validators, the validation credentials indicating that the first validator resolved the encrypted identifier within a predetermined period of time. In some embodiments, the validation credentials are assets from each of the one or more validators, and step 808 includes identifying a highest value asset from the one or more validators. In some embodiments, the validation credentials are authorities selected by each of the one or more validators, and selecting the first validator includes identifying an authority with the highest consensus authorization from the one or more validators.

[0092] Step 810 includes generating a hash of the first blockchain and the hashed data block using a first key when the first validator verifies the hashed data block. In some embodiments, step 810 includes rejecting the hashed data block when the first validator invalidates the hashed data block. In some embodiments, step 810 includes rewarding the first validator with blockchain assets when the first blockchain is consensus-basedly approved by one or more validators. In some embodiments, step 810 includes taxing the first validator with blockchain assets when the first blockchain is rejected by a preselected threshold number of one or more validators.

[0093] Step 812 includes providing a first key to a first network subscriber to access the first blockchain. In some embodiments, step 812 includes providing different portions of the encrypted signature to each of one or more validators to approve the blockchain transaction, and approving the blockchain transaction when a threshold number of the one or more validators sign different portions of the encrypted signature. In some embodiments, step 812 further includes receiving a hashed data block from a second network node for adding to a second blockchain in the network, generating a hash of the second blockchain and the hashed data block using the second key when the second validator verifies the hashed data block, providing the second key to the second network subscriber to access the second blockchain, and preventing the first network subscriber from accessing the second blockchain. In some embodiments, the second key defines access control, for example, for viewing and / or accessing the second blockchain. The second key may be an encrypted key, and in some embodiments, step 812 further includes receiving a request from the second network node for a transaction with the first network node, approving the transaction when the second validator validates the transaction, and adding a hashed block containing the transaction to the first blockchain.

[0094] Hardware Overview 9 is a block diagram illustrating an example computer system 900 in which aspects of the subject technology may be implemented. In certain aspects, computer system 900 may be implemented using hardware or a combination of software and hardware, whether in a dedicated server, integrated in another entity, or distributed across multiple entities.

[0095] Computer system 900 (e.g., server and / or client) includes a bus 908 or other communication mechanism for communicating information and a processor 902 coupled with bus 908 for processing information. By way of example, computer system 900 may be implemented with one or more processors 902. Processor 902 may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, a discrete hardware component, or any other suitable entity capable of performing computations or other manipulations of information.

[0096] Computer system 900 may include, in addition to hardware, code that creates an execution environment for computer programs in question, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these, stored in included memory 904, such as random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device coupled to bus 908 for storing information and instructions executed by processor 902. Processor 902 and memory 904 may be supplemented by, or incorporated in, special purpose logic circuitry.

[0097] The instructions may be stored in memory 904 and implemented in one or more computer program products, i.e., encoded on a computer-readable medium for execution by computer system 900, or in one or more modules of computer program instructions encoded on a computer-readable medium for controlling the operation of computer system 900, according to any method known to those skilled in the art, including, but not limited to, computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). The instructions may also be implemented in a computer language such as an array language, an aspect-oriented language, an assembly language, an authoring language, a command line interface language, a compiled language, a concurrent language, a curly brace language, a data flow language, a data structure language, a declarative language, an esoteric language, an extension language, a fourth generation language, a functional language, an interactive mode language, an interpreted language, an iterative language, a list-based language, a little language, a logic-based language, a machine language, a macro language, a metaprogramming language, a multi-paradigm language, numerical analysis, a non-English-based language, an object-oriented class-based language, an object-oriented prototype-based language, an offside rules language, a procedural language, a reflective language, a rule-based language, a scripting language, a stack-based language, a synchronization language, a syntax processing language, a visual language, a worth language, and an xml-based language. The memory 904 may also be used for storing temporary variables or other intermediate information during execution of instructions by the processor 902.

[0098] A computer program as discussed herein does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network. The processes and logic flows described herein can be implemented by one or more programmable processors executing one or more computer programs to perform functions by manipulating input data and generating output.

[0099] Computer system 900 further includes a data storage device 906, such as a magnetic or optical disk, coupled to bus 908 for storing information and instructions. Computer system 900 may be coupled to various devices via input / output module 910. Input / output module 910 may be any input / output module. An exemplary input / output module 910 includes a data port, such as a USB port. Input / output module 910 is configured to connect to a communications module 912. An exemplary communications module 912 includes a networking interface card, such as an Ethernet card and a modem. In certain aspects, input / output module 910 is configured to connect to multiple devices, such as input devices 914 and / or output devices 916. Exemplary input devices 914 include a keyboard and a pointing device, such as a mouse or trackball, by which a user can provide input to computer system 900. Other types of input devices 914, such as a tactile input device, a visual input device, an audio input device, or a brain-computer interface device, may also be used to provide interaction with a user. For example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, speech, tactile, or electroencephalographic input. Exemplary output devices 916 include display devices, such as LCD (liquid crystal display) monitors, for displaying information to the user.

[0100] According to one aspect of the present disclosure, the gaming system described above can be implemented using computer system 900 in response to processor 902 executing one or more sequences of one or more instructions contained in memory 904. Such instructions may be read into memory 904 from another machine-readable medium, such as data storage device 906. Execution of the sequences of instructions contained in main memory 904 causes processor 902 to perform the process steps described herein. One or more processors in a multi-processing configuration may also be employed to execute the sequences of instructions contained in memory 904. In alternative aspects, hard-wired circuitry may be used in place of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuitry and software.

[0101] Various aspects of the subject matter described herein may be implemented in a computing system that includes a back-end component, such as a data server, a middleware component, such as an application server, or a front-end component, such as a client computer having a graphical user interface or a web browser, through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communications network. The communications network may include, for example, any one or more of a LAN, a WAN, the Internet, etc. Furthermore, the communications network may include, for example, any one or more of the following network topologies, including, but not limited to, a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, etc. The communications module may be, for example, a modem or an Ethernet card.

[0102] Computer system 900 may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Computer system 900 may be, for example, without limitation, a desktop computer, a laptop computer, or a tablet computer. Computer system 900 may also be embedded in another device, for example, without limitation, a mobile phone, a PDA, a mobile audio player, a global positioning system (GPS) receiver, a video game console, and / or a television set-top box.

[0103] The terms "machine-readable storage medium" or "computer-readable medium," as used herein, refer to any medium or media that participate in providing instructions to processor 902 for execution. Such media may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as data storage device(s) 906. Volatile media include dynamic memory, such as memory 904. Transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 908. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tape, any other physical media with a pattern of holes, RAM, PROM, EPROM, FLASH EPROM, any other memory chip or cartridge, or any other medium from which a computer can read. The machine-readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that affects a machine-readable propagated signal, or a combination of one or more of these.

[0104] When the user computing system 900 reads data, the information may be read from the data source and stored in a memory device, such as memory 904. Additionally, data may be read from a memory 904 server accessed via a network, bus 908, or data storage 906 and loaded into memory 904. While the data is described as being found in memory 904, it will be understood that the data need not be stored in memory 904, but may be stored in other memory accessible to the processor 902, or may be distributed among several media, such as data storage 906.

[0105] As used herein, the phrase "at least one of" preceding a list of items with the term "and" or "or" separating any of the items modifies the list as a whole, not each member (i.e., each item) of the list. The phrase "at least one of" does not require the selection of at least one item; rather, the phrase allows for the meaning to include at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. By way of example, the phrase "at least one of A, B, and C" or "at least one of A, B, or C" refers to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0106] To the extent that terms like "include," "have," and the like are used in the description or claims, such terms are intended to be inclusive in the same manner as the word "comprise" is interpreted as "comprise" when employed as a transitional term in a claim. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0107] Reference to an element in the singular is not intended to mean "one and only one," but rather "one or more," unless specifically stated otherwise. All structural and functional equivalents to the elements of the various configurations described throughout this disclosure that are known, or that later become known, to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be dedicated to the public, regardless of whether such disclosure is expressly set forth in the description above.

[0108] While this specification contains many details, these should not be construed as limitations on the scope that may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination and initially claimed as such, in some cases one or more features from a claimed combination may be deleted from the combination, rendering the claimed combination the subject of a subcombination or a variation of the subcombination.

[0109] Although the subject matter herein has been described in terms of particular aspects, other aspects may be implemented and are within the scope of the following claims. For example, while operations are depicted in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order or sequence shown, or that all illustrated operations must be performed to achieve desirable results. Acts recited in the claims may be performed in a different order and still achieve desirable results. As an example, the processes depicted in the accompanying figures do not necessarily require the particular order or sequence shown to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described aspects should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems may generally be integrated in a single software product or packaged in multiple software products. Other variations are within the scope of the following claims.

Claims

1. 1. A computer-implemented method for generating a heterogeneous network of blockchains, comprising: generating a platform blockchain including the replicated state machine; generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating causing a merging or burning of underlying assets of the platform blockchain; and designating a validator for the at least one subnet, wherein the platform blockchain includes a source of truth for transactions across the subnet.

2. The computer-implemented method of claim 1 , further comprising customizing the subnet by a creator of the subnet by specifying a virtual machine that implements the replicated state machine for the subnet.

3. The computer-implemented method of claim 1 , wherein the subnet comprises at least one of a private subnet, a proof-of-authority subnet, a permissionless subnet, or a non-consensus subnet.

4. 10. The computer-implemented method of claim 1, further comprising initiating at least one transaction from the at least one subnet of the platform blockchain to another subnet.

5. The computer-implemented method of claim 1 , wherein the validator comprises a proof-of-stake validator that includes an asset named by a creator of the subnet.

6. The computer-implemented method of claim 1 , wherein the validator comprises a proof-of-authority validator, and authority is designated by a creator of the subnet.

7. The computer-implemented method of claim 1 , wherein the subnet is configured to provide rewards to users.

8. 10. The computer-implemented method of claim 1, wherein the validators of the subnet mint virtual currency via proof-of-work.

9. determining a fee structure for the subnet; The computer-implemented method of claim 2 , further comprising: implementing the fee structure by a creator of the subnet.

10. 2. The computer-implemented method of claim 1, wherein inter-subnet communication is utilized to perform cross-subnet transfers, the cross-subnet transfers including an export operation on a source subnet that places one or more digital assets into a database, and an import operation on a destination subnet that checks and moves the one or more digital assets from the database to a particular blockchain.

11. 1. A system for generating a heterogeneous network of blockchains, comprising: a processor; a memory storing instructions that, when executed by the processor, cause the processor to: generating a platform blockchain including the replicated state machine; generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating causing a merging or burning of underlying assets of the platform blockchain; and designating a validator for the at least one subnet, wherein the platform blockchain includes a source of truth for transactions across the subnet.

12. and a stored sequence of instructions that, when executed by the processor, cause the processor to:

12. The system of claim 11, wherein the system allows customization of the subnet by the creator of the subnet by specifying a virtual machine that implements the replicated state machine for the subnet.

13. 12. The system of claim 11, wherein the subnet comprises at least one of a private subnet, a proof-of-authority subnet, a permissionless subnet, or a non-consensus subnet.

14. and a stored sequence of instructions that, when executed by the processor, cause the processor to:

12. The system of claim 11, further comprising: initiating at least one transaction from the at least one subnet of the platform blockchain to another subnet.

15. 12. The system of claim 11, wherein the validators include proof-of-stake validators that include assets named by a creator of the subnet.

16. 12. The system of claim 11, wherein the validator comprises a proof-of-authority validator, and authority is designated by a creator of the subnet.

17. The system of claim 11 , wherein the subnet is configured to provide rewards to users.

18. 12. The system of claim 11, wherein the validators of the subnet mint virtual currency via proof-of-work.

19. and a stored sequence of instructions that, when executed by the processor, cause the processor to: determining a fee structure for the subnet; and implementing the fee structure by a creator of the subnet.

20. 1. A non-transitory computer-readable storage medium comprising stored instructions that, when executed by one or more processors, cause the one or more processors to perform a method for generating a heterogeneous network of blockchains, the method comprising: generating a platform blockchain that includes a single replicated state machine; generating at least one subnet based in part on the platform blockchain, the subnet including at least one blockchain, and the generating causing a merging or burning of underlying assets of the platform blockchain; and designating a validator for the at least one subnet, wherein the platform blockchain includes a source of truth for transactions across the subnet.

Images