WO2023207076A1 - Method and apparatus for establishing blockchain subnet - Google Patents

Abstract

One or more embodiments of the present description provide a method and apparatus for establishing a blockchain subnet. The method may comprise: blockchain nodes in a blockchain main net respectively obtain a transaction for establishing a blockchain subnet, the transaction comprising configuration information of the blockchain subnet, and the configuration information comprising identity information of node members participating in establishment of the blockchain subnet; the blockchain nodes in the blockchain main net respectively execute the transaction; and when the configuration information comprises identity information of a node member corresponding to a first blockchain node, a node device deploying the first blockchain node generates, on the basis of the transaction, a genesis block comprising the configuration information and starts, on the basis of the genesis block, a second blockchain node belonging to the blockchain subnet.

Description

Establishment method and installation of blockchain subnet Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method and device for establishing a blockchain subnet.

Background technique

Blockchain technology is built on a transmission network (such as a peer-to-peer network). Network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. All nodes in the same blockchain network are in a peer position and have completely consistent block data. However, node members corresponding to some nodes in multiple blockchain networks sometimes need to implement small-scale transactions to prevent other node members from obtaining these transactions and related data.

Contents of the invention

In view of this, one or more embodiments of this specification provide a method and device for establishing a blockchain subnet.

To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions.

According to the first aspect of one or more embodiments of this specification, a method for establishing a blockchain subnet is proposed, including: multiple main network nodes respectively obtain transactions for establishing a blockchain subnet, and the transaction includes the block chain subnet. Configuration information of the blockchain subnet, the configuration information includes the identity information of the node members participating in the establishment of the blockchain subnet, and the multiple main network nodes belong to at least two blockchain main networks; the multiple main network nodes The network nodes respectively execute the transaction to reveal the configuration information; the node devices deployed with the main network nodes execute respectively: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by itself. , load the genesis block generated based on the configuration information to start the subnet nodes belonging to the blockchain subnet.

According to the second aspect of one or more embodiments of this specification, another method for establishing a blockchain subnet is proposed, including: multiple node devices respectively obtain configuration information of the blockchain subnet, among the multiple node devices Deploying main network nodes belonging to at least two blockchain main networks, the configuration information includes identity information of node members participating in establishing the blockchain subnet; the multiple node devices respectively execute: when the configuration information includes itself In the case of identity information of node members corresponding to the deployed main network nodes, load the genesis block generated based on the configuration information to start the subnet nodes belonging to the blockchain subnet.

According to the third aspect of one or more embodiments of this specification, a device for building a blockchain subnet is proposed, including: a transaction acquisition unit for multiple main network nodes to respectively acquire transactions for building a blockchain subnet, so The transaction includes the configuration information of the blockchain subnet, the configuration information includes the identity information of the node members participating in the establishment of the blockchain subnet, and the multiple main network nodes belong to at least two blockchain main networks. ; Transaction execution unit, used for the plurality of main network nodes to execute the transaction respectively to reveal the configuration information; Node startup unit, used for node equipment deployed with the main network node to respectively execute: in the configuration If the information includes the identity information of the node members corresponding to the main network nodes deployed by itself, load the genesis block generated based on the configuration information to start the subnet nodes belonging to the blockchain subnet.

According to the fourth aspect of one or more embodiments of this specification, another device for building a blockchain subnet is proposed, including: an information acquisition unit for multiple node devices to respectively acquire the configuration information of the blockchain subnet, so The main network nodes deployed in the plurality of node devices belong to at least two blockchain main networks, and the configuration information includes the identity information of the node members participating in forming the blockchain subnet; a node startup unit is used for the multiple The node device performs respectively: when the configuration information includes the identity information of the node member corresponding to the main network node deployed by itself, load the genesis block generated based on the configuration information to start the subnet belonging to the blockchain subnet. network node.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions by the processor; wherein the processor executes the executable instructions To implement the method described in any one of the first aspects.

According to the sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is proposed, on which computer instructions are stored. When the instructions are executed by a processor, the method as described in any one of the first aspects is implemented. A step of.

Through the above embodiments, for multiple blockchain mainnets, at least one mainnet node in each blockchain mainnet can jointly form a blockchain subnet with at least one mainnet node in other blockchain mainnets. , that is, building a cross-mainnet blockchain subnet based on the multiple blockchain mainnets. Since this blockchain subnet is independent of each of the above-mentioned blockchain mainnets, transactions and related data conducted in this subnet will not be obtained by other node members in the above-mentioned mainnets. It can be seen that based on the newly established blockchain subnet, it can meet the needs of small-scale transactions between various node members participating in the formation of the subnet.

Description of the drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative efforts.

Figure 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

Figure 2 is a schematic diagram of calling a smart contract provided by an exemplary embodiment.

Figure 3 is a schematic diagram of creating and calling a smart contract provided by an exemplary embodiment.

Figure 4 is a flow chart of a method for establishing a blockchain subnet provided by an exemplary embodiment.

Figure 5 is a schematic diagram of establishing a blockchain subnet based on multiple blockchain mainnets according to an exemplary embodiment.

Figure 6 is a flow chart of another method of establishing a blockchain subnet provided by an exemplary embodiment.

Figure 7 is a schematic structural diagram of a device provided by an exemplary embodiment.

Figure 8 is a block diagram of a device for building a blockchain subnet provided in an exemplary embodiment.

Figure 9 is a block diagram of another device for building a blockchain subnet provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, methods may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. On the contrary, the private chain has the writing permission of the network controlled by an organization or institution, and the data reading permission is regulated by the organization. Simply put, a private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use within specific organizations. The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Whether it is a public chain, a private chain or a consortium chain, it may provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and each Ethereum node can run the EVM. EVM is a Turing-complete virtual machine, which means that various complex logic can be implemented through it. When users publish and call smart contracts in Ethereum, they run on the EVM. In fact, the virtual machine directly runs the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

For example, as shown in Figure 1, after Bob sends a transaction containing smart contract creation information to the Ethereum network, the EVM of node 1 can execute the transaction and generate the corresponding contract instance. "0x6f8ae93..." in Figure 1 represents the address of this contract. The data field of the transaction can store bytecode, and the to field of the transaction is empty (null). After the nodes reach an agreement through the consensus mechanism, the contract is successfully created and can be called in the subsequent process. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address. The contract code will be saved in the contract account. The behavior of smart contracts is controlled by the contract code. In other words, smart contracts enable virtual accounts containing contract code and account storage (Storage) to be generated on the blockchain.

