CN114363349B

CN114363349B - Block chain sub-network starting method and device

Info

Publication number: CN114363349B
Application number: CN202111669752.3A
Authority: CN
Inventors: 陶友贤
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2024-04-02
Anticipated expiration: 2041-12-31
Also published as: CN114363349A

Abstract

One or more embodiments of the present disclosure provide a method and apparatus for starting a blockchain subnet. The method is applied to node equipment, wherein the node equipment is provided with a main network node belonging to a block chain main network and a sub-network node belonging to a first block chain sub-network, and the first block chain sub-network is managed by the block chain main network, and the method comprises the following steps: reading node starting information from a first database maintained by the node equipment, wherein the node starting information comprises a first subnet identifier corresponding to a first block chain subnet, generation block information of the first block chain subnet and node members, and the first database corresponds to a subnet node of the first block chain subnet; and starting the subnet node of the first block chain subnet by loading the read generation block information, and respectively sending handshake messages containing the first subnet identification to the read node members to establish network connection.

Description

Block chain sub-network starting method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for starting a blockchain subnet.

Background

Blockchain technology builds on top of point-to-point networks. Nodes in the blockchain network verify and store data using a chained data structure and employ a distributed node consensus algorithm to generate and update the data. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their associated data, for which purpose a new blockchain network (i.e., a blockchain subnetwork) may be created on top of the existing blockchain network (i.e., the blockchain main network).

Disclosure of Invention

The embodiments described in this specification relate to blockchain technologies such as ethernet, but it should be noted that the embodiments described in this specification should be implemented within a legal scope, i.e. the implementation process of the embodiments described in this specification should not violate relevant legal regulations.

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

In order 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, a method for starting a blockchain subnetwork is provided, which is applied to a node device, where a main network node belonging to a blockchain main network and a subnetwork node belonging to a first blockchain subnetwork are deployed, where the first blockchain subnetwork is managed by the blockchain main network, and the method includes:

Reading node starting information from a first database maintained by the node equipment, wherein the node starting information comprises a first subnet identifier corresponding to a first block chain subnet, generation block information of the first block chain subnet and node members, and the first database corresponds to a subnet node of the first block chain subnet;

and starting the subnet node of the first block chain subnet by loading the read generation block information, and respectively sending handshake messages containing the first subnet identification to the read node members to establish network connection.

According to a second aspect of one or more embodiments of the present specification, there is provided an activation apparatus of a blockchain subnetwork, applied to a node device in which a main network node belonging to a blockchain main network and a subnetwork node belonging to a first blockchain subnetwork managed by the blockchain main network are disposed, the apparatus comprising:

the information reading unit is used for reading node starting information from a first database maintained by the node equipment, wherein the node starting information comprises a first subnet identifier corresponding to a first block chain subnet, generation block information of the first block chain subnet and node members, and the first database corresponds to a subnet node of the first block chain subnet;

The node starting unit is used for starting the subnet node of the first block chain subnet by loading the read creating block information and respectively sending handshake messages containing the first subnet identification to the read node members to establish network connection.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method as described in the first aspect by executing the executable instructions.

According to a fourth 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 as described in the first aspect.

In summary, the node device in the technical solution of the present disclosure maintains a first database corresponding to the subnet node of the first blockchain subnet, and the first subnet identifier corresponding to the first blockchain subnet is recorded in the database. The node device can read the node starting information including the first subnet identifier from the database, further start the subnet node of the first block chain subnet according to the node starting information, and respectively send handshake messages containing the first subnet identifier to the node members of the first block chain subnet to establish network connection, thereby realizing the starting of the first block chain subnet. By the scheme, in the process of starting the first block chain sub-network, the node equipment can read data from the first database of the first block chain sub-network without acquiring the first sub-network identification from the database of the block chain main network, so that the starting flow of the node equipment is simplified, and the efficient starting of the first block chain sub-network is facilitated.

Drawings

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

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

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

Fig. 4 is a schematic diagram of a blockchain main network and a blockchain subnetwork according to an exemplary embodiment.

Fig. 5 is a flowchart of a method for starting a blockchain subnet, according to an exemplary embodiment.

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

Fig. 7 is a block diagram of a block chain subnet enabling device according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying 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 the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying 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, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. Participants joining the public chain may read data records on the chain, participate in transactions, compete for billing rights for new blocks, and so forth. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, a user is supported to create and invoke some complex logic in the ethernet network. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

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

Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction for invoking a smart contract to the ethernet network, the EVM of a node may execute the transaction and generate the corresponding contract instance. The from field of the transaction in fig. 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 may be the numerical value of the digital asset in the ethernet, and the data field of the transaction holds the method and parameters for calling the smart contract. The value of the policy may change after invoking the smart contract. Subsequently, a client may view the current value of the policy 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, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating a smart contract and invoking a smart contract is shown in fig. 3. To create an intelligent contract in the ethernet, the intelligent contract needs to be written, compiled into byte codes, deployed to a blockchain and the like. The intelligent contract is called in the Ethernet, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract code is distributed and operated in a virtual machine of each node in the Ethernet network.

It should be noted that, in addition to the smart contracts that can be created by the user, the smart contracts can also be set by the system in the creation block. Such contracts are commonly referred to as an opening contract. In general, some blockchain networks may be configured in the creation contract for data structures, parameters, attributes, and methods. In addition, an account with system administrator rights may create a system level contract, or modify a system level contract (simply referred to as a system contract). In addition, different blockchain networks may employ various virtual machines in addition to the EVM in the ethernet, which is not limited herein.

After executing a transaction invoking the 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 result of contract execution can be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in a receipt. The messaging mechanism may implement messaging through events in the receipt to trigger a blockchain node or node device deploying the blockchain node to perform a corresponding process. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above examples, the number of events may be one or more; wherein each event includes fields such as a theme (topic) and data (data), respectively. The blockchain node or the node device deploying the blockchain node may perform a preset process by listening to the topic of the event, thereby performing a preset process in case of listening to the predefined topic, or read the related content from the data field of the corresponding event, and may perform a preset process based on the read content.

In the event mechanism described above, the client having the monitoring function is located at the monitoring party (such as the user having the monitoring requirement), for example, the SDK for implementing the monitoring function is running on the client, and the client monitors the event generated by the blockchain node, and the blockchain node only needs to normally generate the receipt. In addition to the event mechanism described above, the transmission of transaction information may be accomplished in other ways. For example, the listening code may be embedded in the blockchain platform code running at the blockchain point such that the listening code may listen to one or more of the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc., and send the monitored data to the predefined listener. Since the snoop code is deployed in the blockchain platform code, rather than at the client of the snooper, such a snoop code-based implementation is relatively more proactive than an event mechanism. The above-mentioned monitoring code may be added into the blockchain platform code by a developer of the blockchain platform in the development process, or may be embedded by a monitoring party based on the own requirement, which is not limited in this specification.

Blockchain technology differs from one of the decentralized features of conventional technology in that accounting is performed on individual nodes, otherwise known as distributed accounting, rather than conventional centralized accounting. The blockchain system is to be a hard-to-break, public, untampered, decentralised, honest and trusted system for data records, and needs to be secure, clear and irreversible for distributed data records in as short a time as possible. In different types of blockchain networks, in order to keep account books consistent among the nodes of each record account book, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a block granularity consensus mechanism may be implemented between blockchain nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism may be implemented between blockchain nodes, for example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node approving the blockchain transaction may respectively add the blockchain transaction to its own maintained latest block, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism that the blockchain node achieves the consensus of the whole network about the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm, honeybadgenbft algorithm, etc.

