CN113067895A

CN113067895A - Method for building block chain sub-network and block chain system

Info

Publication number: CN113067895A
Application number: CN202110611542.2A
Authority: CN
Inventors: 陶友贤; 夏凝
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2021-07-02
Anticipated expiration: 2041-06-02
Also published as: CN113067895B

Abstract

One or more embodiments of the present specification provide a method of building a blockchain subnet and a blockchain system; the method can comprise the following steps: each block chain link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information and consensus type information of each node member participating in establishing the block chain sub-network, and the consensus type information is used for indicating the consensus type of the corresponding block chain link point of the corresponding node member in the block chain sub-network; each block link point in the block chain main network respectively executes the transaction to reveal the configuration information; and when the configuration information contains identity information of a first node member corresponding to the first block link point, the node equipment deploying the first block link node starts a second block link node belonging to the block link subnet based on the creation block containing the configuration information.

Description

Method for building block chain sub-network and block chain system

Technical Field

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

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Nodes in the blockchain network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. When a new blockchain network is established on the basis of an existing blockchain network system, the newly established blockchain network can completely reuse various attributes of the existing blockchain network, and the complete isomorphism among the blockchain networks cannot meet the actual requirements of users, so that the networking flexibility is lacked.

Disclosure of Invention

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

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

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

each block chain link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information and consensus type information of each node member participating in establishing the block chain sub-network, and the consensus type information is used for indicating the consensus type of the corresponding block chain link point of the corresponding node member in the block chain sub-network;

each block link point in the block chain main network respectively executes the transaction to reveal the configuration information; when the configuration information contains identity information of a first node member corresponding to the first block link point, the node device deploying the first block link node starts a second block link node belonging to the block link subnet based on the creation block containing the configuration information.

In accordance with a second aspect of one or more embodiments of the present specification, there is provided a method of building a blockchain subnet, comprising:

a first block chain link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information and consensus type information of each node member participating in establishing the block chain sub-network, and the consensus type information is used for indicating the consensus type of the corresponding block chain link point of the corresponding node member in the block chain sub-network;

the first block link point executes the transaction to reveal the configuration information;

and when the configuration information contains identity information of a first node member corresponding to the first block link point, the node equipment deploying the first block link node starts a second block link node belonging to the block link subnet based on the creation block containing the configuration information.

According to a third aspect of one or more embodiments herein, there is provided a blockchain system, comprising:

each block chain node in the block chain main network is used for respectively acquiring and executing a transaction for building a block chain sub-network so as to reveal configuration information of the block chain sub-network, wherein the configuration information comprises identity information and consensus type information of each node member participating in building the block chain sub-network, and the consensus type information is used for indicating the consensus type of the corresponding block chain link point of the corresponding node member in the block chain sub-network;

and the node equipment is used for starting a second blockchain node belonging to the blockchain sub-network based on the creation block containing the configuration information when the configuration information contains the identity information of the node member corresponding to the blockchain link point deployed on the node equipment.

Drawings

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

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

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

Fig. 4 is a flowchart of a method for building a blockchain subnet provided by an exemplary embodiment.

Fig. 5 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

Fig. 6 is a flowchart of another method for building a blockchain subnet provided by an example embodiment.

Fig. 7 is a schematic structural diagram of a blockchain system according to an exemplary embodiment.

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

Detailed Description

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

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

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

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

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

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

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

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

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

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

Event：

[topic][data]

......

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

In the event mechanism, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

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

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

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

step 402, each block chain link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction includes configuration information of the block chain sub-network, the configuration information includes identity information and consensus type information of each node member participating in establishing the block chain sub-network, and the consensus type information is used for indicating a consensus type of a corresponding block chain link point of a corresponding node member in the block chain sub-network.

The transaction for establishing the blockchain sub-network can be initiated by an administrator of the blockchain main network, that is, the administrator is only allowed to establish the blockchain sub-network on the basis of the blockchain main network, and the establishment permission of the blockchain sub-network is prevented from being opened to a common user, so that the security problem caused by the establishment permission can be prevented. In some cases, a common user of the blockchain main network may also be allowed to initiate a transaction for building the blockchain sub-network, so as to meet networking requirements of the common user, and the common user can still quickly build the blockchain sub-network under the condition that an administrator is not convenient to initiate the transaction.