As shown in Figure 2, still taking Ethereum as an example, after Bob sends a transaction for calling a smart contract to the Ethereum network, the EVM of a certain node can execute the transaction and generate a corresponding contract instance. The from field of the transaction in Figure 2 is the address of the account of the transaction initiator (i.e. Bob). The "0x6f8ae93..." in the to field represents the address of the called smart contract. The value field can be a number in Ethereum. The value of the asset and the data field of the transaction save the methods and parameters for calling the smart contract. After calling the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a certain blockchain node (such as node 6 in Figure 2). Smart contracts are executed independently by each node in the blockchain network in a prescribed manner. All execution records and data are saved on the blockchain. Therefore, when the transaction is completed, the information is stored on the blockchain and cannot be tampered with. Lost transaction documents.

The schematic diagram of creating a smart contract and calling a smart contract is shown in Figure 3. To create a smart contract in Ethereum, you need to go through the process of writing the smart contract, turning it into bytecode, and deploying it to the blockchain. Calling a smart contract in Ethereum is to initiate a transaction pointing to the smart contract address. The smart contract code is distributed and runs in the virtual machine of each node in the Ethereum network.

It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some data structures, parameters, attributes and methods of the blockchain network can be set in the genesis contract. In addition, accounts with system administrator rights can create system-level contracts or modify system-level contracts (referred to as system contracts). In addition, in addition to the EVM in Ethereum, different blockchain networks may also use various virtual machines, which are not limited here.

After nodes in the blockchain network execute transactions that call smart contracts, they will generate corresponding receipts to record information related to the execution of the smart contract. In this way, relevant information about the contract execution results can be obtained by querying the receipt of the transaction. Contract execution results can be represented as events in receipts. The message mechanism can realize message delivery through events in receipts to trigger blockchain nodes to perform corresponding processing. The structure of the event can be, for example:

Event：

[topic][data]

[topic][data]

...

In the above example, the number of events may be one or more; each event includes fields such as topic and data. The blockchain node can listen to the topic of the event, and then perform preset processing when listening to the predefined topic, or read the relevant content from the data field of the corresponding event, and can execute the preset based on the read content. deal with.

One of the decentralized features of blockchain technology that distinguishes it from traditional technology is that accounting is performed on each node, or distributed accounting, instead of traditional centralized accounting. In order for the blockchain system to become a decentralized, honest and trustworthy system that is hard to break, open, and cannot tamper with data records, it needs to make distributed data records secure, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, the consensus mechanism mentioned above. After a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, other nodes will record the same block. The process by which the blocks generated above are recognized by other nodes is the consensus mechanism. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus across the entire network on block information (or block data), which can ensure that the latest blocks are accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized nature of the blockchain network, all blockchain nodes in the blockchain network maintain the same block data, which cannot meet the special needs of some nodes. Taking the alliance chain as an example, all alliance members (i.e., node members within the alliance) can form a blockchain network. All alliance members have corresponding blockchain nodes in the blockchain network and can pass through the corresponding zones. Blockchain nodes obtain all transactions and related data that occur on the blockchain network. However, in some cases, there may be some alliance members in different blockchain networks who want to complete some transactions with confidentiality requirements. These alliance members hope that these transactions can be stored on the blockchain or with the help of blockchain technology. Among other advantages, it can prevent other alliance members in its blockchain network from viewing these transactions and related data. Although these alliance members can additionally form a new blockchain network, which is similar to the above-mentioned blockchain network containing all alliance members, building a new blockchain network from scratch requires a large amount of resources, and regardless of The establishment process of the blockchain network or the configuration process after it is built are very time-consuming. The demands among alliance members are often temporary or time-sensitive, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network. . The needs among alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever alliance members change, a new blockchain network may need to be formed, resulting in a waste of resources and time. A lot of waste.

This manual can use multiple established blockchain networks as the blockchain main network, and build blockchain subnets based on multiple blockchain main networks. Then, in a consortium chain scenario such as the one mentioned above, consortium members can establish the required blockchain subnet based on their own needs based on the blockchain mainnet they participate in while already participating in the blockchain mainnet. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet consumes more resources and takes more time than establishing a completely independent blockchain network. are greatly reduced and the flexibility is extremely high. The following describes the construction plan of the blockchain subnet in this specification in conjunction with Figure 4.

Please refer to Figure 4. Figure 4 is a flow chart of a method for establishing a blockchain subnet provided by an exemplary embodiment. As shown in Figure 4, this method is applied to blockchain nodes and may include the following steps 402 to 406.

Step 402: Multiple main network nodes obtain transactions for establishing a blockchain subnet respectively. The transactions include configuration information of the blockchain subnet. The configuration information includes the identities of node members participating in establishing the blockchain subnet. Information, the multiple main network nodes belong to at least two blockchain main networks.

It can be understood that any main network node belongs to a corresponding blockchain main network, and each main network node described in the embodiment of this specification belongs to at least two blockchain main networks. It can be seen that the n main network nodes participating in the establishment of the blockchain subnet in this solution belong to m blockchain main networks, where n≥m≥2, and n and m are both positive integers. As shown in Figure 5, there are three blockchain mainnets mainnet1, mainnet2 and mainnet3. Among them, the mainnet nodes nodeA and nodeB in mainnet1, nodeH in mainnet2 and nodeM in mainnet3 are participating in the formation of the blockchain subnet subnet1. Multiple main network nodes, at this time n=4, m=3. It can be seen that the “at least two blockchain mainnets” mentioned in this plan are “multiple blockchain mainnets”, hereinafter referred to as multiple blockchain mainnets. Moreover, there is at least one main network node in any blockchain main network that participates in forming the blockchain subnet.

As mentioned before, for any blockchain main network, transactions to establish a blockchain subnet can be initiated by the administrator of the main network, that is, only administrators are allowed to establish blockchain subnets based on this main network and other main networks, and Avoid opening the permissions to create a blockchain subnet to ordinary users to prevent security issues caused by this. In some cases, ordinary users of the main network can also be allowed to initiate the above-mentioned transactions to form a blockchain subnet to meet the networking needs of ordinary users, so that ordinary users can still quickly initiate transactions even when it is inconvenient for administrators to initiate transactions. Establish a blockchain subnet.