Because of the decentralization characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same block data, and the special requirements of part of nodes cannot be met. Taking a blockchain as an example, all the coalition members (i.e., node members in the coalition) can form a blockchain network, all the coalition members respectively have corresponding blockchain nodes in the blockchain network, and all transactions and related data occurring on the blockchain network can be obtained through the corresponding blockchain nodes. In some cases, however, there may be some coalition members desiring to complete transactions with security requirements, which may be desirable to both be able to document on the blockchain or to take advantage of other advantages of blockchain technology, and to avoid other coalition members from viewing such transactions and related data. Although these coalition members can additionally create a new blockchain network in a manner similar to that described above that includes all coalition members, building a new blockchain network from scratch requires a significant amount of resources and is time consuming either the creation of the blockchain network or the post-build deployment process. The requirements among the alliance members are often temporary or have certain timeliness, so that the new blockchain network quickly loses the meaning of existence due to the disappearance of the requirements, thereby further increasing the chain building cost of the blockchain network. The requirements between the members of the federation often vary, and the members of the federation corresponding to each requirement also often vary, so that a new blockchain network may need to be created each time a change occurs to the member of the federation, resulting in a significant waste of resources and time.

To this end, the created blockchain network may be used as a blockchain master network, and a blockchain subnetwork may be created based on the blockchain master network. Then, in a federated chain scenario such as that described above, federated members may create a desired blockchain sub-network on the blockchain main network based on their own needs, already participating in the blockchain main network. Because the blockchain subnetwork is built on the basis of the blockchain main network, compared with a completely independent blockchain network, the creation process of the blockchain subnetwork has the advantages of greatly reduced consumed resources, time consumption and the like, and extremely high flexibility.

The following briefly describes the process of quickly creating a blockchain sub-network based on a blockchain master network: each main network node in the block chain main network respectively acquires the transaction of creating the block chain sub-network to reveal configuration information, when the configuration information contains the identity information of the node member corresponding to the first main network node, node equipment for deploying the first main network node starts the first sub-network node belonging to the block chain sub-network based on the creation block containing the configuration information.

The transaction of creating the blockchain sub-network can be initiated by an administrator of the blockchain main network, namely, only the administrator is allowed to create the blockchain sub-network on the basis of the blockchain main network, and the creation authority of the blockchain sub-network is prevented from being opened to the common users so as to prevent the security problem caused by the creation authority. In some cases, the common user of the blockchain main network can be allowed to initiate the transaction for creating the blockchain sub-network, so that the networking requirement of the common user is met, and the common user can still quickly create the blockchain sub-network under the condition that an administrator is inconvenient to initiate the transaction.

Taking the example shown in fig. 4, the blockchain home network is a mainnet of mainnet0, and the mainnet0 includes blockchain nodes of nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Suppose nodeA, nodeB, nodeC and nodeD wish to create a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to create a blockchain subnet, then the transaction to create a blockchain subnet described above may be initiated by nodeA to mailnet 0; alternatively, nodeB-nodeE may request nodeA to initiate the above-described transaction to create a blockchain subnet to main 0. If nodeA is an administrator but allows a general user to initiate a transaction to create a blockchain subnet, then each of nodeA through nodeE may initiate the transaction to create a blockchain subnet described above to main net 0. Of course, the blockchain node that initiates the transaction to create the blockchain subnetwork, whether an administrator or an average user, does not necessarily participate in the created blockchain subnetwork, such as, although ultimately the blockchain subnetwork is created by nodeA, nodeB, nodeC and nodeD, the transaction to create the blockchain subnetwork described above may be initiated by nodeE to mainnet0, and not necessarily by nodeA-nodeD.

When creating a blockchain subnetwork on the basis of a blockchain main network, it is easy to understand that there is a logical hierarchical relationship between the blockchain subnetwork and the blockchain main network. For example, when creating a blockchain subnet1 on the mailnet 0 shown in fig. 4, it may be considered that the mailnet 0 is at the first layer and the subnet1 is at the second layer, that is, the mailnet 0 is a parent network of the subnet1, and the subnet1 is a subnet of the mailnet 0. And a next-level blockchain subnet may be further created on the basis of the blockchain subnet, for example, another blockchain subnet1.1 may be further created on the basis of subnet1 in fig. 4, where the subnet may be considered to be in the third layer, subnet1 is a parent network corresponding to subnet1.1, subnet1.1 is a subnet of subnet1, and subnet1.1 is a grandson subnet of main 0. Likewise, subnet1.1 can still be newly created on the basis of the subnet, so that the multi-level tree structure is formed among the blockchain networks.

In this specification, any blockchain network may be managed by its corresponding parent network, i.e., by the blockchain network that created the any blockchain network. For example, in a multi-level tree structure in which the blockchain main network is the root node (the lowest level of the root node) and each blockchain sub-network is another node as shown in fig. 4, the blockchain sub-network represented by any node is managed by the blockchain network corresponding to its parent node, and in a special case, when the blockchain main network is the bottom layer blockchain network, the blockchain main network is managed by the blockchain main network itself. The blockchain home network in this specification may be an underlying blockchain network, which refers to a blockchain sub-network that is not created on the basis of other blockchain networks, so that there is no other blockchain network than the blockchain home network that can manage the blockchain home network, such as the mailnet 0 in fig. 4 may consider a blockchain home network that belongs to the underlying blockchain network type, and the mailnet 0 manages the mailnet 0 itself. Of course, the blockchain master network may be a subnetwork of other blockchain networks, which is not limiting in any way in this description. The multi-level tree structure realizes layer-by-layer management by managing the corresponding child nodes through the father node, reduces the management pressure of the block chain main network, and simultaneously avoids exposing the child network information of the upper network to the lower network, thereby realizing the secret management of each level of network.

In this specification, node devices may implement deployment of blockchain nodes by creating an instance of running blockchain platform code in a process. For example, a node device may first create a first instance in a process to form a blockchain node in a blockchain master network; and when the node member corresponding to the node device wants to participate in creating the blockchain sub-network, a second instance can be created in the process, wherein the second instance is different from the first instance, and the blockchain node in the blockchain sub-network is formed by the second instance. 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 first subnet node can be reduced, and the deployment efficiency can be improved. Of course, the second instance may also be in a different process on the node device than the first instance, which is not limited by the present description.

In fact, each blockchain node deployed on any node device according to the embodiments of the present disclosure is a different blockchain instance running on the any node device, the blocks generated by each blockchain node deployed on any node device are respectively stored in different databases on the any node device, and the different databases used by each blockchain node deployed on any node device are isolated from each other. For example, a node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in creating the blockchain sub-network, a second process different from the first process may be started, and a second instance may be created in the second process, where the second instance is different from the first instance, and thus the second instance forms a second blockchain node in the blockchain sub-network.

In this way, a blockchain subnetwork managed by the blockchain subnetwork can be created on the blockchain subnetwork. Taking fig. 4 as an example, for a main network 0 containing nodes a to e, a subnet1 may be created based on the main network 0, where any subnet node in the subnet1 contains nodes a1 to D1 and is disposed on the same node device as its corresponding main network node in the main network 0, for example, nodes a and a1 are disposed on the node device A, nodeB and nodes b1 are disposed on the node device B, nodeC and nodes c1 are disposed on the node device C, nodeD and nodes D1 are disposed on the node device D. Similarly, a subnet2 or more blockchain subnets may also be created on the main net0, wherein subnet2 contains nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are deployed on the same node device, respectively. And, subnet1, subnet2, etc. may be used as the blockchain main network, and a blockchain sub-network may be further created on the basis of the blockchain main network, for example, a blockchain sub-network 1.1 may be created on the basis of subnet1, the process is similar to that of creating subnet1 or subnet2, but only the blockchain main network is replaced by blockchain sub-network subnet1, which will not be described herein, and finally, the obtained subnet1.1 contains nodeA3, nodeB3 and nodeC3, so that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2 and nodeC3 are deployed on the same node device respectively. It can be seen that the node device a is provided with a main network node nodeA and sub network nodes nodeA1, nodeA2 and nodeA1.1, and the node device B is provided with a main network node nodeB and sub network nodes nodeB1, nodeB2 and nodeB1.1, and the node device B and the node device C are similar to the node device a and will not be described again. The node device D has a main network node nodeD and a sub-network node nodeD deployed, and the node device E has a main network node and a sub-network node node2 deployed.

In the aforementioned multi-level tree structure, any blockchain subnetwork may be activated or deactivated under the control of the blockchain subnetwork. The starting process of any block chain sub-network is the process of starting corresponding sub-network nodes by the node equipment where each sub-network node forming the block chain sub-network is located and establishing network connection among each block chain sub-network. Taking the subnet1 shown in fig. 4 as an example, a process of starting the subnet1 is a process of respectively starting the subnet nodes nodeA1 to nodeD1 by the node devices a to D and establishing network connection between the subnet nodes nodeA1 to nodeD 1.

As previously described, a blockchain subnetwork created based on a blockchain subnetwork may be managed by the blockchain subnetwork. In the related art, the blockchain subnetwork may be controlled and started by the blockchain main network, for example, a subnetwork identifier of the blockchain subnetwork is maintained in the blockchain main network, and the subnetwork identifier may be loaded through the subnetwork identifier maintained by the main network, which belongs to a node device where a subnetwork node of the blockchain subnetwork is located, so as to start the blockchain subnetwork. However, since the subnet identifier is maintained by the blockchain main network, the node device needs to acquire the subnet identifier from the database of the blockchain main network in the process of starting the blockchain subnet, which is not convenient for realizing efficient starting of the blockchain subnet.

In order to solve the above-mentioned problems, the present disclosure proposes a method for starting a blockchain subnet, in which a node device records a subnet identifier corresponding to the blockchain subnet in a database corresponding to the blockchain subnet maintained by the node device, so that the node device can read the subnet identifier from the database in the process of starting the blockchain subnet. The creation scheme of the blockchain subnetwork of the present description is described below in conjunction with fig. 4.

Referring to fig. 5, fig. 5 is a flowchart of a method for starting up a blockchain subnet according to an exemplary embodiment. As shown in fig. 5, the method is applied to a node device in which a main network node belonging to a blockchain main network and a sub-network node belonging to a first blockchain sub-network managed by the blockchain main network are disposed, and the method includes:

step 502, node starting information is read from a first database maintained by the node device, where the node starting information includes a first subnet identifier corresponding to a first blockchain subnet, generation block information of the first blockchain subnet, and node members, and the first database corresponds to a subnet node of the first blockchain subnet.

In the node device described in the present specification, a main network node belonging to a blockchain main network and a sub-network node belonging to a first blockchain sub-network are deployed, that is, the node device participates in creating the blockchain main network and the first blockchain sub-network. The first blockchain sub-network may be any blockchain sub-network that the node device participates in, and the blockchain sub-network may be managed by the blockchain main network.

In addition, the blockchain master network described herein may be an underlying blockchain network that is not a blockchain subnetwork built on the basis of other blockchain networks. For example, the blockchain master network in the solution described in this specification may be the blockchain master network mainnet0 in fig. 4, which is not created based on other blockchain networks and may be considered an underlying blockchain network. Alternatively, the blockchain master network described herein may be a subnetwork of other blockchain networks, i.e., a blockchain network of components on the basis of other blockchain networks. For example, the blockchain main network in the solution described in this specification may also be a blockchain subnet1, which is created based on the blockchain main network mainnet0, and may be regarded as a subnet of the blockchain main network mainnet 0. Accordingly, the first blockchain subnetwork described herein is a blockchain subnetwork managed by a blockchain main network, which can be created based on the blockchain main network.

The blockchain main network may manage at least one blockchain sub-network, any blockchain sub-network may include at least one sub-network node, and the first blockchain sub-network in the solution described in this specification may be any blockchain sub-network described above, and the node device may be a node device where any sub-network node in the blockchain sub-network is located. Taking fig. 4 as an example, the node device described in the present specification may be any node device from node device a to node device E, for example, in a case where the blockchain main network is a main net0 and the first blockchain sub-network is a subnet1 (where the node device includes nodeA1, B1, C1, and D1), the node device may be any node device from node device A, B, C, D; in the case where the blockchain main network is mainnet0 and the first blockchain subnetwork is subnet2 (where the node devices include nodeA2, B2, C2, and E2), the node device may be any node device in the node devices A, B, C, E; in the case where the blockchain main network is subnet1 and the first blockchain sub network is subnet1.1 (where the node devices include nodeA1.1, B1.1, and C1.1), the node device may be any node device in the node devices A, B, C.

As described above, in the case where a plurality of blockchain nodes are deployed in the node apparatus, the node apparatus may maintain databases respectively corresponding to the respective blockchain nodes, and the respective databases may be isolated from each other. Taking the foregoing node device a as an example, the blockchain nodes nodeA, nodeA1, and nodeA1.1 are deployed in the device, and databases corresponding to the three blockchain nodes may be maintained in the node device, which may be referred to as databases DBA, DBA1, and DBA1.1.

Any database can be recorded with node starting information of each node in the corresponding blockchain network, such as network identification, generation block information, node members and the like of the blockchain network. Therefore, as the first database corresponding to the first blockchain subnetwork in each blockchain main network, node starting information of the first blockchain subnetwork is recorded in the database, for example, when the blockchain main network is main net0 and the first blockchain subnetwork is subnet1, the first database is the database DBA1 corresponding to nodeA1, and node starting information such as the first subnetwork identifier corresponding to subnet1, the creation block information of subnet1, and the node member is recorded in the database.

Wherein the network identifier of the first blockchain subnet is used to uniquely characterize the blockchain subnet, so that the subnet identifier can be distinguished from the network identifier of any other blockchain network in the multi-level tree structure. The generation block information of the first blockchain subnet is related information of the generation block generated when the subnet is created, for example, may include account information (such as an administrator account, a common account, etc.), an IP address, a port number, etc. of an original node member when the first blockchain subnet is created, and may further include attribute configuration of a blockchain platform code for the first blockchain subnet, etc., which is not limited in this specification. The administrator account may be, for example, identity information of an administrator of the first blockchain subnet, such as a public key of a node member serving as the administrator. The administrators of the blockchain main network and the blockchain sub network may be the same or different. The node members of the first blockchain sub-network may be regarded as identity information of each node member in the sub-network, so as to indicate which blockchain nodes the first blockchain sub-network at the current moment contains. For example, the identity information of the node member may include a public key of the node, or other information capable of characterizing the identity of the node, such as a node ID, which is not limited in this specification. Taking the public key as an example, each blockchain node has one or more public and private key pairs, the private key is held by the blockchain node, and the public key is disclosed and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. The public-private key pair can be used in the signing/signature verification process to realize the authentication of the node members. For example, in a consensus algorithm with a signature, such as where nodeA1 belonging to subnet1 signs a message with its own maintained private key, the signed message may be broadcast in subnet1, and nodeB1, nodeC1 and nodeD1 may verify the received message with the public key of nodeA1 to confirm that the message received by itself was indeed from nodeA1 and was not tampered with.

In one embodiment, the node device may participate in creating the first blockchain subnetwork by performing a transaction prior to initiating the first blockchain subnetwork. For example, a creator of a first blockchain subnet (such as the aforementioned administrator) may initiate a transaction in the blockchain master network for creating the first blockchain subnet, such that the node device may locally create a subnet node of the first blockchain subnet in response to the transaction and deploy a system contract containing the first subnet identification on the subnet node. Wherein the transaction for creating the first blockchain subnet may include a transaction invoking a contract in which an address of the invoked smart contract, a method of invocation, and an incoming parameter may be specified. For example, the invoked contract may be the aforementioned creating contract or system contract, the invoked method may be a method of creating a blockchain subnet, and the incoming parameters may include the configuration information described above. The transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

wherein the from field is information of the initiator of the transaction, such as an Administrator, indicating that the initiator is an Administrator; the to field is the address of the called smart contract, for example, the smart contract may be a Subnet contract deployed in the blockchain main network, and the to field may specifically be the address of the Subnet contract; the method field is a called method, for example, the method for creating a blockchain Subnet in a Subnet contract may be AddSubnet (string), while string is a parameter in the AddSubnet () method, and in the above example, the value of the parameter may be represented by generation, which may specifically be configuration information specified by the creating party for the first blockchain Subnet to be created. The Subnet contract may be one of system contracts of a blockchain main network.

Taking the example of the node nodeA-nodeE on the main net0 in fig. 4 to execute the transaction of calling the AddSubnet () method in the Subnet contract, after the transaction passes the consensus, the nodeA-nodeE respectively execute the AddSubnet () method and transmit the configuration information to obtain the corresponding execution result.

The execution result of the contract may include the configuration information, and the execution result may be in a receipt of the transaction, and the receipt may include an event related to execution of the AddSubnet () method, that is, a networking event. Topic of networking events may contain predefined networking event identifications to distinguish from other events. For example, in an event related to execution of the AddSubnet () method, the content of the topic is a keyword subnet, and the keyword is distinguished from topic in an event generated by other methods. Then, the nodeA to nodeE can determine to monitor the event related to execution of the AddSubnet () method, that is, the networking event, in the case of monitoring the topic including the keyword subnet by monitoring the topic included in each event in the generated receipt. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the 1 st event is monitored, since the content of the topic contained is other, it is determined that the event is irrelevant to the AddSubnet () method; and when the 2 nd event is monitored, determining that the event is related to an AddSubNet () method because the content of the topic 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 first blockchain subnet, the content of the data field may include, for example:

{subnet1；

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

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

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

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

}

wherein, subnet1 is the network identification of the first blockchain subnet that it is desired to create. Each blockchain node in the blockchain master network may record network identifications 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 a Subnet contract as described above, for example, and may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, the nodes A-E can determine whether the subnet1 already exists according to the recorded network identifications of all the established blockchain subnets; if not, it is indicated that subnet1 is a new block chain subnet that currently needs to be created, and if so, it is indicated that subnet1 already exists. As can be seen, the node device may participate in creating the first blockchain subnetwork based on a subnetwork node identification maintained by the blockchain main network.

In addition to employing network identifications of the first blockchain subnets that are desired to be created, predefined new network identifications may also be employed that indicate the corresponding networking events for creating new first blockchain subnets. For example, the subnet1 may be replaced by a newsubnet, where the newsubnet is a predefined newly created network identifier, and when it is identified that the data field contains the newsubnet, the nodes a to e may determine that the event containing the newsubnet is a networking event, and need to create a new blockchain subnet.

In addition to the network identifier subnet1, the data field also includes content such as identity information of each node member in the first blockchain subnet. The node equipment of the main network node which is allocated to the first block chain sub-network can monitor and generate receipts of the transaction, and under the condition that the networking event is monitored and the content of the networking event indicates that the created main network node belongs to the node member, the node equipment of the first main network node is allocated to acquire configuration information or an creation block contained in the networking event. For example, in the case that it is determined that subnet1 is the first blockchain subnet that needs to be newly created, nodeA to nodeE further identifies the identity information of the node member contained in the data field to determine its own processing mode. For example, the nodeA to nodeD find that the data field contains identity information such as its own public key, IP address and port number, and assume that nodeA to nodeD are respectively disposed on the node devices A to D, taking nodeA and node device A as examples: the nodeA triggers the node equipment A, so that the node equipment A obtains the configuration information of the first blockchain subnet to be created from the data field based on the message mechanism and generates an creation block containing the configuration information, and the node equipment A locally deploys the nodeA1, and the created creation block is loaded by the nodeA1 to form 1 node member in the subnet 1. Similarly, nodeB will trigger node device B to generate nodeB1, nodeC will trigger node device C to generate nodeC1, and nodeD will trigger node device D to generate nodeD1. And the nodeE can find that the identity information contained in the data field is not matched with the nodeE, and the node equipment E can not generate an creation block according to the configuration information in the data field or generate a node in the subnet1 on the assumption that the nodeE is deployed on the node equipment E.

As described above, the main network node and the sub network node deployed in the same node device do not necessarily use the same identity information. Thus, in the above embodiment, the data field may contain identity information generated in advance for the nodeA1 to nodeD1, and is distinguished from the identity information of the nodeA to nodeD. Still taking nodeA and node device A as examples: if the node equipment A finds the identity information of the nodeA1 in the data field, generating an creation block, deploying the nodeA1 and loading the creation block by the nodeA1, or if the nodeA finds the identity information of the nodeA1 in the data field, the nodeA triggers the node equipment A to generate the creation block, deploying the nodeA1 and loading the creation block by the nodeA 1; the processing manners of nodeB to nodeD are similar and are not described in detail herein.

In addition to the configuration information, the execution result of the contract may also include an creation block. In other words, in addition to the configuration information contained in the data field, the generation block containing the configuration information can be directly generated in the process of executing the contract call, so that the generation block is contained in the data field, and for the nodeA-nodeD described above, the corresponding node devices A-D can directly obtain the generation block from the data field through a message mechanism without self-generation, so that the deployment efficiency of the nodeA 1-nodeD 1 can be improved.

Through the above process, the node device can complete the creation process of the first blockchain sub-network, and create a corresponding first database for the sub-network nodes belonging to the first blockchain sub-network deployed in the node device. The account data, the intelligent contract, the block data and the like corresponding to the subnet node belonging to the first block chain subnet can be stored in a first database corresponding to the node. For example, the node device may further create a next level blockchain Subnet on the basis of the first blockchain Subnet, wherein the node device may record Subnet information of the next level blockchain Subnet in a Subnet contract of the blockchain Subnet, which may be one of the system contracts of the first blockchain Subnet. In addition, the node device may record the subnet identifier of the first blockchain subnet in the above-mentioned mainnet0 contract, and the contract code corresponding to the subnet information of the next-level blockchain subnet and the subnet identifier of the first blockchain subnet in the mainnet0 contract may be:

Struct Subnetlnfo{

uint subnetld；

Bytes[]pubkeys；

SubnetState subnetState；

string genesis；

}

unit min_id

in the above code, subnetlnfo is an array corresponding to subnet information of the next-level blockchain subnet, and subnet information of each next-level blockchain subnet managed by the first blockchain subnet may be uniformly recorded in the array. Taking any one of the blockchain subnets as an example, the subnetId is a subnet identifier of the blockchain subnet, pubkeys is identity information such as public keys of all node members in the blockchain subnet, the subnetState is an operation state (an on state, a stop state, an invalid state and the like) of the blockchain subnet, and genesis is creation block information of the blockchain subnet. In addition, the min_id is a subnet identifier of the first blockchain subnet itself. Of course, with respect to each blockchain subnet managed by the first blockchain subnet, the first blockchain subnet is the main network, and the subnet identifier of each blockchain subnet may be extended on the basis of the min_id, so as to avoid collision with the network identifiers of other networks in the multi-level tree structure.

In practice, for any blockchain network in the multi-level tree structure, the network identifier of the blockchain network can be recorded in the system contract of the blockchain network. In addition, when the next-level blockchain sub-network is managed by itself, sub-network information of the managed next-level blockchain sub-network may be recorded in a system contract of itself. By taking the constraint of Subnet, each blockchain network with the next blockchain Subnet managed in the multi-level tree structure can record the Subnet information and the Subnet identification of the managed Subnet in the Subnet maintained by itself as shown in the code. The first subnet identifier in the node starting information read from the first database by the node device can be the first subnet identifier contained in the system contract recorded by the first database, and is not described again.

In an embodiment, the node device may read the node start information in response to a subnet start instruction. For example, a node member having enablement rights for a first blockchain subnet may initiate a transaction in a blockchain master network for enabling the first blockchain subnet such that the node device may participate in executing the transaction and monitor the subnet enablement instructions from a receipt resulting from the execution. It will be appreciated that the transaction for launching the first blockchain sub-network needs to be launched and executed if the blockchain main network has been launched, in other words, the node device may launch and execute the transaction for launching the first blockchain sub-network in the blockchain main network if the blockchain main network is in the launched state, and then monitor the corresponding sub-network launch instruction from the receipt of the transaction. Obviously, only if the transaction is successfully executed, the node device can also monitor the subnet starting instruction from the transaction receipt, so that the blockchain main network can effectively control the starting process of the first blockchain subnet.

The initiator for initiating the transaction of the first blockchain sub-network may be an administrator or a general user of the blockchain main network. Taking the first blockchain subnet as the subnet1 in fig. 4 as an example, if nodeA is the administrator and only allows the administrator to initiate the transaction to start the blockchain subnet, then the transaction to start the first blockchain subnet may be initiated by nodeA to mainnet 0; alternatively, nodeB-nodeE may request nodeA to initiate the above-described transaction to create a blockchain subnet to main 0. If nodeA is an administrator but allows a general user to initiate a transaction to create a blockchain subnet, then nodeA-nodeE may each initiate the transaction to the main net0 to initiate the first blockchain subnet as described above. Of course, the blockchain node that initiates the transaction that initiates the blockchain subnetwork, whether an administrator or an average user, does not necessarily participate in the blockchain subnetwork that is initiated, such as the transaction that initiates the blockchain subnetwork described above may be initiated by the nodeto the mainnet0, although the first blockchain subnetwork includes nodeA, nodeB, nodeC and nodeD, and not necessarily by nodeA-nodeD.

In addition, the same node device typically maintains multiple databases corresponding to network nodes in different blockchain networks, and the node device may read the above-mentioned node activation information in multiple manners. As an exemplary embodiment, the subnet start instruction may include description information of the first database, so that the node device may determine, from a plurality of databases maintained by itself, the first database corresponding to the first blockchain subnet according to the description information, and read the node start information from the database. Wherein the descriptive information may be determined by an initiator of a transaction that initiates the first blockchain subnet and recorded in the transaction. Specifically, the description information may be a database identifier of the first database, or an access address of a system contract of the first subnet identifier recorded in the first database, or the like. In this way, the node device may directly read the node start information of the first blockchain subnet from the first database, and further start the first blockchain subnet, under the condition that the first database is known but the first subnet identifier is not yet known.

As another exemplary embodiment, the node device may locally predefine a correspondence between the subnet identification and the database, for example, may generate a correspondence between the subnet identification of the created blockchain subnet and the database to which the subnet corresponds when the blockchain subnet is created. In this case, the subnet start instruction may include a first subnet identifier, so that the node device may determine a first database corresponding to the first subnet identifier (i.e., a database corresponding to the first blockchain subnet to be started) according to the correspondence, and read the node start information from the first database. Similarly, the first subnet identifier may be determined by the initiator that initiates the transaction of the first blockchain subnet and recorded in the transaction, which will not be described in detail. In this way, the initiator for initiating the transaction of the first blockchain subnet may designate, by the node initiation instruction, the first subnet identifier corresponding to the first blockchain subnet to be initiated to the node device, and the node device reads the node initiation information of the first blockchain subnet from the first database determined according to the identifier.

In another embodiment, because the first subnet identifier corresponding to the subnet is maintained in the first database corresponding to the first blockchain subnet, the node device does not need to obtain the identifier from the database corresponding to the blockchain main network, and therefore the node device can start the blockchain subnet even if the blockchain main network is not started yet. For example, the node device may read the above node activation information from the first database in the event that the main network node of the blockchain main network is not activated, so as to activate the first subnet node in the blockchain subnet according to the information. In this way, the blockchain subnetwork can be directly started without depending on the blockchain main network, so that the node device can pertinently start the first blockchain subnetwork according to the actual demand of the node member under the condition that the self resources (network resources, computing resources, storage resources and the like) are limited, thereby ensuring the actual demand of the node member as much as possible.

Step 504, starting the subnet node of the first blockchain subnet by loading the read creating block information, and respectively sending handshake messages containing the first subnet identification to the read node members to establish network connection.

Under the condition that the node starting information of the first block chain sub-network is read, the node equipment can start the sub-network node of the first block chain sub-network by loading the creating block information therein, and respectively send handshake messages containing the first sub-network identification to the node members of the first block chain sub-network so as to establish network connection between the sub-network node and the sub-network nodes respectively corresponding to the node members. It will be appreciated that the first blockchain subnetwork is started up to completion in the event that a network connection is successfully established between the various subnetwork nodes of the first blockchain subnetwork.

In the above scheme, the node device maintains a first database corresponding to the subnet node of the first blockchain subnet, and the first subnet identifier corresponding to the first blockchain subnet is recorded in the database. The node device can read the node starting information including the first subnet identifier from the database, further start the subnet node of the first block chain subnet according to the node starting information, and respectively send handshake messages containing the first subnet identifier to the node members of the first block chain subnet to establish network connection, thereby realizing the starting of the first block chain subnet. By the scheme, in the process of starting the first block chain sub-network, the node equipment can read data from the first database of the first block chain sub-network without acquiring the first sub-network identification from the database of the block chain main network, so that the starting flow of the node equipment is simplified, and the efficient starting of the first block chain sub-network is facilitated.

In an embodiment, in order to facilitate management of each blockchain subnet corresponding to itself, the blockchain main network may maintain a subnet management list, so that the node device may read a database corresponding to the main network node maintained by itself and query the subnet management list from the database.

The subnet management list may be used to record subnet information of the blockchain subnets under the blockchain master management, including information such as identity information (including an IP address and a port number of the node device where the node device is located), an operation state, plug-in configuration information, and the like, and of course, also may record subnet identifiers of each blockchain subnet (that is, subnet identifiers of any blockchain subnet are recorded not only in a database corresponding to the subnet but also in a database of the blockchain master network that manages the subnet). The running state of the first block chain sub-network, the plug-in configuration information and the like can be configured by the block chain main network, for example, the running state of the block chain sub-network, the plug-in configuration information and the like are updated so as to realize the management of the first block chain sub-network. The Subnet management list of the blockchain master network may be recorded in a system contract of the blockchain master network, such as a Subnet contract of the blockchain master network. Based on this, the node device may query a subnet management list maintained by the blockchain main network to determine an operation state of the first blockchain subnet, and start a subnet node of the first blockchain subnet if the operation state of the first blockchain subnet is an on state.

Taking main 0 as a blockchain main network and subnet1 as a first blockchain sub network in fig. 4 as an example, the node device a maintains databases corresponding to nodeA and nodeA1 respectively, wherein the database corresponding to nodeA records the running state of the subnet1 to which nodeA1 belongs. Thus, the node device may read the running state of the subnet1 from the database corresponding to the nodeA: if the running state of the subnet1 is an on state, the normal start of the subnet1 is indicated, and at the moment, the start of the subnet node of the first blockchain subnet can be started; otherwise, if the running state of the subnet1 is in the off or stop state, it indicates that the subnet1 cannot be started normally, at this time, the subnet node of the first blockchain subnet may be stopped from being started, and start failure information may also be sent and/or running logs of the blockchain subnet may be recorded, which will not be described again.

Each block link point deployed in the node device in the specification is essentially a different block chain instance running on the node device and formed by respective plug-in modules, each node device is deployed with a corresponding plug-in manager for managing plug-in modules on which each block chain node (including a main network node and a sub network node) deployed on the corresponding node device depends in running, that is, plug-in modules for forming each block chain node. Based on this, the node device may start a plug-in module for constituting a subnet node of the first blockchain subnet through a plug-in manager corresponding to the subnet node of the first blockchain subnet.

In one case, only one shared plugin manager is deployed in the node device, and is used for managing plugin modules corresponding to all block chain link points deployed in the node device, that is, the shared plugin manager corresponds to all block chain nodes deployed on the node device. In particular, the shared plugin manager may maintain plugin configuration information for each blockchain node deployed locally. Since the plug-in modules of different blockchain nodes in the same blockchain network are typically identical, the plug-in configuration information of a blockchain node is typically identical to the plug-in configuration information of the blockchain network to which the blockchain node belongs, although the plug-in modules of different blockchain nodes in the same blockchain network may also be different. The plug-in configuration information of a blockchain node is used to indicate a specific plug-in module that forms the blockchain node, and may include: service network plug-ins, service plug-ins, P2P (peer-to-peer) plug-ins, blockchain subnet management plug-ins, cache (Cache memory) plug-ins, authentication plug-ins, event management plug-ins, consensus plug-ins, synchronization plug-ins, execution plug-ins, blockchain plug-ins, storage plug-ins, and the like, which are not limiting in this specification.

In another case, a node device may separately allocate a corresponding independent plugin manager according to each blockchain node deployed by the node device, for example, an independent plugin manager may be allocated to be separately applied to the subnet nodes that form the first blockchain subnet. Specifically, any individual plug-in manager may only maintain plug-in configuration information for the corresponding blockchain node, and is specifically responsible for managing plug-in modules for the corresponding blockchain node, e.g., turning on, off, replacing plug-in modules for the corresponding blockchain node, etc.

The plug-in manager deployed in the node device can obtain plug-in configuration information of the first blockchain node by reading the subnet management list.

Different blockchain nodes on a node device may depend on the same plug-in module at runtime, and such plug-ins are shared plug-ins. For example, the block link points currently in the on state on the node device a include nodeA and nodeA1, and the plug-in modules for forming nodeA include plug-in 1.0, plug-in 2.0, plug-in 3.0 and plug-in 4.0, and the plug-in modules for forming nodeA1 include plug-in 1.1, plug-in 2.0, plug-in 3.1, plug-in 4.1 and plug-in 5.1, where, although they are of the same type, have the same plug-in function, but still two different plug-in modules are respectively embedded in different block chain nodes, and do not share information with each other, and essentially belong to different plug-in modules. Whereas the plugin 2.0 is relied on by both nodeA and nodeA1, so plugin modules commonly used by two or more blockchain nodes at the same time, such as plugin 2.0, belong to a shared plugin under node device a, whereas plugin modules solely relied on by only one blockchain node belong to independent plugins under node device a, for example, plugins other than plugin 2.0 belong to independent plugins.

The plug-in manager may maintain dependencies between plug-in modules. If the normal operation of plug-in a must require plug-in B to have been operated, plug-in a can be considered to have a dependency relationship with plug-in B and plug-in a depends on plug-in B. When the node device starts the plug-in modules for the subnet nodes forming the first block chain subnet according to the node starting information, each plug-in module can be started in sequence according to the dependency relationship among each plug-in module forming the node. For example, in the case where the plug-in modules for constituting nodeA1 include plug-ins 1.1, 2.0, 3.1, 4.1, and 5.1, and plug-ins 4.1 and 5.1 depend on plug-ins 3.1, 3.1 depend on plug-ins 1.1 and 2.0, the node device may first boot up plug-ins 1.1 and 2.0, then boot up plug-ins 3.1, and finally boot up plug-ins 4.1 and 5.1.

The plug-in manager deployed on the node device can maintain a plug-in information attribute list according to plug-in configuration information and running state of each locally deployed blockchain node, and the plug-in information attribute list is used for marking attribute information of all plug-in modules, including a shared plug-in or an independent plug-in, dependency relationship with other plug-in modules and the like. When the plugin manager reads the subnet management list and finds that the blockchain subnet with the current running state being the on state only has the main net0 and the subnet1, the plugin information attribute list can be updated in real time, so that plugin configuration information of nodeA and nodeA1 corresponding to the main net0 and the subnet1 deployed locally can be further searched, and further, plugin modules commonly used by nodeA and nodeA1 can be obtained by comparison and are plugins 2.0, and plugin 2.0 in the plugin information attribute list is marked as a shared plugin. When the subnet1 is closed, the plug-in manager reads the subnet management list again to find that the blockchain subnet with the running state being the open state is only a main net0, then only the obtained plug-in configuration information of nodeA can be searched, no shared plug-in exists at this time, and then the plug-in 2.0 in the plug-in information attribute list can be changed from the shared plug-in to an independent plug-in. Besides obtaining the plug-in configuration information and the running state of each locally deployed subnet node through the subnet information of each block chain subnet in the subnet management list, the plug-in manager can also independently maintain the plug-in configuration information and the running state of the locally deployed main network node and each subnet node, and automatically update the maintained running state and other information after the corresponding subnet node is started, so that the attribute information of each plug-in module in the plug-in information attribute list can be updated more timely and accurately.

Further, the node device may activate a plug-in module for constructing any blockchain node in the first blockchain subnetwork by:

and determining the plug-in description information of each plug-in module used for forming any blockchain node and the operation requirement of each plug-in module. In this embodiment, the plug-in description information and the operation requirement of each plug-in module for forming a blockchain node may be determined by querying a plug-in information attribute list corresponding to the node, where the plug-in description information may include at least one of a plug-in type, a plug-in name, and a plug-in function, and is used to point to a specific plug-in module.

Furthermore, if the running requirement of any plug-in module is shared running, if there is an opened plug-in module matching with the plug-in description information of the plug-in module, and the running mode of the opened plug-in module is a sharing mode, the node device may share the opened plug-in module to any blockchain node. The operation requirement of each plug-in module is defined in the plug-in configuration information corresponding to any blockchain node, and if the operation requirement of any plug-in module in the plug-in configuration information is shared operation, the operation requirement of any plug-in module is required to be operated in a shared mode. And if the first node device has found an opened plug-in module corresponding to the plug-in description information of any plug-in module through the plug-in information attribute list before starting any plug-in module, the opened plug-in module can be further shared to the blockchain node to which any plug-in module belongs under the condition that the operation mode of the opened plug-in module is determined to be a sharing mode.

Or under the condition that the operation requirement of any plug-in module is shared operation, if the plug-in module which is matched with the plug-in description information and has the operation mode of the shared mode does not exist, the node equipment can start any plug-in module. If the operation requirement of any one of the plug-in modules in the plug-in configuration information is shared operation, the requirement that any one of the plug-in modules is operated in a shared mode is described. And if, before starting any plug-in module, the first node device finds out that the plug-in module corresponding to the plug-in description information of the any plug-in module does not exist through the plug-in information attribute list, or the operation mode of the plug-in module is not the sharing mode although the plug-in module exists, then it is considered that the plug-in module which is matched with the plug-in description information and has the operation mode of the sharing mode does not exist, so that the any plug-in module needs to be started. Meanwhile, when the plug-in module corresponding to the plug-in description information is started, an operation mode of the started plug-in module can be set based on the operation requirement, for example, because the sharing requirement of any plug-in module is shared operation. Therefore, the running mode of any plug-in module after starting can be set to be a sharing mode, so that the block chain node which needs to use the any plug-in module subsequently can share the any plug-in module to the block chain node which starts subsequently when starting.

Or, in the case that the operation requirement of any one of the plug-in modules is independent operation, the node device may start any one of the plug-in modules. If the operation requirement of any one of the plug-in modules in the plug-in configuration information is independent operation, the requirement that the any one of the plug-in modules operates in the exclusive mode is indicated, so that any one of the plug-in modules can be directly started and the operation mode of the plug-in modules can be set to the exclusive mode, so that the block chain node of any one of the plug-in modules which is required to be used subsequently cannot share any one of the plug-in modules to the block chain node of the subsequent start-up when the plug-in modules are started, the operation mode of the exclusive mode of the plug-in modules is met, and the operation requirement that any one of the plug-in modules independently operates in the plug-in configuration information is ensured.

Under the above circumstances, the operation requirement of each plug-in module is defined in the plug-in configuration information corresponding to any blockchain node, and each plug-in configuration information corresponding to different blockchain nodes may be different, so different plug-in sharing strategies may be allocated to different blockchain nodes, and the differentiated management of different blockchain nodes may flexibly meet various actual requirements of users. In another case, the operation requirement of each plug-in module is global predefined information, so that the plug-in configuration information corresponding to any blockchain node can be used for avoiding recording the operation requirement of each plug-in module, and the plug-in configurator maintains the operation requirement of each plug-in module according to different plug-in description information.

Under the condition that the node equipment starts the subnet node of the first block chain subnet by loading the read generation block information, handshake messages can be respectively sent to the read (other than the node members corresponding to the subnet node deployed in the node equipment) node members to establish network connection, and the handshake messages can contain the first subnet identifier read in the process so that the other node members can confirm which block chain subnet to start according to the identifier. The specific transceiving process of the handshake message can be referred to the description in the related art, and will not be repeated here.

It will be appreciated that the foregoing is illustrative from the perspective of a node device in which any of the first blockchain subnetwork nodes is deployed. The node equipment deployed with each subnet node in the first block chain subnet can respectively start the corresponding subnet node through the mode, and establish network connection with each other through the handshake message. After the network connection is established by each subnet node, each node device completes the starting process of the first block chain subnet.

In one embodiment, a new node (hereinafter referred to as a node to be added to the subnet) may be added to the first blockchain subnet after startup. For example, the target node device for deploying the subnet node to be added may initiate a network access request to the node device deployed with any subnet node in any first blockchain subnet in a link-down manner, where the request may include network information such as an IP address and a port number of the target node device, and may also include identity information of a node member corresponding to the subnet node to be added. In response to the request, the node device may verify the identity information of the node member, and of course, in the case that the subnet node deployed in the node device corresponds to the normal user of the first blockchain subnet, the node device may send the identity information to the node device corresponding to the administrator of the first blockchain subnet, so that the device performs identity verification; alternatively, an authentication transaction including the above-mentioned identity information may be initiated in the first blockchain subnet to be authenticated by each subnet node in the first blockchain subnet, respectively.

In the case that the authentication is passed, the node device may perform a transaction initiated at the first blockchain subnet for acquiring the generation block information of the first blockchain subnet, and monitor the generation block information of the first blockchain subnet from a receipt of the transaction, where the generation block information includes a first subnet identification of the first blockchain subnet. Specifically, the node device may read the aforementioned creation block information in response to the transaction in a first database corresponding to the first blockchain Subnet maintained locally, where the aforementioned creation block information may include configuration information such as the running state of the first blockchain Subnet itself and the next blockchain Subnet managed thereby, system contracts (such as the aforementioned Subnet contracts, node contracts for recording node member information of the first blockchain Subnet, etc.) deployed in the first blockchain Subnet, and/or account information of accounts (external accounts, contract accounts, etc.) created in the first blockchain Subnet. In addition, the transaction for acquiring the generation block information of the first blockchain subnet may be a local transaction initiated by the node and requiring no consensus, or may be a blockchain transaction initiated by an administrator of the first blockchain subnet and requiring consensus, which is not limited in this specification.

Under the condition that the generation block information is acquired, the node equipment can send the generation block information to the target node equipment in a link-down mode so that the target node equipment starts the to-be-added subnet node by loading the generation block information. Further, the node device may perform a transaction for newly adding a subnet node initiated at the first blockchain subnet, establishing a network connection between a subnet node of the locally deployed first blockchain subnet and the subnet node to be added.

After joining the first blockchain subnetwork in the manner described above, the blockchain node to be joined becomes a blockchain node similar to an existing blockchain node in the first blockchain subnetwork (e.g., a blockchain node deployed in the node device). It can be appreciated that, because the first blockchain identifier is recorded in the first database, the target node device can directly obtain the created block information containing the identifier from the node device, and the node device does not need to interact with the blockchain main network or obtain data from the database corresponding to the blockchain main network in the process of adding the to-be-added subnet node to the first blockchain sub-network, so that the process of adding the to-be-added subnet node to the first blockchain sub-network is independent of the blockchain main network. From the perspective of the target node device, even if the local node device does not deploy any blockchain node in the blockchain main network, the node device can still acquire the generated block information of the first blockchain sub-network through interaction with the node device, so as to load the sub-network node for realizing the first blockchain sub-network.

In another embodiment, a new, next level of blockchain subnetwork (hereinafter referred to as a second blockchain subnetwork) may also be created on the basis of the first blockchain subnetwork after start-up. For example, the node device may, in response to a transaction initiated in a first blockchain subnet to create a second blockchain subnet, locally create a subnet node in the second blockchain subnet and deploy a system contract on the subnet node containing a second subnet identification corresponding to the second blockchain subnet; the second subnet mark is generated after the value of the first subnet mark is adjusted according to a predefined adjustment rule. The process of locally creating the subnet node in the second blockchain subnet by the node device is similar to the process of locally creating the subnet node in the first blockchain subnet in response to the transaction for creating the first blockchain subnet initiated in the blockchain main network, and the description of the foregoing embodiments will be omitted herein.

It should be noted that, the second subnet identifier corresponding to the second blockchain subnet may be generated according to the first subnet identifier, for example, generated by adjusting the value of the first subnet identifier according to a predefined adjustment rule. Wherein the adjustment rule may be incremented based on the first subnet identification and indicates the network level of the second blockchain subnet using "." as the separator. For example, in the case where the first blockchain subnetwork is subnet1 shown in fig. 4, node device a (with blockchain nodes nodeA and nodeA1 deployed) may create nodeA1.1 locally, thereby creating subnet1.1 on a subnet1 basis. The second subnet of the newly created subnet1 is identified as "1.1", and the first subnet of the first blockchain subnet is identified as "1", where the second subnet identification "1.1" is generated based on the first subnet identification "1". Of course, after creating the subnet1.1, the new second blockchain subnetwork subnet1.2 and subnet1.3 … can be further created on the basis of the subnet 1; alternatively, in the case that the first blockchain subnetwork is subnetwork 2, a second blockchain subnetwork 2.1, subnetwork 2.2 … can be generated on the basis of the subnetwork; on the basis of the second blockchain subnetwork 1.1, a third blockchain subnetwork 1.1.1, subnetwork 1.1.2, subnetwork 1.1.3, etc. (not shown in fig. 4) may be further created, and details thereof will not be repeated.