For example, as shown in fig. 5, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Suppose that the node members respectively corresponding to nodeA, nodeB, nodeC and nodeD wish to construct a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if the node E is an administrator but allows a common user to initiate the transaction of building the blockchain sub-network, the node A-node E can initiate the transaction of building the blockchain sub-network to the subnet 0. Of course, no matter an administrator or an ordinary user, the node members corresponding to the blockchain link points initiating the transaction for building the blockchain subnet do not necessarily participate in the built blockchain subnet, for example, although the blockchain subnet is finally built by the node members respectively corresponding to nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated to subnet0 by nodeE, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the block chain sub-network is established on the basis of the block chain main network, it is easy to understand that a logical hierarchical relationship exists between the block chain sub-network and the block chain main network, and the hierarchical relationship represents the establishment relationship between the block chain networks. For example, when a blockchain subnet1 is constructed on subnet0 shown in fig. 5, subnet0 may be considered to be at the first level and subnet1 may be considered to be at the second level. In one case, the blockchain main network in this specification may be an underlying blockchain network, that is, the blockchain main network is not a blockchain sub-network constructed on the basis of other blockchain networks, for example, the subnet0 in fig. 5 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification may also be a subnet of another blockchain network, for example, another blockchain subnet may be further configured on the basis of the subnet1 in fig. 5, and at this time, the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect that the subnet1 belongs to the blockchain subnet created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

In step 404, each block link node in the block chain master network performs the transaction to reveal the configuration information.

Step 406, when the configuration information includes identity information of a first node member corresponding to the first block link point, the node device that deploys the first block link node starts a second block link node belonging to the block link subnet based on the creation block that includes the configuration information.

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

The transaction for establishing the blockchain subnet is not necessarily executed after being sent to the blockchain master network, and before the transaction is executed, each blockchain node in the blockchain master network may compare the identity information of each node member included in the configuration information with a locally maintained legal identity information list, and execute the transaction under the condition that the identity information of each node member is determined to be included in the legal identity information list, where the content of the legal identity information list includes at least one of: identity information of each blockchain node in a blockchain main network and identity information of each blockchain node in a blockchain sub-network. By performing the preliminary detection on the transaction configuration information, the transaction can be avoided from being executed when the configuration information is determined to contain the illegal identity information, so that the computing resources and the time resources of the blockchain system are saved, wherein the illegal identity information indicates that the configuration information is not the node member on the blockchain main network or the node identity of the node member in the predefined blockchain sub-network, that is, only the node member on the blockchain main network or the node member on the predefined blockchain sub-network is allowed to participate in building the blockchain sub-network. The preliminary detection process described above may occur prior to the consensus on the transaction, where the transaction is discarded directly without participating in the consensus mechanism; or may occur after a consensus mechanism for the transaction, in which case the transaction may be tagged with an illegal tag and not executed by each tile link point; still alternatively, it may occur during a pre-processing phase of transaction execution where, although the transaction has been executed, it is detected as being illegal and thus immediately forgoes execution of subsequent processes and records the results and reasons of transaction execution failure in the receipt of transaction execution.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including identity information of the node members participating in the building of the blockchain subnet in the configuration information, it can be specified to which node members the built blockchain subnet corresponds. Except for the identity information of each node member which is appointed to participate in the building of the block chain sub-network, the configuration information also carries the common identification type information which corresponds to each node member corresponding to each block chain link point in the block chain main network in the block chain sub-network, so that the common identification type of each block chain node in the newly built block chain sub-network is controlled, wherein when the common identification type information is a first value, the configuration information is used for indicating the corresponding block chain link point to become the common identification node; and when the consensus type information is a second value, indicating that the corresponding block link point becomes a non-consensus node. After the networking of the blockchain subnet is completed, the blockchain link points with different consensus types need to fulfill different node functions, for example, the consensus nodes need to participate in a consensus mechanism, transaction execution and block synchronization, while the non-consensus nodes do not need to participate in the consensus mechanism and are only used for executing the block synchronization, and have observer attributes of passively received information in the blockchain. In some cases, in a case where the consensus type information in the configuration information included in the transaction is undefined, for example, when only the identity information of the first node member is carried in the configuration information and the consensus type information of the corresponding blockchain link point of the first node member in the blockchain subnet is not carried, the consensus type of the corresponding second blockchain node of the first node member in the blockchain subnet may be made to inherit the consensus type of the first blockchain node.

Taking the example shown in fig. 5 as an example, assuming that node members corresponding to nodeA, nodeB, nodeC and nodeD respectively wish to construct a blockchain subnet, and specify that the blockchain link point to be created of the node members corresponding to nodeA, nodeB and nodeC becomes a common node, and the blockchain link point to be created of the node member corresponding to nodeD becomes a non-common node, the configuration information included in the transaction initiated by the administrator for constructing the blockchain subnet will include the identity information of the node members corresponding to nodeA, nodeB, nodeC and nodeD respectively and the common type information of the corresponding blockchain node to be created, for example, the configuration information may be represented as "6 bd 7-1; 1ba 8-1; 1b4 b-1; aecc-0 ", wherein" 6bd7 "in" 6bd7-1 "is the node public key corresponding to nodeA and represents the identity information of the node member corresponding to nodeA, and" 1 "is the consensus type information of the blockchain node to be created of the node member corresponding to nodeA and is used for indicating that the blockchain node to be created becomes a consensus node, thereby generating a blockchain subnet1 with nodeA1, nodeB1 and nodeC1 as consensus nodes and nodeD1 as non-consensus nodes. For another example, when nodeA-nodeD are all consensus nodes in subnet0, the configuration information carried by the transaction can also be represented as "6 bd 7; 1ba 8; 1b4 b-2; aebc-0 ", the consensus type information of the to-be-created blockchain nodes of the node members corresponding to the nodeA and the nodeB is null, and the consensus type information of the to-be-created blockchain nodes of the node members corresponding to the nodeC is" 2 ", so that the consensus type information corresponding to the nodeA-nodeC is undefined, and the newly-created nodeA1, nodeB1 and nodeC1 inherit the consensus types of the nodeA, nodeB and nodeC, so that the blockchain subnet1 with the nodeA1, nodeB1 and nodeC1 as the consensus nodes and the nodeD1 as the non-consensus nodes can be generated.