Taking the example shown in Figure 5 as an example, the main network nodes included in the blockchain main network mainnet1 are nodeA, nodeB, nodeC, nodeD and nodeE, etc. The main network nodes included in the blockchain main network mainnet2 are nodeF, nodeG, nodeH, nodeI. etc. The main network nodes included in the blockchain mainnet mainnet3 are nodeJ, nodeK, nodeL, nodeM, etc. Assume that the node members corresponding to nodeA, nodeB, nodeH and nodeM respectively want to form a blockchain subnet: If nodeA is the administrator of mainnet1 and only allows the administrator to initiate transactions to form a blockchain subnet, then nodeA can initiate the above establishment to mainnet1 Blockchain subnet transactions; if nodeF is the administrator and only allows the administrator to initiate transactions to establish a blockchain subnet, then nodeG~nodeI need to request nodeF so that nodeF initiates the above-mentioned transaction to establish a blockchain subnet to mainnet2; If nodeJ is the administrator but allows ordinary users to initiate transactions to establish a blockchain subnet, then nodeK ~ nodeM can initiate the above transactions to establish a blockchain subnet to mainnet3. Of course, whether they are administrators or ordinary users, the node members corresponding to the blockchain nodes that initiate the transaction to form the blockchain subnet do not necessarily participate in the formed blockchain subnet. For example, although it is ultimately composed of nodeA, nodeB, nodeH and nodeM Corresponding node members form a blockchain subnet, but nodeE can initiate the above-mentioned transaction to form a blockchain subnet to mainnet1, and it does not necessarily have to be initiated by nodeA or nodeB to mainnet1, nodeH to mainnet2, and/or nodeM to mainnet3. Transactions on the blockchain subnet.

When building a blockchain subnet based on multiple blockchain mainnets, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the multiple blockchain mainnets. For example, when building the blockchain subnet subnet1 based on mainnet1, mainnet2, and mainnet3 shown in Figure 5, it can be considered that mainnet1, mainnet2, and mainnet3 are on the first layer, and subnet1 is on the second layer. Then, any blockchain mainnet in this manual can be the underlying blockchain network. The underlying blockchain network is not a blockchain subnet established on the basis of other blockchain networks. For example, mainnet1 in Figure 5 can The blockchain mainnet is considered to be the underlying blockchain network type. Of course, any blockchain main network can also be a subnet of other blockchain networks. For example, a next-level blockchain subnet (such as subnet1.1) can be further established based on subnet1 and other subnets in Figure 5. , at this time, subnet1 can be considered to be the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnets corresponding to mainnet1, mainnet2, and mainnet3. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.

Each main network node in the multiple blockchain main networks can obtain the transaction respectively. This description takes each main network node participating in the establishment of a blockchain subnet as an example. Taking any main network node in any blockchain main network as an example: in one embodiment, the transaction obtained by the node can be processed by the administrator or ordinary user of any blockchain main network. Launched in the main network. Taking the administrator as an example, the administrator of each blockchain main network can decide in advance to form a blockchain subnet. After that, each administrator can initiate the transaction in the corresponding main network respectively, so that the main network can participate in the formation of the subnet. Obtain the main network node of the blockchain subnet. In this method, the corresponding participants of each blockchain main network (such as the above-mentioned administrators or ordinary users) can initiate transactions to form a blockchain subnet in the corresponding main network.

In another embodiment, the transaction obtained by the node can also be initiated by an administrator or an ordinary user of another blockchain main network in the other blockchain main network, and processed by the other blockchain main network. The blockchain mainnet is synchronized to any of the blockchain mainnets. Still taking the administrator as an example, the administrator of a certain main network among the multiple blockchain main networks can initiate the transaction in the main network, and the main network will synchronize the transaction to other main networks. , so that other main network nodes participating in the formation of blockchain subnets can obtain it. Among them, the above-mentioned transactions can be synchronized between one of the above-mentioned main networks and other main networks through any cross-chain interaction technology, and this specification does not limit this. Based on the transaction synchronization mechanism between multiple blockchain mainnets, this method only requires the participants corresponding to any blockchain mainnet to initiate transactions to form a blockchain subnet in the mainnet, and other blocks The transaction can be obtained by the chain subnet and the mainnet nodes therein, without the above-mentioned participants or participants from other mainnets repeatedly initiating the transaction in other mainnets, thus helping to simplify the initiation process of the transaction. At the same time, the efficiency of building the blockchain subnet will be improved to a certain extent.

For any blockchain main network to synchronize the transaction from another blockchain main network, the main network node of the other blockchain main network can maintain the data of any blockchain main network. A node list of main network nodes. This list is used to record the node identification, identity information, communication address and other node information of each main network node in any of the blockchain main networks. Based on this list, the mainnet node of the other blockchain mainnet can synchronize the transaction to any blockchain mainnet in various ways. Wherein, the main network node can be any node in the other blockchain main network, or it can also be a specific node therein, such as the management node, central node or the transaction designated for the main network. A certain node, etc.

In one embodiment, the transaction may include the main network identifier of the blockchain main network to which each main network node participating in forming the blockchain subnet belongs. At this time, the main network node may use the main network identifier included in the transaction to The identifier determines which blockchain mainnet this transaction should be synced to. Taking Figure 5 as an example, assuming that the administrator of mainnet1 initiates a transaction to establish a blockchain subnet in the mainnet, the mainnet node nodeD in mainnet1 can send a request to mainnet2 if the transaction contains the mainnet identifier of mainnet2. Synchronize the transaction. Specifically, nodeD can determine the nodes in nodeF~nodeI that have network connections with itself, such as nodeI, based on the node list of mainnet2, and then can send the transaction to nodeI through the network connection, so that nodeI can synchronize the received transaction. To other nodes in mainnet2 (i.e. nodeF~nodeH), or only to the nodes that need to participate in building the blockchain subnet (i.e. nodeH). The process of mainnet1 synchronizing the transaction to mainnet3 is similar to this and will not be described again. In this way, the other blockchain main network can quickly synchronize the transaction to the blockchain main network to which other main network nodes participating in forming the blockchain subnet belong based on the main network identification.

In another embodiment, the transaction may also include the identity information (such as public keys, etc.) of each main network node participating in the establishment of the blockchain subnet. At this time, the main network node can use the identity information contained in the transaction to The information determines which mainnet nodes this transaction should be synchronized to. Still taking Figure 5 as an example, assuming that the administrator of mainnet1 initiates a transaction to establish a blockchain subnet in the mainnet, the mainnet node nodeD in mainnet1 can include the public key of the node nodeM in mainnet3 in the transaction. Next, synchronize the transaction to nodeM. Specifically, nodeD can determine nodeM from nodeJ～nodeM according to the node list of mainnet3. Furthermore, when nodeD and nodeM have established a network connection, the transaction can be directly sent to nodeM; but when the network connection is not established, nodeD can directly send the transaction to nodeM. In this case, the node among nodeJ~nodeL that has established a network connection with itself, such as nodeJ, can be determined, and then the transaction can be sent to nodeJ through the network connection, so that nodeJ can send the received transaction to nodeM. In this way, the other blockchain main network can directly synchronize the transaction to other main network nodes participating in the formation of the blockchain subnet based on the identity information of the main network node, further improving the efficiency of the transaction. Synchronization efficiency.

Among them, the main network node of another blockchain main network can obtain the node list of the main network node of any blockchain main network in one of the following ways. For example, the list can be obtained from any of the blockchain mainnets. For another example, any blockchain main network described in this solution can be an independent blockchain network, or it can also be a subnet of other blockchain networks, that is, the blockchain network can have a parent blockchain network. . In the case where any of the blockchain main networks and the other blockchain main network are managed by the same parent blockchain network, the main network node of the other blockchain main network can also be Get the node list from the parent blockchain network. For the above two acquisition methods, the main network node can obtain it in advance according to a fixed period or in response to the transaction, or it can update according to the change notification sent by any of the blockchain main networks after its own node changes, or It is updated according to the change notification sent by the parent blockchain network after determining the node change of any blockchain main network, which will not be described again. Through the above method, the main network node of the other blockchain main network can automatically update the node list. For another example, the administrator or ordinary user of another blockchain main network can also submit the list to the main network node after collecting the node list (such as through off-chain collection). For example, a list update transaction can be initiated in the main network, and the main network node executes the transaction to record the list. In this way, the administrator or ordinary user of the other blockchain main network can manually maintain (such as record or update) the node list of each main network node in any blockchain main network for all Cross-chain interaction between another blockchain main network and any blockchain network, such as synchronizing the transaction.

Step 404: The multiple main network nodes execute the transaction respectively to reveal the configuration information.

Step 406: The node devices deployed with the main network nodes respectively execute: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by themselves, load the genesis block generated based on the configuration information. to launch subnet nodes belonging to said blockchain subnet.

After the above-mentioned transactions forming the blockchain subnet are sent to any blockchain main network, the consensus nodes in the blockchain main network will conduct consensus, and after passing the consensus, the transactions will be executed by each blockchain node. Complete the establishment of the blockchain subnet. The consensus process depends on the consensus mechanism used, such as any of the consensus mechanisms mentioned above, and this specification does not limit this.

By including configuration information in the above-mentioned transaction for forming a blockchain subnet, the configuration information can be used to configure the formed blockchain subnet so that the formed blockchain subnet meets the networking requirements. For example, by including in the configuration information the identity information of the node members participating in forming the blockchain subnet, it is possible to specify which node members the formed blockchain subnet corresponds to.

The identity information of the node members may include public keys, or other information that can characterize the identities of the node members, such as node IDs. This specification does not limit this. Taking the public key as an example, each main network node has one or more corresponding public and private key pairs. The main network node holds the private key and the public key is made public and uniquely corresponds to the private key. Therefore, the public key can be used to To represent the identity of the corresponding main network node, the public key can also be used to represent the identity of the node member corresponding to the main network node. Therefore, for node members who wish to join the blockchain subnet, the public keys of the corresponding blockchain nodes of these node members on the blockchain mainnet can be added to the above-mentioned transaction to form the blockchain subnet as the above-mentioned node members. identity information.

When a transaction for establishing a blockchain subnet is obtained, the main network node can execute the transaction to disclose the configuration information to the node device where it is located. Among them, the configuration information can be disclosed through an event mechanism. For specific disclosure methods, please refer to the embodiments below, which will not be described again here.

As mentioned above, any one of the multiple blockchain mainnets includes at least one mainnet node that participates in forming a blockchain subnet. Of course, the mainnet may also include subnets that do not participate in forming a subnet. The main network nodes of the network (that is, some main network nodes in the main network participate in forming subnets). In this regard, in order to distinguish the above two types of main network nodes, the main network nodes participating in forming subnets in the multiple blockchain main networks can be called network master nodes (i.e., the multiple main network nodes described in steps 402-406 Main network node), and the remaining main network nodes that do not participate in forming the subnet are called non-networking master nodes. As shown in Figure 5, nodeA and nodeB in mainnet1, nodeH in mainnet2, and nodeM in mainnet3 are the network master nodes, while the other nodes in mainnet1 to mainnet3 are non-network master nodes. The following is an explanation of the process of the network master node participating in the establishment of the blockchain main network.

The networking master node may be a blockchain node on the blockchain main network corresponding to the node member indicated by the configuration information. When building a blockchain subnet, the network master node does not directly join the blockchain subnet. Instead, the node device used to deploy the node generates the corresponding subnet node, and the subnet node joins the blockchain subnet. net. The networking master node and the corresponding subnet node correspond to the same node member. For example, in the alliance chain scenario, they correspond to the same alliance chain member. However, the network master node belongs to the blockchain main network and the subnet node belongs to the blockchain main network. The blockchain subnet allows the node members to participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet are two independent blockchain networks , so that the blocks generated by the networking master node and the blocks generated by the subnet nodes are stored in different storages on the node device (the storage used can be a database, for example), realizing the separation of the networking master node and the subnet node. The storage used is isolated from each other, so the data generated by the blockchain subnet will only be synchronized between the various subnet nodes in the blockchain subnet, so that node members who only participate in the blockchain mainnet cannot obtain the zone. The data generated on the blockchain subnet realizes the data isolation between the blockchain main network and the blockchain subnet, and meets the transaction needs between some node members (that is, node members participating in the blockchain subnet).

The networking master node and subnet nodes are logically divided blockchain nodes. From the perspective of physical equipment, it is equivalent to the above-mentioned node devices deploying the networking master node and subnet nodes participating in the blockchain master node at the same time. network and blockchain subnet. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other. Therefore, even if the network main node and the subnet node can use the exact same public key, they should still Think of the two as different blockchain nodes. For example, in Figure 5, nodeA in mainnet1 is equivalent to the master node of the network, and the node device deploying nodeA generates nodeA1 belonging to subnet1, which is equivalent to the subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the subnet node is different from the main node of the network, it will not affect the implementation of the solution in this manual.

Of course, the node members participating in the blockchain subnet are not necessarily only part of the node members participating in the blockchain mainnet. In some cases, the node members participating in the blockchain subnet can be completely consistent with the node members participating in the blockchain main network. At this time, all node members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other. For example, one type of business can be implemented on the blockchain main network and another type of business can be implemented on the blockchain subnet, so that the two types of Business data generated by businesses are isolated from each other. For example, for the multiple blockchain mainnets mainnet1, mainnet2 and mainnet3 shown in Figure 5, all nodes in at least one blockchain mainnet can participate in forming the subnet1. Take for example that all nodes nodeA ~ nodeE in mainnet1 participate in forming subnet1. At this time, the node members corresponding to nodeA1 ~ nodeE1 in subnet1 are exactly the same as the node members corresponding to nodeA ~ nodeE in mainnet1.

In addition to the identity information of the node members mentioned above, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the identity information for the blockchain platform This manual does not limit the attribute configuration of the code. The network identifier is used to uniquely characterize the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the multiple blockchain mainnets and other blockchain subnets established on each blockchain mainnet. The identity information of the administrator of the blockchain subnet, for example, can be the public key of the node member who is the administrator; wherein, the administrator of the blockchain subnet can be the same as the administrator of at least one of the blockchain main networks. ; Alternatively, the administrator of the blockchain subnet may be different from the administrator of each blockchain main network.

One of the advantages of building a blockchain subnet through the blockchain main network is that since the network master node has been deployed on the node device that generates the subnet node, the blockchain platform code used by the network master node can be Reuse on subnet nodes eliminates the need for repeated deployment of blockchain platform code and greatly improves the efficiency of building blockchain subnets. Then, if the configuration information does not contain attribute configuration for the blockchain platform code, the subnet node can reuse the attribute configuration adopted on any group network master node. For example, the management node or master node of the blockchain subnet can be used. Attribute configuration; if the configuration information contains attribute configuration for the blockchain platform code, the subnet node can adopt this attribute configuration, so that the attribute configuration used by the subnet node is not limited to the attribute configuration of the network master node, and The network master node has nothing to do with it. The attribute configuration of the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc. This specification does not limit this.

Transactions that build a blockchain subnet can include transactions that call contracts. The transaction can specify the address of the called smart contract, the method called and the parameters passed in. For example, the contract called can be the aforementioned creation contract or system contract, the method called can be a method of establishing a blockchain subnet, and the parameters passed in can include the above configuration information. In one embodiment, the transaction may include the following information:

from：Administrator

to：Subnet

method:AddSubnet(string)

string: genesis

Among them, the from field is the information of the initiator of the transaction. For example, Administrator indicates that the initiator is the administrator; the to field is the address of the called smart contract. For example, the smart contract can be a Subnet contract, then the to field is specifically the Subnet The address of the contract; the method field is the method called. For example, the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method. In the above example, genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.

Take the nodes nodeA~nodeE on mainnet1 as an example to execute a transaction that calls the AddSubnet() method in the Subnet contract. After the transaction passes the consensus, nodeA ~ nodeE execute the AddSubnet() method respectively and pass in the configuration information to obtain the corresponding execution results.

The execution result of the contract may include the configuration information. The execution results of the contract may include the receipt mentioned above, which may include events related to the execution of the AddSubnet() method, that is, networking events. The topic of the networking event can contain a predefined networking event identifier to distinguish it from other events. For example, in an event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods. Then, nodeA~nodeE or node devices 1~5 where nodeA~nodeE are deployed can listen to the topics contained in each event in the receipt generated. When the topic containing the keyword subnet is monitored, it can be determined that the listening and executing AddSubnet( ) method-related events, that is, networking events. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

...

Then, when the first event is monitored, since the content of the included topic is other, it is determined that the event has nothing to do with the AddSubnet() method; and, when the second event is monitored, since the content of the included topic is subnet, Determine that the event is related to the AddSubnet() method, and then read the data field corresponding to the event, which contains the above configuration information. Taking the configuration information including the public keys of node members of the blockchain subnet as an example, the content of the data field may include:

{subnet1;

nodeA's public key, nodeA's IP, nodeA's port number...;

nodeB’s public key, nodeB’s IP, nodeB’s port number…;

nodeC’s public key, nodeC’s IP, nodeC’s port number…;

nodeD’s public key, nodeD’s IP, nodeD’s port number…;

}

Among them, subnet1 is the network identifier of the blockchain subnet you want to create. Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets. This information can, for example, be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, you can determine whether the above-mentioned subnet1 already exists based on the recorded network identifiers of all created blockchain subnets: If the network identifier does not exist, it means that subnet1 is the new blockchain subnet that currently needs to be created. If the network identifier exists , indicating that subnet1 already exists.

In addition to using the network identifier of the new blockchain subnet you wish to create, you can also use a predefined new network identifier, which indicates that the corresponding networking event is used to form a new blockchain subnet. For example, you can replace the above subnet1 with newsubnet, which is a predefined new network identifier. When nodeA ~ nodeE recognize that the data field contains newsubnet, they can determine that the event containing the newsubnet is a networking event, and a new one needs to be created. Blockchain subnet.

In addition to the network identifier subnet1, the above data field also contains the identity information of each node member participating in the formation of the blockchain subnet. The node device deployed with the main network node can obtain the configuration information through the message mechanism. For example, the main network node can monitor the generated receipt, and when the content of the monitored networking event records the identity information of its corresponding node member, trigger the node device where it is located to obtain the networking event. The genesis block or the configuration information contained. For another example, the node device deploying the networking master node can monitor the generated receipt, and obtain the network event when the content of the network event monitored indicates that the networking master node belongs to the node member. The genesis block or the configuration information included in the networking event.

As mentioned before, node devices can listen directly for receipts. Assume that nodeA ~ nodeM are deployed on node devices 1 ~ 13 respectively. Node devices 1 ~ 13 can monitor the receipts generated by nodeA ~ nodeM respectively. Then when it is detected that subnet1 is a newly established blockchain subnet, node device 1 ~M will further identify the identity information of the node members contained in the data field to determine its own processing method. Taking nodeA and node device 1 as an example: If node device 1 finds that the data field contains nodeA's public key, IP address, port number and other identity information, then node device 1 obtains the configuration information from the data field based on the above message mechanism. , the genesis block can be generated according to the configuration information, and the subnet node nodeA1 belonging to the blockchain subnet can be started by loading the genesis block; similarly, node device 2 can generate nodeB1, node device 8 can generate nodeH1, node Device 13 can spawn nodeM1. And, node device 3 will find that the identity information contained in the data field does not match itself, then the node device 3 will not generate a genesis block based on the configuration information in the data field, nor will it generate a blockchain node in subnet1.

As mentioned before, the main network nodes in the blockchain main network can monitor receipts and trigger the node equipment to perform relevant processing based on the monitoring results. For example, when nodeA~nodeM determines that subnet1 is a newly established blockchain subnet, they will further identify the identity information of the node members contained in the data field to determine their own processing method. For example, nodeA, nodeB, nodeH and nodeM will find that the data field contains their own public key, IP address and port number and other identity information. Assume that nodeA, nodeB, nodeH and nodeM are deployed on node devices 1 to 2, node devices 8 and 8 respectively. On node device 13, taking nodeA and node device 1 as an example: nodeA will trigger node device 1, so that node device 1 can generate a creation based on the configuration information when it obtains configuration information from the data field based on the above message mechanism. block, and start the subnet node nodeA1 belonging to the blockchain subnet by loading the genesis block; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeH will trigger node device 8 to generate nodeC1, and nodeM will trigger node device 13 to generate nodeM1. Also, nodeC will find that the identity information contained in the data field does not match itself. Assuming that nodeC is deployed on node device 3, node device 3 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1. Blockchain nodes in .

As mentioned before, the network master nodes participating in the formation of the blockchain subnet and the subnet nodes included in the blockchain subnet do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information generated in advance for nodeA1, nodeB1, nodeH1, and nodeM1, and is different from the identity information of nodeA, nodeB, nodeH, and nodeM. Still taking nodeA and node device 1 as an example: If node device 1 finds the identity information of nodeA1 in the data field, it can generate and load the genesis block to start nodeA1; or, if nodeA finds the identity information of nodeA1 in the data field, Then nodeA will trigger node device 1 to generate and load the genesis block to start nodeA1. Other blockchain nodes or node devices are handled in a similar manner and will not be described here.

In addition to configuration information, the execution results of the contract can also include the genesis block. In other words, in addition to including configuration information in the data field, you can also directly generate a genesis block containing configuration information during the execution of the contract call, thereby including the genesis block in the data field. Then for the above nodeA, nodeB, For nodeH and nodeM, the corresponding node devices 1 to 2, node device 8 and node device 13 can directly obtain the genesis block from the data field through the message mechanism without generating it themselves, which can improve the performance of nodeA1, nodeB1, nodeH1 and nodeM1. Deployment efficiency.

In this specification, the transaction to establish a blockchain subnet may not be a transaction that calls a smart contract, so that a blockchain network that does not support smart contracts can also implement the technical solution of this specification, thereby based on multiple blockchain main networks Quickly create a blockchain subnet. For example, a set of network transaction type identifiers can be predefined. When a transaction contains this group of network transaction type identifiers, it indicates that the transaction is used to form a new blockchain subnet, that is, the transaction is a transaction that forms a blockchain subnet. The blockchain platform code can include relevant processing logic for building a blockchain subnet, so that when the main network node running the blockchain platform code executes a transaction, if it is found that the transaction contains the above-mentioned network transaction type identifier , and the identity information of the node member corresponding to the main network node is included in the configuration information in the transaction, the node device deploying the main network node can be triggered based on the above processing logic to generate a genesis block containing the configuration information and pass Loading this genesis block starts subnet nodes belonging to the blockchain subnet.

The node device pulls up a process and creates an instance running the blockchain platform code in the process, which is equivalent to deploying a blockchain node on the node device. For any group of network master nodes, the node device creates the first instance of running the blockchain platform code in the above process. Similarly, for the subnet node, the node device creates a second instance running the blockchain platform code in the above process. When the first instance and the second instance are located in the same process, since no cross-process interaction is involved, the difficulty of deploying subnet nodes can be reduced and the deployment efficiency can be improved; of course, the second instance may also be located on separate node devices from the first instance. In different processes, this manual does not limit this.

Through the above method, a blockchain subnet can be created on the blockchain mainnet. Taking Figure 5 as an example, mainnet1 originally included nodeA~nodeE, mainnet2 originally included nodeF~nodeI, and mainnet3 originally included nodeJ~nodeM. Based on mainnet1, mainnet2, and mainnet3, subnet1 can be formed. This subnet1 includes nodeA1, nodeB1, nodeH1, and nodeM1, and nodeA and nodeA1, nodeB and nodeB1, nodeH and nodeH1, nodeM and nodeM1 are deployed on the same node device respectively. Similarly, subnet2 or more blockchain subnets can be established based on mainnet1 and mainnet2, where subnet2 includes nodeA2, nodeG2 and nodeH2, and nodeA and nodeA1, nodeA2, nodeH and nodeH1, nodeH2, nodeG and nodeG1 are respectively deployed in the same on the node device. In addition, subnet1, subnet2, etc. can also be used as the new blockchain main network, and on this basis, the next-level blockchain subnet can be further established. The process is similar to the establishment of subnet1 or subnet2, and will not be repeated here.

Through the above embodiments, for multiple blockchain mainnets, at least one mainnet node in each blockchain mainnet can jointly form a blockchain subnet with at least one mainnet node in other blockchain mainnets. , that is, building a cross-mainnet blockchain subnet based on multiple blockchain mainnets. Since this blockchain subnet is independent of each of the above-mentioned blockchain mainnets, transactions and related data conducted in this subnet will not be obtained by other node members in the above-mentioned mainnets. It can be seen that based on the newly established blockchain subnet, it can meet the needs of small-scale transactions between various node members participating in the formation of the subnet.

This manual also proposes another method of establishing a blockchain subnet. Please refer to Figure 6, which is a flow chart of another method for establishing a blockchain subnet provided by an exemplary embodiment. As shown in Figure 6, the method may include the following steps 602 and 604.

Step 602: Multiple node devices obtain configuration information of the blockchain subnet respectively. The main network nodes deployed in the multiple node devices belong to at least two blockchain main networks. The configuration information includes participating in the establishment of the blockchain subnet. Identity information of node members of the network.

Step 604: The multiple node devices respectively execute: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by themselves, load the genesis block generated based on the configuration information to start the node devices belonging to all nodes. Describe the subnet nodes of the blockchain subnet.

In this solution, the main network nodes deployed in the plurality of node devices can respectively execute transactions to form a blockchain subnet, so that each node device can obtain the configuration information revealed by the corresponding main network node executing the transaction. At this time, there is no essential difference between the above-mentioned transaction initiation and execution methods and the foregoing solution. For the specific process, please refer to the records of the foregoing embodiments, which will not be described again here.

Alternatively, the configuration information may also be sent by other devices to the node device where the main network node is deployed in an off-chain manner. In other words, any node device among the plurality of node devices may receive the configuration information sent by other devices in an off-chain manner. For example, each participant of a blockchain subnet to be established can determine the configuration information of the subnet at the same time or obtain it separately after negotiating to determine the formation of the subnet, and then send the configuration information to the deployed device through other methods. The corresponding node device of the main network node. When other devices send the configuration information to any node device, they may send the message through a general network connection without being based on the blockchain main network or other blockchains in which the node device participates.

Or, the node members corresponding to the main network nodes participating in the establishment of the blockchain subnet can also specify the configuration information to the node device. For example, the configuration information can be input through the human-computer interaction interface of the node device or include the configuration information. Configuration file of configuration information so that the node device can obtain the configuration information accordingly. The above configuration information can be collected by the node member itself or obtained through negotiation with other node members. The above configuration file can be generated by the node member itself or obtained from other relevant parties, which will not be described again.

Through the above method, multiple node devices deployed with main network nodes can respectively obtain the configuration information of the blockchain subnet to be formed. Further, the node device can generate a genesis block based on the obtained configuration information. The foregoing embodiments take obtaining the configuration information as an example to illustrate. In fact, the multiple node devices can also obtain the genesis block generated according to the configuration information in the above manner, such as the genesis block containing the configuration information, etc. .

Based on the genesis block generated or obtained in the above manner, each node device can load the genesis block to start the genesis block belonging to the node device after determining that the configuration information includes the identity information of the node member corresponding to the main network node deployed by itself. The subnet node of the blockchain subnet. For the generation and loading process of the genesis block, please refer to the records of the foregoing embodiments, and will not be described again here.

Through the above embodiments, a cross-mainnet blockchain subnet can also be established based on multiple blockchain mainnets. Since this blockchain subnet is independent of each of the above-mentioned blockchain mainnets, transactions and related data conducted in this subnet will not be obtained by other node members in the above-mentioned mainnets. It can be seen that the blockchain subnet established through this solution can also meet the needs of small-scale transactions between various node members participating in the formation of the subnet.

Figure 7 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 7. At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710. Of course, it may also include other hardware required for services. One or more embodiments of this specification may be implemented based on software. For example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.

As shown in Figure 8, Figure 8 is a block diagram of a device for building a blockchain subnet provided in this specification according to an exemplary embodiment. This device can be applied to the equipment shown in Figure 7 to implement the instructions of this specification. Technical solutions. The device includes: a transaction acquisition unit 801, which is used by multiple main network nodes to obtain transactions for establishing a blockchain subnet respectively. The transactions include configuration information of the blockchain subnet, and the configuration information includes participating in the establishment of the zone. Identity information of node members of the blockchain subnet. The multiple main network nodes belong to at least two blockchain main networks; the transaction execution unit 802 is used for the multiple main network nodes to execute the transaction respectively to reveal The configuration information; the node startup unit 803 is used for the node devices deployed with the main network node to respectively execute: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by itself, load based on The genesis block generated by the configuration information is used to start the subnet nodes belonging to the blockchain subnet.

Optionally, the transaction acquisition unit 801 is also used to: any main network node obtains the transaction initiated by the administrator or ordinary user of any blockchain main network in the blockchain main network; or , any main network node obtains the transaction initiated by the administrator or ordinary user of another blockchain main network in the other blockchain main network, and the transaction is initiated by the other blockchain main network Sync to any of the blockchain mainnets mentioned.

Optionally, the main network node of another blockchain main network maintains a node list of the main network nodes of any blockchain main network, and the transaction acquisition unit 801 is also used to: the other The main network node of the blockchain main network sends the transaction to the main network of any blockchain according to the node list when the transaction contains the main network identifier of any blockchain main network. The main network node of the network; or, the main network node of another blockchain main network, when the transaction contains the identity information of the main network node of any blockchain main network, according to the node The list sends the transaction to the mainnet node of any of the blockchain mainnets.

Optionally, the transaction acquisition unit 801 is also used to: obtain the node list from any of the blockchain main networks; obtain all the transactions submitted by the administrator or ordinary users of the other blockchain main network. The node list; in the case where any of the blockchain main networks and the other blockchain main network are managed by a parent blockchain network, obtain the said node list from the parent blockchain network Node list.

Optionally, the transaction of establishing a blockchain subnet includes a transaction of calling a smart contract.

Optionally, the transaction execution unit 802 is also configured to: the execution result of the smart contract includes the genesis block, and the node device where the main network node is deployed obtains the genesis block through a message mechanism; or, The execution result of the smart contract includes the configuration information. The node device where the main network node is deployed obtains the configuration information through a message mechanism, and generates the genesis block based on the obtained configuration information.

Optionally, the receipt generated by executing the smart contract includes networking events related to the establishment of the blockchain subnet. The transaction execution unit 802 is also configured to: the main network node monitors the generated receipt, and When the content of the monitored networking event records the identity information of its corresponding node member, trigger the node device where it is located to obtain the genesis block or the configuration information contained in the networking event; Alternatively, the node device deploying the main network node monitors the generated receipt, and when the content of the monitored networking event indicates that the main network node belongs to the node member, obtain the network event. The genesis block or the configuration information contained.

Optionally, the networking event includes an event in which the subject name in the receipt contains a predefined networking identifier.

Optionally, when the content of the networking event includes the following identification, it indicates that the networking event is related to the establishment of the blockchain subnet: the network identification of the blockchain subnet that is desired to be established, and the network The identifier is different from the network identifier of the existing blockchain subnet; or, a predefined new network identifier, which indicates that the networking event is used to form a new blockchain subnet.

Optionally, the transaction includes a networking transaction type identifier, and the networking transaction type identifier indicates that the transaction is used to establish a new blockchain subnet.

Optionally, the configuration information also includes at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, and the attribute configuration for the blockchain platform code.

Optionally, the blockchain subnet has the same administrator as at least one of the blockchain main networks; or, the blockchain subnet has different administrators from each of the blockchain main networks.

Optionally, the node startup unit 803 is also configured to: the node device create a second instance that runs the platform code corresponding to the blockchain subnet, and trigger the second instance to load the genesis block.

Optionally, any of the blockchain main networks is an underlying blockchain network, or a subnet managed by other blockchain networks.

Optionally, there is at least one main network node in any of the blockchain main networks participating in forming the blockchain subnet.

As shown in Figure 9, Figure 9 is a block diagram of another device for building a blockchain subnet provided in this specification according to an exemplary embodiment. This device can be applied to the equipment shown in Figure 7 to implement this specification. technical solutions. The device includes: an information acquisition unit 901, used for multiple node devices to respectively acquire the configuration information of the blockchain subnet. The main network nodes deployed in the multiple node devices belong to at least two blockchain main networks. The configuration information It includes the identity information of the node members participating in the establishment of the blockchain subnet; the node starting unit 902 is used for the multiple node devices to respectively execute: the configuration information includes the identity of the node member corresponding to the main network node deployed by itself. In the case of information, load the genesis block generated based on the configuration information to start the subnet nodes belonging to the blockchain subnet.

Optionally, the information acquisition unit 901 is also used for one of the following: any node device receives the configuration information sent by other devices in an off-chain manner; any node device obtains the configuration information specified by a node member, The node member corresponds to the main network node deployed locally by any node device; any node device obtains the configuration information revealed by the locally deployed main network node by executing a transaction to establish a blockchain subnet.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.

For the convenience of description, when describing the above device, the functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and/or hardware.

Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

This specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through communications networks. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain implementations.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of this specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a," "the" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although one or more embodiments of this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent substitutions, improvements, etc. shall be included in the scope of protection of one or more embodiments of this specification.

Claims (21)

1. A method of forming a blockchain subnet, including:

   Multiple main network nodes respectively obtain transactions for establishing a blockchain subnet. The transactions include configuration information of the blockchain subnet, and the configuration information includes identity information of node members participating in establishing the blockchain subnet, so The multiple main network nodes belong to at least two blockchain main networks;

   The multiple main network nodes execute the transaction respectively to reveal the configuration information;

   The node devices deployed with the main network nodes respectively perform: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by themselves, load the genesis block generated based on the configuration information to start the belonging to the main network node. The subnet node of the blockchain subnet.
2. According to the method of claim 1, any main network node in any blockchain main network obtains the transaction, including:

   Any main network node obtains the transaction initiated by the administrator or ordinary user of any blockchain main network in the blockchain main network; or,

   Any mainnet node obtains the transaction initiated by the administrator or ordinary user of another blockchain mainnet in the other blockchain mainnet, and the transaction is synchronized by the other blockchain mainnet to any of the blockchain mainnets mentioned.
3. According to the method of claim 2, the main network node of another blockchain main network maintains a node list of the main network nodes of any blockchain main network, and the other blockchain main network Synchronize the transaction to any of the blockchain mainnets, including:

   The main network node of the other blockchain main network sends the transaction to any one of the main network nodes according to the node list when the transaction contains the main network identifier of any one of the main network blocks of the blockchain. The mainnet node of the blockchain mainnet; or,

   The main network node of the other blockchain main network sends the transaction to the main network node according to the node list when the transaction contains the identity information of the main network node of any blockchain main network. Describe the main network nodes of any blockchain main network.
4. According to the method of claim 3, the main network node of another blockchain main network obtains the node list in one of the following ways:

   Obtain the node list from any of the blockchain main networks;

   Obtain the node list submitted by the administrator or ordinary user of the other blockchain main network;

   In the case that any one of the blockchain main networks and the other blockchain main network are managed by a parent blockchain network, the node list is obtained from the parent blockchain network.
5. According to the method of claim 1, the transaction of establishing a blockchain subnet includes a transaction of calling a smart contract.
6. The method of claim 5,

   The execution result of the smart contract includes the genesis block, and the node device where the main network node is deployed obtains the genesis block through a message mechanism; or,

   The execution result of the smart contract includes the configuration information. The node device where the main network node is deployed obtains the configuration information through a message mechanism, and generates the genesis block based on the obtained configuration information.
7. According to the method of claim 6, the receipt generated by executing the smart contract contains networking events related to the establishment of the blockchain subnet, and the node device where the main network node is deployed obtains the creation through a message mechanism. The world block or the configuration information includes:

   The main network node monitors the generated receipt, and when the content of the monitored networking event records the identity information of its corresponding node member, triggers the node device where it is located to obtain the content of the networking event. The genesis block or the configuration information; or,

   The node device deploying the main network node monitors the generated receipt, and when the content of the monitored networking event indicates that the main network node belongs to the node member, obtains the information contained in the networking event. The genesis block or the configuration information.
8. According to the method of claim 7, the networking event includes an event in which the subject name in the receipt contains a predefined networking identifier.
9. According to the method of claim 7, when the content of the networking event includes the following identifier, it indicates that the networking event is related to the establishment of the blockchain subnet:

   The network identifier of the blockchain subnet that you wish to establish, and the network identifier is different from the network identifier of the existing blockchain subnet; or,

   A predefined new network identifier indicating that the networking event is used to establish a new blockchain subnet.
10. According to the method of claim 1, the transaction includes a networking transaction type identifier, and the networking transaction type identifier indicates that the transaction is used to establish a new blockchain subnet.
11. The method according to claim 1, the configuration information further includes at least one of the following:

    The network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, and the attribute configuration for the blockchain platform code.
12. According to the method of claim 1, the blockchain subnet has the same administrator as at least one of the blockchain main networks; or, the blockchain subnet has the same administrator as each of the blockchain main networks. All are different.
13. According to the method of claim 1, the node device loading is based on the genesis block, including:

    The node device creates a second instance that runs the platform code corresponding to the blockchain subnet, and triggers the second instance to load the genesis block.
14. According to the method of claim 1, any of the blockchain main networks is an underlying blockchain network, or a subnet managed by other blockchain networks.
15. According to the method of claim 1, there is at least one main network node in any of the blockchain main networks participating in forming the blockchain subnet.
16. A method of forming a blockchain subnet, including:

    Multiple node devices respectively obtain the configuration information of the blockchain subnet. The main network nodes deployed in the multiple node devices belong to at least two blockchain main networks. The configuration information includes nodes participating in the establishment of the blockchain subnet. Members’ identifying information;

    The plurality of node devices respectively perform: in the case where the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by itself, load the genesis block generated based on the configuration information to start the block belonging to the The subnet node of the chain subnet.
17. According to the method of claim 16, any node device obtains the configuration information, including one of the following:

    Any node device receives the configuration information sent by other devices in an off-chain manner;

    Any node device obtains the configuration information specified by a node member, and the node member corresponds to the main network node deployed locally by the any node device;

    Any node device obtains the configuration information revealed by the locally deployed main network node by executing transactions to establish a blockchain subnet.
18. A device for building a blockchain subnet, including:

    A transaction acquisition unit is used for multiple main network nodes to obtain transactions for establishing a blockchain subnet respectively. The transactions include configuration information of the blockchain subnet, and the configuration information includes nodes participating in establishing the blockchain subnet. Identity information of members, the multiple main network nodes belong to at least two blockchain main networks;

    A transaction execution unit, used for the multiple main network nodes to execute the transaction respectively to reveal the configuration information;

    A node startup unit, configured for node devices deployed with the main network node to respectively execute: in the case where the configuration information includes identity information of node members corresponding to the main network nodes deployed by themselves, load the configuration information generated based on the configuration information. Genesis block to launch subnet nodes belonging to said blockchain subnet.
19. A device for building a blockchain subnet, including:

    An information acquisition unit is used for multiple node devices to respectively acquire the configuration information of the blockchain subnet. The main network nodes deployed in the multiple node devices belong to at least two blockchain main networks. The configuration information includes participating in the establishment of the Identity information of node members of the blockchain subnet;

    A node startup unit configured for the plurality of node devices to perform respectively: when the configuration information includes the identity information of the node members corresponding to the main network nodes deployed by itself, load the genesis block generated based on the configuration information to Start subnet nodes belonging to said blockchain subnet.
20. An electronic device including:

    processor;

    Memory used to store instructions executable by the processor;

    Wherein, the processor implements the method according to any one of claims 1-17 by running the executable instructions.
21. A computer-readable storage medium having computer instructions stored thereon, which when executed by a processor, implements the steps of the method according to any one of claims 1-17.

Images