CN115086338A

CN115086338A - Block chain subnet building method and device

Info

Publication number: CN115086338A
Application number: CN202210473060.XA
Authority: CN
Inventors: 陶友贤
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2022-09-20
Anticipated expiration: 2042-04-29
Also published as: CN115086338B; WO2023207076A1

Abstract

One or more embodiments of the present specification provide a method and an apparatus for building a blockchain subnet. The method can comprise the following steps: each block chain link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, and the configuration information comprises identity information of node members participating in establishing the block chain sub-network; each block link point in the block chain main network respectively executes the transaction; when the configuration information contains identity information of node members corresponding to the first block link nodes, the node equipment deploying the first block link nodes generates a created block containing the configuration information based on the transaction and starts a second block link node belonging to the block link sub-network based on the created block.

Description

Block chain subnet building method and device

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a block chain subnet building method and device.

Background

Blockchain (Blockchain) technology is built on top of transport networks, such as point-to-point networks. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. All nodes in the same blockchain network are in a peer-to-peer position and have completely consistent block data. However, there is sometimes a need for implementing a small-scale transaction for node members corresponding to some nodes in a blockchain network, so as to prevent other node members from obtaining the transactions and related data thereof.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for building a blockchain subnet.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a method for building a blockchain subnet, including:

the method comprises the steps that a plurality of main network nodes respectively obtain transactions for building block chain subnets, the transactions comprise configuration information of the block chain subnets, the configuration information comprises identity information of node members participating in building the block chain subnets, and the main network nodes belong to at least two block chain main networks;

the plurality of main network nodes respectively execute the transaction to reveal the configuration information;

the node devices deployed with the main network node respectively execute: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

According to a second aspect of one or more embodiments of the present specification, there is provided another method for building a blockchain subnet, including:

the method comprises the steps that a plurality of node devices respectively obtain configuration information of a block chain sub-network, a main network node is deployed in the node devices and belongs to at least two block chain main networks, and the configuration information comprises identity information of node members participating in building the block chain sub-network;

the plurality of node devices respectively perform: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

According to a third aspect of one or more embodiments of the present specification, there is provided an apparatus for constructing a blockchain subnet, including:

the system comprises a transaction acquisition unit, a transaction processing unit and a transaction processing unit, wherein the transaction acquisition unit is used for acquiring transactions for establishing a block chain sub-network by a plurality of main network nodes respectively, the transactions comprise configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in establishing the block chain sub-network, and the plurality of main network nodes belong to at least two block chain main networks;

the transaction execution unit is used for respectively executing the transactions by the multiple main network nodes so as to reveal the configuration information;

a node starting unit, configured to separately execute, by the node devices deployed with the master network node: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

According to a fourth aspect of one or more embodiments of the present specification, there is provided another apparatus for building a blockchain subnet, including:

the system comprises an information acquisition unit, a configuration unit and a processing unit, wherein the information acquisition unit is used for a plurality of node devices to respectively acquire configuration information of a block chain sub-network, deployed main network nodes in the plurality of node devices belong to at least two block chain main networks, and the configuration information comprises identity information of node members participating in building the block chain sub-network;

a node starting unit, configured to perform, by the plurality of node devices, respectively: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of the first aspects by executing the executable instructions.

According to a sixth aspect of one or more embodiments of the present description, there is provided a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to any one of the first aspects.

With the above embodiment, for a plurality of block chain main networks, at least one main network node in each block chain main network may jointly establish a block chain sub-network with at least one main network node in other block chain main networks, that is, establish a block chain sub-network across the main networks based on the plurality of block chain main networks. Since the blockchain subnetwork is independent of the individual blockchain masters, transactions and their associated data conducted in the subnetwork are not available to other node members in the master. Therefore, based on the newly constructed block chain sub-network, the requirement of small-range transaction among all the node members participating in the construction of the sub-network can be met.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

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

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

Fig. 4 is a flowchart of a method for building a blockchain subnet according to an exemplary embodiment.

Fig. 5 is a schematic diagram of a blockchain subnet constructed based on a plurality of blockchain main networks according to an exemplary embodiment.

Fig. 6 is a flowchart of another method for building a blockchain subnet according to an exemplary embodiment.

Fig. 7 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 8 is a block diagram of an apparatus for building a blockchain subnet according to an exemplary embodiment.

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

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

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

Block chains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. Participants joining the public chain can read the data records on the chain, participate in transactions, compete for billing rights for new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds what may be bytecode, and the to field of the transaction is null. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account of the initiator of the transaction (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract being invoked, the value field may be the value of the digital asset in the Etherhouse, and the data field of the transaction holds the method and parameters for invoking the smart contract. After invoking the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a blockchain node (e.g., node 6 in fig. 2). The intelligent contract is independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet workshop network.

It should be noted that, in addition to the creation of the intelligent contract by the user, the intelligent contract may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain networks may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to EVM in the ethernet, different blockchain networks may employ various virtual machines, which is not limited herein.

After executing a transaction that invokes a smart contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. After a node (e.g., a unique node) creates a block, other nodes record the same block if the created block is recognized by other nodes. The process of the generated block gaining acceptance by other nodes is a consensus mechanism. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of workload (Proof of Work, POW), Proof of stock right (Proof of stamp, POS), Proof of commission rights (freed Proof of stamp, DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some federations in different blockchain networks that wish to complete some transactions with security requirements, and these federations would both wish to have these transactions certified on the blockchain or with the help of other advantages of blockchain technology, and avoid other federations in the blockchain network in which they are located from viewing these transactions and related data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federating members often change, and the federating members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever the federating members change, thereby causing a great waste of resources and time.

The present specification may use the established multiple block chain networks as a block chain master network, and establish a block chain subnet based on the multiple block chain master networks. Then, in a federation chain scenario such as that described above, federation members may, having already participated in a blockchain master, build the required blockchain subnets based on their needs and based on the blockchain master with which they participated. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility. The building scheme of the blockchain sub-network in this specification is described below with reference to fig. 4.

Referring to fig. 4, fig. 4 is a flowchart of a method for building a blockchain subnet according to an exemplary embodiment. As shown in fig. 4, the method applied to the blockchain node may include the following steps:

step 402, a plurality of master network nodes respectively acquire transactions for building block chain subnets, the transactions including configuration information of the block chain subnets, the configuration information including identity information of node members participating in building the block chain subnets, and the plurality of master network nodes belonging to at least two block chain master networks.

It will be appreciated that any master network node is attributed to a respective blockchain master network, whereas each master network node described in the embodiments of the present description is attributed to at least two blockchain master networks. Therefore, in the scheme, n main network nodes participating in building the block chain sub-network belong to m block chain main networks, wherein n is more than or equal to m and is more than or equal to 2, and both n and m are positive integers. As shown in fig. 5, there are three blockchain main networks, namely main network 1, main network 2, and main network 3, where main network nodes nodeA and nodeB in main network 1, nodeH in main network 2, and nodeM in main network 3 are the multiple main network nodes participating in building blockchain subnet1, where n is 4, and m is 3. Therefore, the at least two block chain main networks are the multiple block chain main networks, and are referred to as the multiple block chain main networks. And at least one master network node exists in any block chain master network to participate in building the block chain sub-network.

As described above, for any blockchain main network, the transaction for constructing the blockchain sub-network may be initiated by the administrator of the main network, that is, the administrator is only allowed to construct the blockchain sub-network based on the main network and other main networks, and the construction authority of the blockchain sub-network is prevented from being opened to the ordinary users, so as to prevent the security problem caused by the construction authority. In some cases, the ordinary user of the main network may also be allowed to initiate a transaction for building the blockchain subnet, so as to meet the networking requirements of the ordinary user, and the ordinary user can still quickly build the blockchain subnet when an administrator is not convenient to initiate the transaction.

Taking fig. 5 as an example, the master nodes included in the blockchain master network main 1 are nodeA, nodeB, nodeC, nodeD, and nodeE, the master nodes included in the blockchain master network main 2 are nodeF, nodeG, nodeH, and nodeI, and the master nodes included in the blockchain master network main 3 are nodeJ, nodeK, nodeL, and nodeM. Suppose that the node members respectively corresponding to nodeA, nodeB, nodeH and nodeM wish to construct a blockchain subnet: if nodeA is the administrator of mainnet1 and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build a blockchain subnet may be initiated by nodeA to mainnet 1; if nodeF is administrator and only allows administrator to initiate the transaction of building up blockchain sub-network, nodeG-nodeI need to make request to nodeF, so that nodeF initiates the transaction of building up blockchain sub-network to mainnet 2; if nodeJ is an administrator but allows a normal user to initiate a transaction to build a blockchain subnet, nodeK to nodeM may each initiate a transaction to build a blockchain subnet to mainnet 3. Of course, whether it is an administrator or a general user, the node members corresponding to the blockchain link points initiating the transaction for building the blockchain sub-network do not necessarily participate in the built blockchain sub-network, for example, although the blockchain sub-network is finally built by the node members corresponding to nodeA, nodeB, nodeH and nodeM, the transaction for building the blockchain sub-network may be initiated from nodeE to mainnet1, but the transaction for building the blockchain sub-network is not necessarily initiated from nodeA or nodeB to mainnet1, nodeH to mainnet2 and/or nodeM to mainnet 3.

When a block chain sub-network is constructed based on a plurality of block chain main networks, it is easy to understand that a logical hierarchical relationship exists between the block chain sub-network and the plurality of block chain main networks. For example, when building a blockchain subnet1 based on main 1, main 2, and main 3 shown in fig. 5, it can be considered that main 1, main 2, and main 3 are in the first tier, and sublet 1 is in the second tier. Then, any of the blockchain main networks in this specification may be an underlying blockchain network, and the underlying blockchain network is not a blockchain sub-network built on the basis of other blockchain networks, such as main 1 in fig. 5, which may be regarded as a blockchain main network belonging to the type of underlying blockchain network. Of course, any one of the blockchain main networks may also be a sub-network of another blockchain network, for example, a next-level blockchain sub-network (e.g., subnet1.1) may be further constructed on the basis of subnet1 in fig. 5 and other sub-networks, at this time, it may be considered that subnet1 is the blockchain main network corresponding to the blockchain sub-network, and this does not affect that subnet1 belongs to the blockchain sub-networks corresponding to main 1, main 2, and main 3 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

Each master network node in the multiple blockchain master networks can acquire the transaction, and this specification takes each master network node participating in building a blockchain sub-network as an example for explanation. Taking any master network node in any block chain master network as an example: in an embodiment, the transaction obtained by the node may be initiated in the main network by an administrator or an ordinary user of any blockchain main network. Taking an administrator as an example, the administrator of each blockchain master network may negotiate in advance to decide to construct a blockchain subnet, and then each administrator may initiate the transaction in the corresponding master network, so that the master network node in the master network that constructs the blockchain subnet can obtain the transaction. In this manner, a transaction for building a blockchain sub-network may be initiated in a corresponding main network by a participant (such as an administrator or a general user) corresponding to each blockchain main network.

In another embodiment, the transaction acquired by the node may also be initiated in another blockchain master network by an administrator or an ordinary user of the other blockchain master network, and synchronized to any one blockchain master network by the other blockchain master network. Still taking an administrator as an example, the administrator of one of the multiple blockchain masters may initiate the transaction in the master, and the master synchronizes the transaction to other masters, so that the masters participating in the other masters and constructing the blockchain subnets may acquire the transaction. The synchronization of the transactions between the certain main network and the other main networks can be realized through any cross-chain interaction technology, which is not limited in this specification. Based on a transaction synchronization mechanism among the multiple blockchain main networks, in the method, only a participant corresponding to any blockchain main network initiates a transaction for building blockchain subnets in the main network, and other blockchain subnets and main network nodes therein can acquire the transaction without repeatedly initiating the transaction in other main networks by the participant or participants of other main networks, so that the initiation process of the transaction is facilitated to be simplified, and the building efficiency of the blockchain subnets is improved to a certain extent.

For a scheme in which any blockchain master network synchronizes the transaction from another blockchain master network, the master network node of the another blockchain master network may maintain a node list of the master network node of the any blockchain master network, where the list is used to record node information, such as node identifiers, identity information, and communication addresses, of each master network node in the any blockchain master network. Based on this list, the master node of the other blockchain master may synchronize the transaction to the any blockchain master in a number of ways. The master network node may be any node in the other blockchain master network, or may also be a specific node therein, such as a certain node that may be designated for a management node, a central node, or the transaction of the master network.

In an embodiment, the transaction may include a master network identifier of a blockchain master network to which each master network node participating in building a blockchain subnet belongs, and in this case, the master network node may determine to which blockchain master networks the transaction should be synchronized according to the master network identifier included in the transaction. Taking fig. 5 as an example, assuming that the administrator of main 1 initiates a transaction in this main network to build a blockchain sub-network, the main network node nodeD in main 1 may synchronize the transaction to main 2 with the inclusion of the main network identification of main 2 in the transaction. Specifically, nodeD may determine, according to the node list of mainnet2, a node in nodeF-nodeI that has a network connection with itself, such as nodeI, and may send the transaction to nodeI through the network connection, so that the nodeI synchronizes the received transaction to other nodes in mainnet2 (i.e., nodeF-nodeH), or synchronizes only to a node that needs to participate in building the blockchain subnet (i.e., nodeH). The process of synchronizing the transaction to main 3 by main 1 is similar and will not be described further. In this way, the other blockchain master network can quickly synchronize the transaction to the blockchain master network to which the other master network nodes participating in the building of the blockchain sub-network belong based on the master network identification.

In another embodiment, the transaction may also include identity information (e.g., public key, etc.) of each master network node participating in building the blockchain subnet, and in this case, the master network node may determine to which master network nodes the transaction should be synchronized according to the identity information included in the transaction. Still taking fig. 5 as an example, assuming that the administrator of main 1 initiates a transaction in the main network to build a blockchain sub-network, the main network node nodeD in main 1 can synchronize the transaction to nodeM in main 3 with the public key of the node nodeM in this transaction. Specifically, the nodeD may determine the nodeM from nodeJ to nodeM according to a node list of mainnet3, and further, may directly send the transaction to the nodeM when the nodeD establishes a network connection with the nodeM; and under the condition that the network connection is not established, a node such as nodeJ, which has network connection with the node among nodeJ-nodeL, can be determined, and then the transaction can be sent to nodeJ through the network connection, so that the nodeJ sends the received transaction to nodeM. By the method, the other blockchain main network can directly synchronize the transaction with other main network nodes participating in building the blockchain sub-network in a targeted manner based on the identity information of the main network nodes, and the synchronization efficiency of the transaction is further improved.

The master network node of another block chain master network may obtain the node list of the master network node of any block chain master network in one of the following manners. For example, the list may be obtained from any of the blockchain masters. For another example, any one of the blockchain main networks described in the present solution may be an independent blockchain network, or may also be a sub-network of another blockchain network, that is, the blockchain network may have a parent blockchain network. In the case where any blockchain master network and the other blockchain master network are managed by the same parent blockchain network, the master network node of the other blockchain master network may also obtain the node list from the parent blockchain network. For the above two obtaining modes, the master network node may obtain in advance according to a fixed period or obtain in response to the transaction, or update according to a change notification sent by the master network of any block chain after the node is changed, or update according to a change notification sent by the master network of the block chain after the node of any block chain is determined to be changed, which is not described again. In this way, the master node of the other blockchain master network can automatically update the node list. As another example, an administrator or a general user of the main network of the other block chain may submit the list to the main network node in case of collecting (e.g., collecting in a chain-down manner) the list of nodes. A list update transaction may be initiated in the primary network, for example, to in turn execute the transaction record list by the primary network node. In this manner, an administrator or average user of the other blockchain master network may manually maintain (e.g., record or update) a list of nodes of each master network node in the any blockchain master network for use in cross-chain interactions between the other blockchain master network and the any blockchain network, such as to synchronize the transactions.

Step 404, the plurality of master network nodes respectively execute the transaction to reveal the configuration information.

Step 406, the node devices deployed with the master network node respectively execute: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

After the transaction of the building blockchain sub-network is sent to any blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, the transaction is executed by each blockchain link point, so that building of the blockchain sub-network is completed. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, and is not limited by the present specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including identity information of the node members participating in the building of the blockchain subnet in the configuration information, it can be specified to which node members the built blockchain subnet corresponds.

The identity information of the node member may include a public key, or other information capable of representing the identity of the node member, such as a node ID, which is not limited in this specification. Taking a public key as an example, each master network node has one or more corresponding sets of public and private key pairs, and the master network node holds the private key while the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding master network node can be represented by the public key, and the identity of a node member corresponding to the master network node can also be represented by the public key. Therefore, for the node members who wish to join the blockchain sub-network, the public keys of the blockchain nodes corresponding to the node members on the blockchain main network can be added to the transaction for establishing the blockchain sub-network to serve as the identity information of the node members.

In the case of acquiring a transaction for constructing a blockchain subnet, the master network node may execute the transaction to expose the configuration information to the node device where the master network node is located. The configuration information may be exported through an event mechanism, and the specific export manner may be referred to in the following embodiments, which are not described herein again.

As mentioned above, for any one of the plurality of blockchain masters, it includes at least one master node participating in building a blockchain subnet, and of course, the master network may also include master nodes not participating in building a subnet (i.e., some master nodes in the master network participate in building a subnet). For this, in order to distinguish the two types of master network nodes, the master network node participating in constructing the sub-network in the block chain master networks may be referred to as a networking master node (i.e., the master network nodes in step 402 and step 406), and the rest of the master network nodes not participating in constructing the sub-network may be referred to as non-networking master nodes. As shown in fig. 5, nodeA and nodeB in mainnet1, nodeH in mainnet2, and nodeM in mainnet3 are networking master nodes, and other nodes in mainnet1 to mainnet3 are non-networking master nodes. The following describes a process in which a networking master node participates in building a blockchain master network.

The networking master node may be a block chain link point corresponding to a node member indicated by the configuration information on the block chain master network. When building a blockchain sub-network, a main networking node does not directly join the blockchain sub-network, but a node device for deploying the node generates a corresponding sub-network node, and the sub-network node joins the blockchain sub-network. The networking master node and the corresponding sub-network node correspond to the same node member, for example, correspond to the same alliance chain member in an alliance chain scene, but the networking master node belongs to a blockchain master network, and the sub-network node belongs to a blockchain sub-network, so that the node member can participate in the transactions of the blockchain master network and the blockchain sub-network respectively; and because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the networking main node and the blocks generated by the sub-network nodes are respectively stored in different storages (the adopted storages can be databases, for example) on the node equipment, so that mutual isolation between the storages used by the networking main node and the sub-network nodes respectively is realized, data generated by the blockchain sub-network can only be synchronized among all sub-network nodes in the blockchain sub-network, so that the node members only participating in the blockchain main network can not obtain the data generated on the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial node members (namely, the node members participating in the blockchain sub-network) are met.

The main networking nodes and the sub-networking nodes are logically divided block chain nodes, and from the perspective of physical equipment, the node equipment which is equivalent to the main networking nodes and the sub-networking nodes and is deployed participates in the main block chain network and the sub-block chain network at the same time. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the networking main node and the sub-network node may adopt the same public key, the networking main node and the sub-network node should be regarded as different blockchain nodes. For example, in fig. 5, nodeA in mainnet1 corresponds to a networking master node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a subnet node. Therefore, because the identity systems are mutually independent, even if the public key adopted by the subnet node is different from the networking master node, the implementation of the scheme in the specification is not affected.

Of course, the node members participating in the blockchain sub-network are not necessarily only a part of the node members participating in the blockchain main network. In some cases, the node members participating in the blockchain subnet may be completely consistent with the node members participating in the blockchain main network, and at this time, all the node members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, so that service data generated by the two types of services may be isolated from each other. For example, for the multiple blockchain main networks main 1, main 2, and main 3 shown in fig. 5, all nodes in at least one blockchain main network may participate in the sub net1. Taking the example that all nodes nodeA to nodeE in mainnet1 participate in building sublet 1, at this time, the node members corresponding to nodeA1 to nodeE1 in sublet 1 are completely consistent with the node members corresponding to nodeA to nodeE in mainnet 1.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the plurality of blockchain main networks and other blockchain subnets established on each blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as the administrator; wherein an administrator of the blockchain sub-network may be the same as an administrator of at least one of the blockchain main networks; alternatively, the administrator of the blockchain sub-network may be different from the administrator of each blockchain main network.

One of the advantages of building the block chain sub-network by the block chain main network is that the block chain platform code used by the block chain main node can be multiplexed on the sub-network node because the main networking node is already deployed on the node device generating the sub-network node, so that the repeated deployment of the block chain platform code is avoided, and the building efficiency of the block chain sub-network is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the subnet node may reuse the attribute configuration adopted on any networking master node, for example, the attribute configuration of the management node or master node of the blockchain subnet may be adopted; if the configuration information contains the attribute configuration for the block chain platform code, the subnet node can adopt the attribute configuration, so that the attribute configuration adopted by the subnet node is not limited by the attribute configuration of the networking master node and is irrelevant to the networking master node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet may include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeE on mainnet1 perform a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA to nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

The execution result of the contract may include the configuration information. The result of contract execution may include the receipt as described above, which may contain events related to the execution of the AddSubnet () method, i.e., networking events. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, the nodeA to nodeE or the node devices 1 to 5 deploying the nodeA to nodeE can determine to monitor the event related to the execution of the AddSubnet () method, that is, the networking event, by monitoring topic contained in each event in the generated receipt and monitoring topic containing the keyword subnet. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the 1 st event is monitored, the event is determined to be irrelevant to the AddSubnet () method because the contained content of topic is other; and when the 2 nd event is monitored, determining that the event is related to an AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field contains the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

the public key of nodeA, the IP of nodeA, port number … of nodeA;

public key of nodeB, IP of nodeB, port number … of nodeB;

public key of nodeC, IP of nodeC, port number … of nodeC;

the public key of nodeD, the IP of nodeD, port number … of nodeD;

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, it can be determined whether the subnet1 described above already exists according to the recorded network identifications of all blockchain subnets that have been created: if the network identifier does not exist, the subnet1 is a new blockchain subnet which needs to be created currently, and if the network identifier exists, the subnet1 already exists.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA-nodeE recognizes that the data field includes newsbnet, it may be determined that the event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member participating in building the blockchain subnet. The node device deployed with the master network node may obtain the configuration information through a message mechanism. For example, the primary network node may monitor the generated receipt, and trigger the node device where the primary network node is located to acquire the founding block or the configuration information included in the networking event when the monitored content of the networking event records the identity information of the node member corresponding to the primary network node. For another example, the node device that deploys the networking master node may monitor the generated receipt, and acquire the creature block or the configuration information included in the networking event when the monitored content of the networking event indicates that the networking master node belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA-nodeM are respectively deployed on the node devices 1-13, and the node devices 1-13 can monitor receipts respectively generated by the nodeA-nodeM, then under the condition that the subnet1 is monitored to be a block chain subnet which needs to be newly built, the node devices 1-M further identify the identity information of the node members contained in the data field to determine the own processing mode. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of a nodeA, node device 1 may generate a created block according to the configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and start a subnet node nodeA1 belonging to the block chain subnet by loading the created block; similarly, node device 2 may generate nodeB1, node device 8 may generate nodeB h1, and node device 13 may generate nodeB m 1. And if the node device 3 finds that the identity information included in the data field does not match with itself, the node device 3 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet1.

As described above, the master node in the blockchain master may listen for a receipt and trigger the node device to perform the relevant processing according to the listening result. For example, when nodeA to nodeM determine that subnet1 is a blockchain subnet that needs to be newly created, identity information of node members included in the data field is further identified to determine their own processing method. For example, nodeA, nodeB, nodeH, and nodeM may find that the data field contains identity information such as their public key, IP address, and port number, and assume that nodeA, nodeB, nodeH, and nodeM are respectively deployed on node devices 1-2, node device 8, and node device 13, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 can generate an appearance creating block according to the configuration information under the condition that the configuration information is obtained from the data field based on the message mechanism, and starts a subnet node nodeA1 belonging to the block chain subnet by loading the appearance creating block; similarly, nodeB will trigger nodeB1 to be generated by node device 2, nodeH will trigger nodeC1 to be generated by node device 8, and nodeM will trigger nodeM1 to be generated by node device 13. And the nodeC finds that the identity information contained in the data field is not matched with the nodeC, and if the nodeC is deployed on the node device 3, the node device 3 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in the subnet1.

As described above, the networking master node participating in building the block chain sub-network and the sub-network nodes included in the block chain sub-network do not necessarily adopt the same identity information. Therefore, in the above-described embodiment, the data field may contain therein the identity information generated in advance for nodeA1, nodeB1, nodeH1, and nodeM1, and be distinguished from the identity information of nodeA, nodeB, nodeH, and nodeM. Taking nodeA and node device 1 as an example: if the identity information of nodeA1 is found in the data field, node device 1 may generate and load a founding block start nodeA 1; alternatively, nodeA may trigger node device 1 to generate and load a birth creation block to launch nodeA1 if identity information of nodeA1 is found in the data field. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

In addition to configuration information, the execution results of the contract may also include a foundational block. In other words, in addition to containing the configuration information in the data field, the created block containing the configuration information may also be generated directly in the process of executing the contract call, so that the created block is contained in the data field, and then for the nodeA, nodeB, nodeH, and nodeM described above, the corresponding node devices 1 to 2, node device 8, and node device 13 may obtain the created block directly from the data field through a message mechanism without self-generation, and the deployment efficiency of nodeA1, nodeB1, nodeH1, and nodeM1 may be improved.

In this specification, a transaction for creating a blockchain subnet may not be a transaction for calling an intelligent contract, so that a blockchain network that does not support an intelligent contract may also implement the technical solution of this specification, thereby quickly creating a blockchain subnet based on a plurality of blockchain masters. For example, a group network transaction type identifier may be predefined, and when a transaction includes the group network transaction type identifier, it indicates that the transaction is used to construct a new blockchain subnet, that is, the transaction is a transaction for constructing a blockchain subnet. The blockchain platform code may include related processing logic for building a blockchain subnet, so that when a master node running the blockchain platform code executes a transaction, if it is found that the transaction includes the networking transaction type identifier and identity information of a node member corresponding to the master network node is included in configuration information in the transaction, a node device deploying the master network node may be triggered to generate an innovation block including the configuration information based on the processing logic, and a subnet node belonging to the blockchain subnet is started by loading the innovation block.

The node device is equivalent to deploying a blockchain node on the node device by pulling up a process and creating an instance of running blockchain platform code in the process. For any networking master node, the node device creates a first instance of the operation blockchain platform code in the process. Similarly, for a subnet node, it is formed by the node device creating a second instance of the run blockchain platform code in the process described above. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the subnet nodes can be reduced, and the deployment efficiency can be improved; of course, the second instance may be in a different process on the node device than the first instance, and this specification does not limit this.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 5 as an example, main 1 originally includes nodeA-nodeE, main 2 originally includes nodeF-nodeI, and main 3 originally includes nodeJ-nodeM, and subnet1 can be constructed based on main 1, main 2, and main 3, where subnet1 includes nodeA1, nodeB1, nodel 1, and nodel 1, and nodeA-nodeA 1, nodel-nodel 1, nodel-nodel 1, and nodel-nodel 1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets may be constructed based on mainnet1 and mainnet2, where subnet2 includes nodeA2, nodeG2 and nodel 2, and nodeA1, nodeA2, nodel and nodel 1, nodel 2, and nodel 1 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may also be used as new blockchain main networks, and a next-level blockchain sub-network is further constructed on this basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again.

With the above embodiment, for a plurality of block chain master networks, at least one master network node in each block chain master network may jointly establish a block chain sub-network with at least one master network node in other block chain master networks, that is, establish a block chain sub-network across the master networks based on the plurality of block chain master networks. Since the blockchain subnetwork is independent of the individual blockchain masters, transactions and their associated data conducted in the subnetwork are not available to other node members in the master. Therefore, based on the newly constructed block chain sub-network, the requirement of small-range transaction among all the node members participating in the construction of the sub-network can be met.

The present specification also provides another method for building a blockchain subnet. Referring to fig. 6, fig. 6 is a flowchart of another method for building a blockchain subnet according to an exemplary embodiment. As shown in fig. 6, the method may include the steps of:

step 602, a plurality of node devices respectively obtain configuration information of a blockchain subnet, where deployed master network nodes in the plurality of node devices belong to at least two blockchain master networks, and the configuration information includes identity information of node members participating in building the blockchain subnet.

Step 604, the plurality of node devices respectively perform: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

In this scheme, the master network node deployed in the plurality of node devices may respectively perform a transaction for establishing a block chain subnet, so that each node device may obtain the configuration information that is revealed by the execution of the transaction by the corresponding master network node. At this time, the initiating and executing modes of the transaction are not substantially different from the foregoing schemes, and the specific process may refer to the descriptions of the foregoing embodiments, which are not described herein again.

Alternatively, the configuration information may also be sent by other devices to the node device in which the master network node is deployed in a link-down manner. In other words, any node device of the plurality of node devices may receive the configuration information sent by other devices in a downlink manner. For example, each participant of the blockchain subnet to be established may determine or respectively obtain the configuration information of the subnet at the same time when negotiating to determine to establish the subnet, and then send the configuration information to the corresponding node device with the main network node deployed in another manner. When sending the configuration information to any node device, the other device may send the message in a general form of network connection without being based on the blockchain master network or other blockchains in which the node device participates.

Or, the node member corresponding to the master network node participating in building the blockchain subnet may also designate the configuration information to the node device, for example, the configuration information or a configuration file containing the configuration information may be input through a human-computer interaction interface of the node device, so that the node device obtains the configuration information accordingly. The configuration information may be acquired by the node member itself or obtained through negotiation with other node members, and the configuration file may be generated by the node member itself or obtained from other related parties, which is not described in detail again.

By the above manner, the plurality of node devices deployed with the main network node can respectively acquire the configuration information of the block chain sub-network to be constructed, and further, the node devices can generate the creature blocks based on the acquired configuration information. In fact, the plurality of node devices may also obtain a creation block generated according to the configuration information, such as a creation block containing the configuration information, in the manner described above.

Based on the created block generated or obtained in the above manner, each node device may load the created block to start a subnet node belonging to the block chain subnet, when it is determined that the configuration information includes identity information of a node member corresponding to a main network node deployed by itself. The generation and loading process of the creating block may refer to the description of the foregoing embodiments, and details are not described here.

Through the embodiment, the block chain sub-network crossing the main network can be established based on a plurality of block chain main networks. Since the blockchain subnetwork is independent of the individual blockchain masters, transactions and their associated data conducted in the subnetwork are not available to other node members in the master. Therefore, based on the block chain sub-network established by the scheme, the requirement of small-range transaction among the node members participating in establishing the sub-network can be met.

Fig. 7 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 7, at the hardware level, the apparatus includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile storage 710, but may also include hardware required for other services. One or more embodiments of the present description can be implemented in software, such as by the processor 702 reading corresponding computer programs from the non-volatile storage 710 into the memory 708 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 8 is a block diagram of a migration apparatus of a blockchain node according to an exemplary embodiment, where the apparatus may be applied to the device shown in fig. 7 to implement the technical solution of the present specification. The device includes:

a transaction obtaining unit 801, configured to respectively obtain transactions for building a blockchain subnet by a plurality of master network nodes, where the transactions include configuration information of the blockchain subnet, the configuration information includes identity information of node members participating in building the blockchain subnet, and the plurality of master network nodes belong to at least two blockchain master networks;

a transaction executing unit 802, configured to respectively execute the transactions by the multiple master network nodes to reveal the configuration information;

a node starting unit 803, configured to separately execute, by the node device deployed with the master network node: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

Optionally, the transaction obtaining unit 801 is further configured to:

any main network node acquires the transaction initiated by an administrator or a common user of any block chain main network in the block chain main network; or,

any master network node obtains the transaction initiated in another blockchain master network by an administrator or an ordinary user of the other blockchain master network, and the transaction is synchronized to any blockchain master network by the other blockchain master network.

Optionally, the master network node of the other block link master network maintains a node list of the master network node of any block link master network, and the transaction obtaining unit 801 is further configured to:

the master network node of the other block chain master network sends the transaction to the master network node of any block chain master network according to the node list under the condition that the transaction contains the master network identifier of any block chain master network; or,

and the master network node of the other block chain master network sends the transaction to the master network node of any block chain master network according to the node list under the condition that the transaction contains the identity information of the master network node of any block chain master network.

Optionally, the transaction obtaining unit 801 is further configured to:

acquiring the node list from any block chain master network;

acquiring the node list submitted by an administrator or a common user of the main network of the other block chain;

and acquiring the node list from a parent blockchain network under the condition that the any blockchain master network and the other blockchain master network are managed by the parent blockchain network.

Optionally, the transaction for establishing the blockchain subnet includes a transaction for invoking an intelligent contract.

Optionally, the transaction executing unit 802 is further configured to:

the execution result of the intelligent contract comprises the creation block, and the node equipment with the main network node is deployed to obtain the creation block through a message mechanism; or,

and the execution result of the intelligent contract comprises the configuration information, the node equipment with the main network node acquires the configuration information through a message mechanism, and the creation block is generated according to the acquired configuration information.

Optionally, the receipt generated by executing the intelligent contract includes networking events related to building the blockchain subnet, and the transaction execution unit 802 is further configured to:

the main network node monitors the generated receipt, and under the condition that the monitored content of the networking event records the identity information of the corresponding node member, the node device where the main network node is located is triggered to acquire the founding block or the configuration information contained in the networking event; or,

and the node equipment deploying the main network node monitors the generated receipt, and acquires the creature block or the configuration information contained in the networking event under the condition that the monitored content of the networking event indicates that the main network node belongs to the node member.

Optionally, the networking event includes: the subject name in the receipt contains the event for the predefined networking identification.

Optionally, 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 block chain sub-network which is expected to be established is different from the network identifier of the existing block chain sub-network; or,

and a predefined new network identifier, wherein the new network identifier indicates that the networking event is used for establishing a new block chain subnet.

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

Optionally, the configuration information further includes at least one of:

the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

Optionally, the blockchain sub-network is the same as an administrator of at least one blockchain main network; or the block chain sub-network is different from the administrator of each block chain main network.

Optionally, the node starting unit 803 is further configured to:

and the node equipment creates a second example for running the platform code corresponding to the block chain subnet and triggers the second example to load the creation block.

Optionally, any one of the block chain main networks is a bottom layer block chain network, or a sub-network managed by another block chain network.

Optionally, at least one master network node exists in any one of the blockchain master networks to participate in building the blockchain sub-network.

Fig. 9 is a block diagram of another migration apparatus for a blockchain node according to an exemplary embodiment, which may be applied to the device shown in fig. 7 to implement the technical solution of the present specification, as shown in fig. 9. The device includes:

an information obtaining unit 901, configured to separately obtain, by multiple node devices, configuration information of a blockchain subnet, where deployed master nodes in the multiple node devices belong to at least two blockchain masters, and the configuration information includes identity information of node members participating in building the blockchain subnet;

a node starting unit 902, configured to perform, by the multiple node devices respectively: and loading a creation block generated based on the configuration information to start the subnet nodes belonging to the block chain subnet under the condition that the configuration information comprises the identity information of the node members corresponding to the main network node deployed by the configuration information.

Optionally, the information obtaining unit 901 is further configured to:

any node device receives the configuration information sent by other devices in a downlink mode;

any node device acquires the configuration information appointed by a node member, wherein the node member corresponds to a main network node locally deployed by any node device;

any node device obtains the configuration information which is released by a locally deployed main network node through executing the transaction of building a block chain sub-network.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, 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 convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

This description 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 particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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), 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following 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 desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

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

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A method of building a blockchain subnet, comprising:

2. The method of claim 1, any master network node in any blockchain master network obtaining the transaction, comprising:

and any master network node acquires the transaction initiated in another block chain master network by an administrator or an ordinary user of the other block chain master network, and the transaction is synchronized to any block chain master network by the other block chain master network.

3. The method of claim 2, the master node of the other blockchain master maintaining a list of nodes of master nodes of the either blockchain master synchronizing the transaction to the either blockchain master, comprising:

4. The method of claim 3, wherein the master node of the other blockchain master obtains the list of nodes by one of:

acquiring the node list from any block chain master network;

5. The method of claim 1, the transactions to group blockchain subnets comprising transactions to invoke smart contracts.

6. The method of claim 5, wherein the first and second light sources are selected from the group consisting of,

the execution result of the intelligent contract comprises the configuration information, the node equipment with the main network node is deployed acquires the configuration information through a message mechanism, and the creating block is generated according to the acquired configuration information.

7. The method of claim 6, wherein the receipt generated by executing the smart contract includes a networking event related to building the blockchain subnet, and the node device deployed with the master network node acquires the created block or the configuration information through a message mechanism, including:

and the node equipment deploying the main network node monitors the generated receipt, and acquires the creation block or the configuration information contained in the networking event under the condition that the monitored content of the networking event indicates that the main network node belongs to the node member.

8. The method of claim 7, the networking event comprising: the subject name in the receipt contains the event for the predefined networking identification.

9. The method of claim 7, indicating that the networking event is relevant for constructing the blockchain subnet when the content of the networking event contains the following identification:

10. The method of claim 1, the transaction comprising a networking transaction type identifier indicating that the transaction is for building a new blockchain subnet.

11. The method of claim 1, the configuration information further comprising at least one of:

12. The method of claim 1, the blockchain subnet being the same as an administrator of at least one of the blockchain master networks; or the block chain sub-network is different from the administrator of each block chain main network.

13. The method of claim 1, the node device loading based on the founder block, comprising:

14. The method of claim 1, wherein any one of the blockchain main networks is an underlying blockchain network or a subnet managed by other blockchain networks.

15. The method of claim 1, wherein at least one master network node exists in any one of the blockchain master networks to participate in building the blockchain sub-network.

16. A method of building a blockchain subnet, comprising:

the method comprises the steps that a plurality of node devices respectively obtain configuration information of block chain subnets, wherein major network nodes which belong to at least two block chain major networks are deployed in the node devices, and the configuration information comprises identity information of node members which participate in building the block chain subnets;

17. The method of claim 16, wherein any node device obtains the configuration information, comprising one of:

any node equipment receives the configuration information sent by other equipment in a downlink mode;

18. An apparatus for building a blockchain subnet, comprising:

a transaction execution unit, configured to execute the transaction by the multiple master network nodes respectively to reveal the configuration information;

19. An apparatus for building a blockchain subnet, comprising:

a node starting unit, configured to perform, by the plurality of node devices, respectively: and loading a creature block generated based on the configuration information to start the sub-network node belonging to the block chain sub-network under the condition that the configuration information comprises the identity information of the node member corresponding to the main network node deployed by the sub-network.

20. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-17 by executing the executable instructions.

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