The identity information of the node member may include information that can represent the identity of the node member, such as a subnet node public key, a master node number, a node device IP address, a node device port number, and a node device number, which is not limited in this specification. Taking a public key as an example, each block chain node has one or more corresponding public and private key pairs, and the block chain node holds the private key and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding block chain node can be represented by the public key, and the identity of a node member corresponding to the block chain node can also be represented by the public key. Therefore, for the node members who wish to participate in building the blockchain sub-network, the public keys of the blockchain nodes corresponding to the node members on the blockchain main network can be added to the transaction of building the blockchain sub-network to serve as the identity information of the node members. The public and private key pair described above may be used in the process of signature verification. For example, in a signed consensus algorithm, such as the sub net1, the above-mentioned nodeA1 signs a message with its own private key, and broadcasts the signed message in the sub net1, while nodeB1, nodeC1 and nodeD1 can verify that the received message is signed with the public key of nodeA1 to confirm that the received message is indeed from nodeA1 and has not been tampered with. In addition, the first block link point and the second block link point may use the same identity information, taking a public key as the identity information as an example, the subnet node public key of the first block link node corresponding to the block chain master network may be multiplexed with the master network node public key of the second block link node corresponding to the block chain subnet, or the first block link point and the second block link point may also use different identity information, for example, the subnet node public key of the first block link node corresponding to the block chain master network may be different from the master network node public key of the second block link node corresponding to the block chain subnet.

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

The first blockchain node and the second blockchain node are logically divided blockchain link points, and from the perspective of physical devices, the node device which is equivalent to the first blockchain node and the second blockchain node is deployed to participate in both the blockchain main network and the blockchain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, the identity system and the member consensus types of the two blockchain networks are also independent from each other, for example, even though the first blockchain node and the second blockchain node may use the same public key, the first blockchain node and the second blockchain node should be regarded as different blockchain nodes, and even though the first blockchain node is a consensus node on the blockchain main network, the second blockchain node on the same node device may also be a non-consensus node on the blockchain sub-network. For example, in fig. 5, the nodeA in subnet0 corresponds to a first blockchain node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a second blockchain node. It can be seen that, because the identity systems are independent from each other, even if the public key adopted by the second blockchain node is different from the first blockchain node, the implementation of the scheme of the present specification is not affected, and because the scheme of the present specification provides a method for customizing the consensus type of the blockchain nodes when creating the blockchain subnet, the consensus type heterogeneity of different blockchain link points on the same node device can be realized, thereby satisfying various networking requirements of users and enabling networking to have stronger flexibility.

Of course, the node members participating in the blockchain sub-network are not necessarily only a part of the node members participating in the blockchain main network. In some cases, the node members participating in the blockchain subnet may be completely consistent with the node members participating in the blockchain main network, and at this time, all the node members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, so that service data generated by the two types of services may be isolated from each other.

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

One of the advantages of building the block chain sub-network by the block chain main network is that since the first block chain node is already deployed on the node device generating the second block chain node, the block chain platform code used by the first block chain node can be multiplexed on the second block chain node, so that repeated deployment of the block chain platform code is avoided, and the building efficiency of the block chain sub-network is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the second blockchain link point may reuse the attribute configuration adopted on the first blockchain node; if the configuration information includes the attribute configuration for the blockchain platform code, the second blockchain link point may adopt the attribute configuration, so that the attribute configuration adopted by the second blockchain node is not limited to the attribute configuration of the first blockchain node and is independent of the first blockchain link point. The attribute configuration for blockchain platform code may include at least one of: the code version number, whether consensus is needed, the type of consensus algorithm, the size of the block, etc., which is not limited in this specification, it should be noted that whether consensus is needed herein refers to whether a consensus mechanism needs to be configured for the whole block chain subnet, rather than whether the block chain link points corresponding to specific node members need to be known.

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

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

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

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

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

Event：

[topic:other][data]

[topic:subnet][data]

......

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