By the method, after any block chain sub-network in the multi-level tree structure is started, the sub-network identification of the next-level block chain sub-network created on the basis of the block chain sub-network is obtained by adjusting the sub-network identification of the block chain sub-network according to the predefined adjustment rule, so that the sub-network identification of the newly created block chain sub-network is prevented from being repeated (namely the same) as the network identification of the existing block chain network in the multi-level tree structure, the global uniqueness of the network identification of each block chain network in the multi-level tree structure is effectively realized, and the management efficiency of the block chain network is improved.

Fig. 6 is a schematic diagram of an apparatus according to an exemplary embodiment. Referring to fig. 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile storage 610, although other hardware required by other services is possible. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 602 reading a corresponding computer program from the non-volatile memory 610 into the memory 608 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

Fig. 7 is a block diagram of a block chain subnet enabling device according to an exemplary embodiment. Referring to fig. 7, the device may be applied to the apparatus shown in fig. 6 to implement the technical solution of the present specification. The apparatus for starting the blockchain subnetwork is applied to a node device, and a main network node belonging to the blockchain main network and a subnetwork node belonging to a first blockchain subnetwork are deployed in the node device, wherein the first blockchain subnetwork is managed by the blockchain main network, and the apparatus comprises:

an information reading unit 701, configured to read node start information from a first database maintained by the node device, where the node start information includes a first subnet identifier corresponding to a first blockchain subnet, generation block information of the first blockchain subnet, and node members, and the first database corresponds to a subnet node of the first blockchain subnet;

the node starting unit 702 is configured to start a subnet node of the first blockchain subnet by loading the read creation block information, and send handshake messages including the first subnet identifier to the read node members respectively to establish network connection.

Optionally, the method further comprises:

a first node creation unit 703 for creating a subnet node of the first blockchain subnet locally and deploying a system contract including the first subnet identification on the subnet node in response to a transaction for creating the first blockchain subnet initiated in the blockchain main network;

Wherein the first subnet identification in the node activation information comprises: a first subnet identification contained in the system contract of the first database record.

Optionally, the information reading unit 701 is further configured to:

responding to a subnet starting instruction containing description information of a first database, and reading the node starting information from the first database; or,

and responding to a subnet starting instruction containing the first subnet identification, determining a first database corresponding to the first subnet identification according to the corresponding relation between the predefined subnet identification and the database, and reading the node starting information from the first database.

Optionally, the method further comprises:

and the instruction monitoring unit 704 is used for executing the transaction initiated in the blockchain main network and used for starting the first blockchain sub-network, and monitoring the sub-network starting instruction from the receipt of the transaction.

Optionally, the information reading unit 701 is further configured to:

and under the condition that the main network node of the block chain main network is not started, reading node starting information from a first database.

Optionally, the node activation unit 702 is further configured to:

inquiring a subnet management list maintained by the block chain main network to determine the running state of a first block chain subnet;

And starting the subnet node of the first block chain subnet under the condition that the running state of the first block chain subnet is in an on state.

Optionally, the node activation unit 702 is further configured to:

and reading a database corresponding to the main network node maintained by the node equipment, and inquiring the subnet management list from the database.

Optionally, the node activation unit 702 is further configured to:

starting a plug-in module for forming the subnet node of the first block chain subnet through a plug-in manager corresponding to the subnet node of the first block chain subnet;

wherein the plug-in manager is an independent plug-in manager that is separately applied to the subnet nodes constituting the first blockchain subnet; or the plug-in manager is a shared plug-in manager corresponding to all block link points deployed on the node equipment.

Optionally, the node activation unit 702 is further configured to:

determining plug-in description information of each plug-in module and operation requirement of each plug-in module for forming a subnet node of the first block chain subnet;

if the running requirement of any plug-in module is shared running, if an opened plug-in module matched with the plug-in description information of any plug-in module exists and the running mode of the opened plug-in module is a sharing mode, the opened plug-in module is shared to a subnet node of a first blockchain subnet;

Under the condition that the operation requirement of any plug-in module is shared operation, if the opened plug-in module which is matched with the plug-in description information and has the operation mode of the shared mode does not exist, starting any plug-in module;

and starting any plug-in module under the condition that the operation requirement of any plug-in module is independent operation.

Optionally, the method further comprises:

a second node creation unit 705 for creating a subnet node in the second blockchain subnet locally in response to a transaction for creating the second blockchain subnet initiated in the first blockchain subnet, and deploying a system contract containing a second subnet identification corresponding to the second blockchain subnet on the subnet node;

the second subnet mark is generated after the value of the first subnet mark is adjusted according to a predefined adjustment rule.

Optionally, the method further comprises:

an information monitoring unit 706, configured to perform a transaction initiated on the first blockchain subnet and used to acquire generation block information of the first blockchain subnet, and monitor, from a receipt of the transaction, the generation block information of the first blockchain subnet, where the generation block information includes a first subnet identifier;

An information sending unit 707, configured to send the creation block information to a target node device for deploying a node to be added to a subnet, so that the target node device starts the node to be added to the subnet by loading the creation block information;

a transaction execution unit 708, configured to execute a transaction for adding a subnet node initiated at the first blockchain subnet, and establish a network connection between a subnet node of the locally deployed first blockchain subnet and the subnet node to be added.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, 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 functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.

It will be appreciated by those skilled in the art that 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 flowchart illustrations and/or block diagrams, and combinations of flows 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 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.

The 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 volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

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 storage media for a computer 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, read only 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 or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

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 one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present 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 are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments 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 or 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, these 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 of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A method of starting a blockchain subnetwork, applied to a node device, in which a main network node belonging to a blockchain main network and a subnetwork node belonging to a first blockchain subnetwork, the first blockchain subnetwork being managed by the blockchain main network, are deployed, the method comprising:

2. The method of claim 1, further comprising:

in response to a transaction initiated in the blockchain master network for creating a first blockchain subnet, locally creating a subnet node of the first blockchain subnet and deploying a system contract on the subnet node containing a first subnet identification;

3. The method of claim 2, the reading node activation information from a first database maintained by the node device, comprising:

4. A method according to claim 3, further comprising:

executing a transaction initiated in the blockchain main network for initiating the first blockchain subnet, and monitoring the subnet initiation instruction from a receipt of the transaction.

5. The method of claim 1, reading node activation information from a first database, comprising:

6. The method of claim 1, the initiating a subnet node of a first blockchain subnet, comprising:

7. The method of claim 6, the querying a subnet management list maintained by the blockchain master network, comprising:

8. The method of claim 1, the initiating a subnet node of a first blockchain subnet, comprising:

9. The method of claim 8, the enabling a plug-in module for a subnet node that forms a first blockchain subnet, comprising:

10. The method of claim 1, further comprising:

in response to a transaction initiated in the first blockchain subnet for creating a second blockchain subnet, locally creating a subnet node in the second blockchain subnet and deploying a system contract on the subnet node containing a second subnet identification corresponding to the second blockchain subnet;

11. The method of claim 1, further comprising:

executing a transaction initiated at the first blockchain subnet for acquiring the generation block information of the first blockchain subnet, and monitoring the generation block information of the first blockchain subnet from a receipt of the transaction, wherein the generation block information comprises a first subnet identifier;

transmitting the creation block information to target node equipment for deploying the to-be-added subnet node, so that the target node equipment starts the to-be-added subnet node by loading the creation block information;

and executing a transaction initiated at the first blockchain subnet for the newly added subnet node, and establishing network connection between the subnet node of the locally deployed first blockchain subnet and the subnet node to be added.

12. A blockchain subnetwork activation device for use in a node device having deployed therein a main network node belonging to a blockchain main network and a subnetwork node belonging to a first blockchain subnetwork managed by the blockchain main network, the device comprising:

13. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any of claims 1-11 by executing the executable instructions.

14. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-11.