{subnet1；

a public key of nodeA, consensus type information of nodeA1, IP of nodeA, and port number … of nodeA;

a public key of nodeB, consensus type information of nodeB1, IP of nodeB, port number … of nodeB;

a public key of the nodeC, consensus type information of the nodeC1, an IP of the nodeC, and a port number … of the nodeC;

a public key of nodeD, consensus type information of nodeD1, IP of nodeD, port number … of nodeD;

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, it may be determined whether the subnet1 already exists according to the recorded network identifications of all blockchain subnets that have been created; if the Subnet1 does not exist, it indicates that the Subnet1 is a new blockchain Subnet that needs to be created currently, for example, when a transaction of the Subnet1 calls a Subnet contract in the Subnet0, a Subnet contract state corresponding to the Subnet1 may be added in the contract state of the Subnet contract, where the contract state includes various types of Subnet information of the Subnet1, including network identifiers, public keys and common identification type information of node members, an operation state of the network, a creation block, and the like, and the Subnet contract state may be recorded in a world state of the Subnet0, and meanwhile, since the Subnet contract state for the Subnet1 has been added and maintained when the transaction of the Subnet1 is performed, when the transaction of the Subnet1 is obtained and performed again subsequently, the Subnet contract state 1 may be determined to exist according to the Subnet contract state of the Subnet 1; if the sub net1 exists, the sub net1 is not created again, and the result of the failure of the transaction execution of the sub net1 and the reason of the failure can be informed to each main network node in the form of a receipt. After the creation of the Subnet1 is completed, the Subnet1 may also create a Subnet contract to store the public keys and consensus type information corresponding to each node member in the contract state of the Subnet contract based on the information in the creation block, so as to be recorded in the world state of the Subnet 1.

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

Besides the network identifier subnet1, the data field further includes content such as identity information of each node member participating in building the blockchain subnet and consensus type information of the corresponding blockchain node to be created, for example, consensus type information of nodeA1 to nodeD1, where nodeA1 to nodeD1 are the blockchain nodes to be created on the subnet1 of the node members corresponding to nodeA to nodeD, and are to be deployed in the node devices 1 to 4, respectively. The node device deploying the first blockchain node may monitor the generated receipt, and acquire, by the node device deploying the first blockchain node, configuration information or a creation block included in the networking event when the networking event is monitored and the content of the networking event includes identity information of a node member corresponding to the first blockchain node. Or the first block link point may monitor the generated receipt, and trigger the node device deploying the first block link node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA to nodeE are respectively deployed on the node devices 1 to 5, and the node devices 1 to 5 can monitor receipts respectively generated by the nodeA to nodeE, under the condition that the subnet1 is monitored to be a block chain subnet needing to be newly established, the node devices 1 to 5 further identify the identity information of the node members contained in the data field and the consensus type information of the corresponding block chain nodes to be established, so as to determine the processing mode of the node devices. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of nodeA, node device 1 generates a created block containing configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and node device 1 deploys nodeA1 locally so that the consensus type of nodeA1 matches the corresponding consensus type information, and nodeA1 loads the generated created block, thereby becoming a subnet node of subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeB c1, and node device 4 may generate nodeB 1. And if the node device 5 finds that the identity information included in the data field does not match with itself, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet 1.

As mentioned above, the blockchain link point in the blockchain master network can listen for the receipt and trigger the node device to perform the relevant processing according to the listening result. For example, when determining that subnet1 is a blockchain subnet that needs to be newly established, nodeb a to nodeb e further identifies identity information of node members included in the data field and consensus type information corresponding to the blockchain node to be created, so as to determine its own processing method. For example, nodeA to nodeD may find that the data field includes identity information such as a public key, an IP address, a port number, and the like of the data field and consensus type information corresponding to the to-be-created block chain node, assuming that nodeA to nodeD are respectively deployed on node devices 1 to 4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 generates a creation block containing the configuration information under the condition that the node device 1 obtains the configuration information from the data field based on the message mechanism, and the node device 1 deploys the nodeA1 locally, so that the consensus type of the nodeA1 is matched with the corresponding consensus type information, and the nodeA1 loads the generated creation block, thereby becoming a subnet node of the subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in the subnet 1.

As mentioned above, the first block link point and the second block link point do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may include identity information and consensus type information previously generated for nodeA 1-nodeD 1, wherein the identity information of nodeA 1-nodeD 1 is different from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if the identity information of nodeA1 is found in the data field, node device 1 may generate a created block, deploy nodeA1 so that the consensus type of nodeA1 matches the corresponding consensus type information, and load the created block by nodeA 1; alternatively, nodeA, if the identity information of nodeA1 is found in the data field, would trigger node device 1 to generate a birth block, deploy nodeA1 so that the consensus type of nodeA1 matches the corresponding consensus type information, and load the birth block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

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

When a transaction of the Subnet1 is established to call a Subnet contract on the Subnet0, it is detected whether there is no definition of the consensus type information corresponding to at least one node member in the configuration information included in the transaction, and if there is any, the consensus type information of the corresponding segment link point of the at least one node member in the segment chain main network is read in the contract state of the Subnet contract itself, so as to replace the consensus type information of the corresponding node member in the configuration information. For example, when a Subnet contract is called and executed by a transaction, if it is detected that the consensus type information of the node member corresponding to the nodeA in the transaction is null, the consensus type information corresponding to the nodeA is found out according to the main network contract state maintained by the Subnet contract, and the consensus type information is added to a null field of the consensus type information of the node member corresponding to the nodeA, so that the configuration information does not have undefined consensus type information after the contract is executed, and the problem of creation failure caused by the fact that the consensus type information cannot be identified in the subsequent processes of creating the nodeA 1-nodeD 1 is solved.

As another method for realizing that the common recognition type of the second blockchain node corresponding to the first node member in the blockchain subnet inherits the common recognition type of the first blockchain node in the blockchain main network, after the node device monitors a receipt, it is detected whether the configuration information contained in the data field of the receipt has a value-taking condition that the node member corresponds to the common recognition type information of the blockchain network to be created, and under the condition that the common recognition type information corresponding to each node member in the configuration information is determined to have a definition, an creation block containing the configuration information is generated based on the transaction; and under the condition that the consensus type information corresponding to at least one node member in the configuration information is determined to be undefined, acquiring the consensus type information of the corresponding block link node of the at least one node member in the block link main network to replace the consensus type information of the corresponding node member in the configuration information, and generating an creation block containing the replaced configuration information. Taking nodeA and node device 1 as an example: if the node apparatus 1 finds that the consensus type information of the nodeA1 corresponding to the nodeA is missing in the data field, the node apparatus may fill the missing field with the consensus type information of the nodeA, so as to update the content of the configuration information, so that the consensus type information of the nodeA1 in the created block generated according to the updated configuration information is defined and is the same as the consensus type information of the nodeA, and therefore the deployed consensus type of the nodeA1 is the same as the consensus type of the nodeA, and the created block is loaded by the nodeA 1.

In the above method, a master network management contract is deployed in the block chain master network, where the master network management contract is used to maintain a common identification type corresponding to each block link point in the block chain master network, and a node device may obtain, from an execution result corresponding to the master network management contract, common identification type information of a block link point corresponding to at least one node member in the block chain master network, where the execution result is obtained by a first block link point executing a master network configuration information query transaction that invokes the master network management contract, for example, when detecting that common identification type information of nodeA1 corresponding to nodeA is missing, the node device 1 may initiate a master network configuration information query transaction to the master network management contract to obtain common identification type information of nodeA, or may also initiate the master network configuration information query transaction to the master network management in advance, so as to locally maintain common identification type information of nodeA to nodeA in each block link point in the block chain master network, when detecting that the consensus type information of the nodeA1 corresponding to the nodeA is missing, directly and locally inquiring the consensus type information corresponding to the nodeA, wherein the main network management contract may be the same as or different from the foregoing Subnet contract;

or, the node device may read the contract state of the master link management contract from the database corresponding to the first block link point, and obtain the common identification type information of the block link point corresponding to at least one node member in the block chain master from the read contract state, for example, the node device 1 may directly read the contract state of the master link management contract deployed in the block chain master from the database of the block chain master corresponding to the first block chain, and since the contract state records the common identification type information of each block chain node in the block chain master, the node device may read the common identification type information of the nodeA from the database when detecting that the common identification type information of the nodeA1 corresponding to the nodeA is missing. The primary network management contract may be the Subnet contract or other intelligent contracts deployed on the blockchain primary network.

In this specification, the transaction for creating the blockchain subnet may not be a transaction for calling an intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of this specification, thereby quickly creating the blockchain subnet on the basis of the blockchain main network. For example, a group network transaction type identifier may be predefined, and when a transaction includes the group network transaction type identifier, it indicates that the transaction is used for building a new blockchain subnet, that is, the transaction is a transaction for building a blockchain subnet. The blockchain platform code may include related processing logic for constructing a blockchain subnet, so that when a first blockchain node running the blockchain platform code executes a transaction, if the transaction is found to include the networking transaction type identifier, and the identity information of a node member corresponding to the first blockchain node and the consensus type information corresponding to the blockchain node to be created are included in the configuration information in the transaction, at this time, the blockchain node to be created is a second blockchain node, a node device that deploys the first blockchain node may be triggered based on the processing logic to generate an innovation block including the configuration information and start the second blockchain node, and the innovation block is loaded by the second blockchain node to form a blockchain node in the blockchain subnet.

The node equipment realizes the deployment of a blockchain node on the node equipment by creating an instance of a running blockchain platform code in a process. For the first blockchain node, it is formed by the node device creating a first instance of the running blockchain platform code in the above-described process. Similarly, for the second blockchain node, it is formed by the node device creating a second instance of the run blockchain platform code in the above-described process. For example, the node device may first create a first instance in a 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 building the blockchain subnet, a second instance may be created in the process, where the second instance is different from the first instance, and forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are located in the same process, the deployment difficulty of the second block chain node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved. Of course, the second instance may also be in a different process on the node device than the first instance, and this specification does not limit this; for example, the 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 building the blockchain subnet, a second process different from the first process may be started, and a second instance different from the first instance may be created in the second process, so that the second blockchain node in the blockchain subnet is formed by the second instance.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 5 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as new blockchain main networks, and a blockchain subnet is further constructed on the basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again.

In the above embodiment as shown in fig. 4, the process of building a blockchain subnet in the present specification is actually described from the perspective of the whole blockchain system, and in this process, not all node members participate in the blockchain subnet, and next, in conjunction with fig. 6, the technical solution of the present specification will be described from the perspective of the master node participating in the blockchain subnet and the node device located in the master node. It will be readily appreciated that the embodiment shown in fig. 6 is not substantially different from the embodiment shown in fig. 4, and the foregoing description of the embodiment shown in fig. 4 applies to the embodiment shown in fig. 6.

Fig. 6 is a flowchart of another method for building a blockchain subnet provided by an example embodiment. As shown in fig. 6, the method may include the steps of:

step 602, a first blockchain link point in a blockchain master network respectively obtains a transaction for establishing a blockchain subnet, where the transaction includes configuration information of the blockchain subnet, the configuration information includes identity information and consensus type information of each node member participating in establishing the blockchain subnet, and the consensus type information is used to indicate a consensus type of a corresponding node member in the blockchain subnet.

In step 604, the first block node performs the transaction to reveal the configuration information.

Step 606, when the configuration information includes the identity information of the first node member corresponding to the first block link point, the node device deploying the first block link node starts a second block link node belonging to the block link subnet based on the creation block including the configuration information.

As has been described in the foregoing, the present invention,

under the condition that the consensus type information corresponding to the first node member in the configuration information is defined, the consensus type of the second block chain node is matched with the consensus type information;

the second block link node inherits the consensus type of the first block link node in case the consensus type information corresponding to the first node member in the configuration information is undefined.

As described above, the matching of the consensus type of the second blockchain node to the consensus type information includes:

when the consensus type information is a first value, the second block chain node is a consensus node;

and when the consensus type information is a second value, the second block chain node is a non-consensus node.

As previously mentioned, the created blocks are generated based on the following approaches:

the node equipment generates a creation block containing the configuration information based on the transaction under the condition that the common identification type information corresponding to each node member in the configuration information is determined to be defined;

and under the condition that the common identification type information corresponding to at least one node member in the configuration information is determined to be undefined, the node equipment acquires the common identification type information of the corresponding block chain link point of the at least one node member in the block chain main network, replaces the common identification type information of the corresponding node member in the configuration information, and generates an creation block containing the replaced configuration information.

As described above, a master network management contract is deployed in the block chain master network, and the master network management contract is used to maintain the corresponding consensus type of each block link point in the block chain master network.

As described above, the obtaining the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network includes:

acquiring the consensus type information of the block chain node corresponding to the at least one node member in the block chain master network from the execution result corresponding to the master network management contract, wherein the execution result is obtained by executing a master network configuration information query transaction for calling the master network management contract by a first block chain node.

and the node equipment reads the contract state of the master network management contract from a database corresponding to the first block link point, and acquires the consensus type information of the block link point corresponding to at least one node member in the block chain master network from the read contract state.

As previously described, the transactions that make up the blockchain subnet include transactions that invoke contracts.

As previously described, the contract is created and maintained with a subnet contract state that includes the configuration information in accordance with the transaction.

As mentioned above, the method further comprises:

when the contract is executed, if it is detected that the consensus type information corresponding to at least one node member in the configuration information is undefined, reading the consensus type information of the corresponding block link point of the at least one node member in the block link main network from the contract state of the contract, and replacing the consensus type information of the corresponding node member in the configuration information.

As previously described, the performing the transaction at the first blockchain link point in the blockchain master network includes:

a first blockchain node in the blockchain master network compares the identity information of each node member contained in the configuration information with a locally maintained legal identity information list, and executes the transaction under the condition that the identity information of each node member is determined to be contained in the legal identity information list, wherein the content of the legal identity information list comprises at least one of the following: identity information of each block chain node in the block chain main network and identity information of each block chain node in the block chain sub-network.

As mentioned above, the configuration information further includes at least one of: the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

As previously mentioned, the attribute configuration for blockchain platform code includes at least one of: code version number, whether consensus is required, consensus algorithm type, block size.

As previously mentioned, the identity information includes at least one of: a subnet node public key, a main network node number, a node device IP address, a node device port number and a node device number.

As described above, the sub-network node public key is reused for the main network node public key of the corresponding node member in the blockchain main network; or, the subnet node public key is different from the master network node public key of the corresponding node member in the blockchain master network.

As previously described, the node device initiating a second block link point comprises: the node device creates a second instance of a run blockchain platform code distinct from the first instance of the first blockchain node on which the blockchain platform code is run.

As described above, the block generated by the first block link point and the block generated by the second block link point are stored in different storages on the node device.

As described above, the block chain master network is a bottom layer block chain network; or, the block chain master network is a subnet of other block chain networks.

Fig. 7 is a schematic block diagram of a blockchain system according to an exemplary embodiment. As shown in fig. 6, the blockchain system includes:

each blockchain node in the blockchain master network 700 is configured to respectively acquire and execute a transaction for establishing a blockchain subnet, so as to reveal configuration information of the blockchain subnet included in the transaction, where the configuration information includes identity information and consensus type information of each node member participating in establishing the blockchain subnet, and the consensus type information is used to indicate a consensus type of a corresponding blockchain link point of the corresponding node member in the blockchain subnet.

A node device 701, configured to, when the configuration information includes identity information of a node member corresponding to a blockchain node deployed on the node device 701, start a second blockchain node belonging to the blockchain subnet based on an innovation block including the configuration information.

Alternatively to this, the first and second parts may,

Optionally, the matching of the consensus type of the second blockchain node to the consensus type information includes:

Optionally, the generating, by the node device 701, an ancestry block including the configuration information based on the transaction includes:

the node device 701 generates a creation block including the configuration information based on the transaction under the condition that it is determined that the consensus type information corresponding to each node member in the configuration information is defined;

the node device 701, when determining that the consensus type information corresponding to at least one node member in the configuration information is undefined, obtains the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network, replaces the consensus type information of the corresponding node member in the configuration information, and generates an creation block including the replaced configuration information.

Optionally, a master network management contract is deployed in the block chain master network 700, and the master network management contract is used to maintain a common identification type corresponding to each block link point in the block chain master network 700.

Optionally, the obtaining the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network 700 includes:

obtaining the consensus type information of the corresponding block chain node of the at least one node member in the block chain master network 700 from the execution result corresponding to the master network management contract, where the execution result is obtained by executing a master network configuration information query transaction for calling the master network management contract by a first block chain node.

the node device 701 reads the contract state of the master network management contract from the database corresponding to the first block link point, and obtains the consensus type information of the block link point corresponding to at least one node member in the block chain master network 700 from the read contract state.

Optionally, the transaction of the building blockchain subnet includes a transaction of a call contract.

Optionally, the contracts include startup contracts or system contracts.

Optionally, the contract is created and maintained with a subnet contract state according to the transaction, and the subnet contract state includes the configuration information.

Optionally, the method further includes:

when the contract is executed, if it is detected that the consensus type information corresponding to at least one node member in the configuration information is undefined, reading the consensus type information of the corresponding block link point of the at least one node member in the block link master network 700 from the contract state of the contract, and replacing the consensus type information of the corresponding node member in the configuration information.

Alternatively to this, the first and second parts may,

the execution result of the contract includes the configuration information, the node device 701 deploying the first block chain node obtains the configuration information through a message mechanism, and generates the created block according to the obtained configuration information; alternatively, the first and second electrodes may be,

the execution result of the contract includes the founder block, which is obtained by the node device 701 deploying the first blockchain node through a message mechanism.

Optionally, a receipt generated after the contract is executed includes a networking event related to the establishment of a new blockchain subnet; the node device 701 that deploys the first block chain node obtains the configuration information or the created block through a message mechanism, including:

monitoring a generated receipt by a first block link point, and triggering node equipment 701 for deploying a first block link node to acquire the configuration information or the creation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to a first node member of the node members; alternatively, the first and second electrodes may be,

the node device 701 deploying the first blockchain node monitors the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain link point belongs to a first node member of the node members, the node device 701 deploying the first blockchain node acquires the configuration information or the created block included in the networking event.

Optionally, the networking event includes: the subject name in the receipt contains the event identified by the predefined networking event.

Optionally, when the content of the networking event includes the following identifier, it indicates that the networking event is related to establishing a new blockchain subnet:

the network identification of the block chain sub-network which is expected to be established is different from the existing block chain sub-network; alternatively, the first and second electrodes may be,

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

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

Optionally, the performing the transaction by each blockchain link point in the blockchain master network 700 includes:

each of the blockchain nodes in the blockchain master network 700 compares the identity information of each node member included in the configuration information with a locally maintained legal identity information list, and executes the transaction if it is determined that the identity information of each node member is included in the legal identity information list, where the content of the legal identity information list includes at least one of: identity information of each block chain node in the block chain master network 700, and identity information of each block chain node in the block chain sub-network.

Alternatively to this, the first and second parts may,

the transaction of the building blockchain subnet is initiated by the administrator of the blockchain master network 700; alternatively, the first and second electrodes may be,

the transaction to build the blockchain subnet is initiated by a normal user of the blockchain main network 700.

Optionally, the configuration information further includes at least one of: the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

Optionally, the blockchain main network 700 is the same as or different from an administrator of the blockchain sub-network.

Optionally, the attribute configuration for the blockchain platform code includes at least one of: code version number, whether consensus is required, consensus algorithm type, block size.

Optionally, the identity information includes at least one of: a subnet node public key, a main network node number, a node device IP address, a node device port number and a node device number.

Optionally, the subnet node public key is reused for the master network node public key of the corresponding node member in the blockchain master network 700; alternatively, the subnet node public key is different from the master node public key of the corresponding node member in the blockchain master network 700.

Optionally, the node apparatus 701 starts a second block link point including: the node apparatus 701 creates a second instance of running blockchain platform code distinct from the first instance of the blockchain platform code running on the node apparatus 701 and corresponding to the first blockchain node.

Optionally, the block generated by the link point of the first block and the block generated by the link point of the second block are respectively stored in different storages on the node device.

Optionally, the first block link point and the second block link point are isolated from each other.

Optionally, the storage is a database.

Optionally, the block chain main network 700 is a bottom layer block chain network; alternatively, the blockchain main network 700 is a subnet of other blockchain networks.

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

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

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

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

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

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

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

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

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

Claims

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

each block link point in the block chain main network respectively executes the transaction to reveal the configuration information;

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

3. The method of claim 2, the type of consensus of the second blockchain node matching the type of consensus information, comprising:

4. The method of claim 1, the created blocks being generated based on:

5. The method of claim 4, wherein a master network management contract is deployed in the block chain master network, and the master network management contract is used for maintaining a common identification type corresponding to each block link point in the block chain master network.

6. The method of claim 5, wherein the obtaining of the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network comprises:

7. The method of claim 5, wherein the obtaining of the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network comprises:

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

9. The method of claim 8, the contract created and maintained according to the transaction having a subnet contract state, the subnet contract state including the configuration information.

10. The method of claim 8, further comprising:

11. The method of claim 1, wherein performing the transaction separately for each blockchain link point in the blockchain master network comprises:

each block link point in the block chain main network respectively compares the identity information of each node member contained in the configuration information with a locally maintained legal identity information list, and executes the transaction under the condition that the identity information of each node member is determined to be contained in the legal identity information list, wherein the content of the legal identity information list comprises at least one of the following: identity information of each block chain node in the block chain main network and identity information of each block chain node in the block chain sub-network.

12. The method of claim 1, the configuration information further comprising at least one of: the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

13. The method of claim 12, wherein configuring attributes for blockchain platform code comprises at least one of: code version number, whether consensus is required, consensus algorithm type, block size.

14. The method of claim 1, the identity information comprising at least one of: a subnet node public key, a main network node number, a node device IP address, a node device port number and a node device number.

15. The method of claim 14, the sub-network node public key is reused for a master network node public key of the respective node member in the blockchain master network; or, the subnet node public key is different from the master network node public key of the corresponding node member in the blockchain master network.

16. The method of claim 1, the node device initiating a second block link point comprising: the node device creates a second instance of a run blockchain platform code distinct from the first instance of the first blockchain node on which the blockchain platform code is run.

17. The method of claim 1, wherein the block generated by the first block link point and the block generated by the second block link point are stored in different storages on the node device.

18. The method of claim 17, wherein the storage used by the first block link point and the second block link point, respectively, are isolated from each other.

19. The method of claim 1, the block chain master network being an underlay block chain network; or, the block chain master network is a subnet of other block chain networks.

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

21. The method of claim 20, wherein the first and second portions are selected from the group consisting of,

22. The method of claim 21, the type of consensus of the second blockchain node matching the type of consensus information, comprising:

23. The method of claim 20, the created blocks being generated based on:

24. The method of claim 23, wherein a master network management contract is deployed in the block chain master network, and the master network management contract is used to maintain a common identification type corresponding to each block link point in the block chain master network.

25. The method of claim 24, wherein the obtaining of the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network comprises:

26. The method of claim 24, wherein the obtaining of the consensus type information of the corresponding blockchain link point of the at least one node member in the blockchain master network comprises:

27. The method of claim 20, the transactions to group blockchain subnets comprising transactions to invoke contracts.

28. The method of claim 27, the contract created and maintained according to the transaction having a subnet contract state, the subnet contract state including the configuration information.

29. The method of claim 27, further comprising:

30. The method of claim 20, the performing the transaction at a first blockchain link point in the blockchain master network comprising:

31. The method of claim 20, the configuration information further comprising at least one of: the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

32. The method of claim 31, configuring properties for blockchain platform code comprising at least one of: code version number, whether consensus is required, consensus algorithm type, block size.

33. The method of claim 20, the identity information comprising at least one of: a subnet node public key, a main network node number, a node device IP address, a node device port number and a node device number.

34. The method of claim 33, the sub-network node public key is reused for a master network node public key of the respective node member in the blockchain master network; or, the subnet node public key is different from the master network node public key of the corresponding node member in the blockchain master network.

35. The method of claim 20, the node device initiating a second block link point comprising: the node device creates a second instance of a run blockchain platform code distinct from the first instance of the first blockchain node on which the blockchain platform code is run.

36. The method of claim 20, wherein the block generated by the first block link point and the block generated by the second block link point are stored in different storages on the node device.

37. The method of claim 20, the blockchain master network is an underlay blockchain network; or, the block chain master network is a subnet of other block chain networks.

38. A blockchain system, comprising: