CN113098984B

CN113098984B - Method for forming multi-layer block chain system based on registration mechanism and block chain system

Info

Publication number: CN113098984B
Application number: CN202110611545.6A
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-08-31
Anticipated expiration: 2041-06-02
Also published as: CN113098984A

Abstract

One or more embodiments of the present specification provide a method for forming a multi-tiered blockchain system based on a registration mechanism, comprising: receiving a registration transaction by a block chain node in a first block chain network, acquiring identity information of a second block chain network from the registration transaction, and performing association and certificate storage on the acquired identity information of the second block chain network and a subnet identifier distributed to the second block chain network so as to register the second block chain network as a subnet of the first block chain network; and the block chain link point in the second block chain network receives the anchoring transaction, acquires the identity information of the first block chain network and the subnet identification distributed to the second block chain network from the anchoring transaction, and updates the acquired identity information of the first block chain network and the subnet identification distributed to the second block chain network into the identity information of the second block chain network so as to anchor the first block chain network as the main network of the second block chain network.

Description

Method for forming multi-layer block chain system based on registration mechanism and block chain system

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method for forming a multi-layer blockchain system based on a registration mechanism and a blockchain system.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a blockchain network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. In some block chain networks, part of node members sometimes have a need to implement small-scale transactions, and other node members are prevented from obtaining the transactions and related data thereof through corresponding nodes.

Therefore, the established blockchain network can be used as a blockchain main network, and a blockchain sub-network is reestablished by the node members with the small-range transaction requirements on the basis of the blockchain main network, so that the small-range transaction requirements among the node members can be met, and the blockchain sub-network can be conveniently managed by the blockchain main network.

However, the management relationship between the blockchain main network and the blockchain sub-network needs to be formed along with the building of the blockchain sub-network, so that the blockchain network management scheme implemented based on the management relationship has a limitation of a use scenario.

Disclosure of Invention

In view of the above, one or more embodiments of the present disclosure provide a method and a blockchain system for forming a multi-layer blockchain system based on a registration mechanism.

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 forming a multi-layer blockchain system based on a registration mechanism, including:

receiving a registration transaction by a block chain node in a first block chain network, acquiring identity information of a second block chain network from the registration transaction, and performing association and certificate storage on the acquired identity information of the second block chain network and a subnet identifier distributed to the second block chain network so as to register the second block chain network as a subnet of the first block chain network;

and the block chain link point in the second block chain network receives the anchoring transaction, acquires the identity information of the first block chain network and the subnet identification distributed to the second block chain network from the anchoring transaction, and updates the acquired identity information of the first block chain network and the subnet identification distributed to the second block chain network into the identity information of the second block chain network so as to anchor the first block chain network as the main network of the second block chain network.

According to a second aspect of one or more embodiments of the present specification, there is provided a method for forming a multi-layer blockchain system based on a registration mechanism, including:

receiving a registration transaction by a block chain node in a first block chain network, acquiring identity information and a target subnet identification of a second block chain network from the registration transaction, and sending a registration instruction containing the identity information of the second block chain network to a third block chain network corresponding to the target subnet identification under the condition that the target subnet identification corresponds to a subnet of the first block chain network;

under the condition that the registration instruction is determined to be sent by the main network corresponding to the third block chain network, the third block chain network associates and stores the identity information of the second block chain network contained in the registration instruction with the subnet identification allocated to the second block chain network, so that the second block chain network is registered as the subnet of the third block chain network;

and the block chain nodes in the second block chain network receive the anchoring transaction, acquire the identity information of the third block chain network and the subnet identification distributed to the second block chain network from the anchoring transaction, and update the acquired identity information of the third block chain network and the subnet identification distributed to the second block chain network into the identity information of the second block chain network so as to anchor the third block chain network as the main network of the second block chain network.

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

the system comprises a first block chain network, a second block chain network and a third block chain node, wherein the block chain node in the first block chain network receives registration transaction, acquires identity information of the second block chain network from the registration transaction, and associates and stores the acquired identity information of the second block chain network and a subnet identification distributed to the second block chain network so as to register the second block chain network as a subnet of the first block chain network;

and the block chain nodes in the second block chain network receive the anchoring transaction, acquire the identity information of the first block chain network and the subnet identification distributed to the second block chain network from the anchoring transaction, and update the acquired identity information of the first block chain network and the subnet identification distributed to the second block chain network into the identity information of the second block chain network so as to anchor the first block chain network as the master network of the second block chain network.

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

the method comprises the steps that a first blockchain network receives registration transactions, identity information and a target subnet identification of a second blockchain network are obtained from the registration transactions, and a registration instruction containing the identity information of the second blockchain network is sent to a third blockchain network corresponding to the target subnet identification under the condition that the target subnet identification corresponds to a subnet of the first blockchain network;

the third block chain network associates and stores the identity information of the second block chain network contained in the registration instruction with the subnet identification allocated to the second block chain network under the condition that the registration instruction is determined to be sent by the main network corresponding to the third block chain network, so that the second block chain network is registered as the subnet of the third block chain network;

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 schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

Fig. 5 is a flowchart of a method for forming a multi-layer blockchain system based on a registration mechanism according to an exemplary embodiment.

Fig. 6 is a schematic diagram of a subnet for registering a blockchain network as another blockchain network according to an exemplary embodiment.

Fig. 7 is a schematic diagram of another exemplary embodiment of registering a blockchain network as a subnet of other blockchain networks.

Fig. 8 is a flowchart of another method for forming a multi-layer blockchain system based on a registration mechanism according to an example embodiment.

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

Fig. 10 is a block chain system according to another 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, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds 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 realize message passing through an event in a receipt so as to trigger the blockchain node or a node device deploying 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 blockchain node or the node device deploying the blockchain node may perform the preset processing by monitoring the topic of the event, in case that the predefined topic is monitored, or read the related content from the data field of the corresponding event, and may perform the preset processing 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 block chain network, the block chain link points in the block chain network maintain the same block data, and the special requirements of partial 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.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of 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 process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each block chain link point in the block chain main network respectively acquires a transaction for establishing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, and the configuration information comprises identity information of node members participating in establishing the block chain sub-network. Then, each block link point in the block chain main network respectively executes the transaction; when the configuration information contains identity information of node members corresponding to the first block link nodes, the node equipment deploying the first block link nodes generates a created block containing the configuration information based on the transaction and starts a second block link node belonging to the block link sub-network based on the created block.

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. 4, 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 blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when a blockchain subnet1 is constructed on subnet0 shown in fig. 4, 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. 4 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain master network in this specification may be a sub-network of another blockchain network, for example, another blockchain sub-network may be further configured on the basis of the subnet1 in fig. 4, and at this time, the subnet1 may be considered as the blockchain master network corresponding to the blockchain sub-network, and this does not affect that the subnet1 belongs to the blockchain sub-network 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.

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

The identity information of the node member may include a public key, or other information capable of representing the identity of the node member, such as a node ID, which is not limited in this specification. Taking a public key as an example, each 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 the blockchain sub-network, the public keys of the corresponding blockchain nodes of the node members on the blockchain main network can be added to the transaction for establishing the blockchain sub-network to serve as the identity information of the node members. 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.

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 the block chain sub-network, but the second block chain node needs to be generated by the node device for deploying the first block chain node, and the second block chain link point participates in 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 identity systems of the two blockchain networks are independent from each other due to the independence between the blockchain main network and the blockchain sub-network, even though the first blockchain node and the second blockchain node may use the same public key, they should be regarded as different blockchain nodes. For example, in fig. 4, 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 of 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 in this specification is not affected.

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

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the 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: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet 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；

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

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

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

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

}

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

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 identification subnet1, the data field also contains the identity information of each node member participating in building the blockchain subnet. 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, the node devices 1 to 5 further identify the identity information of the node members included in the data field to determine their own processing modes when it is monitored that the subnet1 is a block chain subnet that needs to be newly built. 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, 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 built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, the nodeA to nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, and assume 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 created block containing the configuration information when obtaining the configuration information from the data field based on the above message mechanism, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created 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 the identity information previously generated for nodeA 1-nodeD 1, and is different from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational 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.

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 building 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 above networking transaction type identifier and the identity information of a node member corresponding to the first blockchain node is included in the configuration information in the transaction, a node device deploying the first blockchain node may be triggered to generate an innovation block including the configuration information and start a second blockchain node based on the processing logic, 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. 4 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, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeC2, nodeD and 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.

By establishing the block chain sub-network in the above manner, a management relationship can be formed between the block chain main network and the block chain sub-network, that is, the block chain main network can manage the block chain sub-network. However, such a management relationship is established based on the building process of the blockchain sub-network, and for a blockchain network established by other methods, the management relationship cannot be established conveniently by the above method, so that it is difficult to implement management of the blockchain network. Therefore, the present specification provides a method for forming a multi-layer blockchain system based on a registration mechanism, which can establish a management relationship between blockchain networks without a building process and manage the blockchain networks accordingly, so that the method is not limited by the building method of the blockchain networks, and can be applied to more use scenarios to improve the management efficiency of the blockchain networks.

Referring to fig. 5, fig. 5 is a flowchart illustrating a method for forming a multi-layer blockchain system based on a registration mechanism according to an exemplary embodiment. As shown in fig. 5, the method may include the steps of:

step 502, a block chain node in a first block chain network receives a registration transaction, acquires identity information of a second block chain network from the registration transaction, and associates and stores the acquired identity information of the second block chain network and a subnet identifier allocated to the second block chain network, so as to register the second block chain network as a subnet of the first block chain network.

Different from the aforementioned way of establishing the blockchain subnet based on the blockchain master network, the second blockchain network may not be established based on the first blockchain network, so that the establishment of the second blockchain network does not cause the second blockchain network to form a management relationship with the first blockchain network, that is, the first blockchain network does not become the master network of the second blockchain network, and the second blockchain network does not become the subnet of the first blockchain network. On this basis, the present specification establishes the above-mentioned management relationship between the first blockchain network and the second blockchain network through the registration mechanism, so that the first blockchain network becomes a master network of the second blockchain network, and the second blockchain network becomes a subnet of the first blockchain network.

The registration transaction may be initiated by an administrator of the second blockchain network, i.e. the administrator is only allowed to register the second blockchain network as a subnet of other blockchain networks, while avoiding opening the registration right to the common member to prevent security problems caused thereby. In some cases, the common member of the second blockchain network may also be allowed to initiate the aforementioned registration transaction, so that the common member can still quickly complete the registration in the event that the administrator does not facilitate initiating the transaction.

Taking fig. 6 as an example, the first blockchain network is subnet0, and the subnet0 includes blockchain nodes nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Similar to the embodiment shown in fig. 4, on the basis of the subnet0, corresponding blockchain subnets subnet1 and subnet2 are established to establish management relationships between subnet0 and subnet1 and between subnet0 and subnet2, respectively, so that subnet0 can manage subnet1 and subnet2, respectively. Further, assuming that there exists a blockchain network as subnet3, the subnet3 includes blockchain link points such as nodeK, nodeL, nodeM, and nodeN, and the subnet3 is not constructed on the basis of subnet 0. If the nodeK is an administrator and only allows the administrator to initiate a registration transaction, the registration transaction may be initiated by the nodeK to subnet 0; if the nodeN is an administrator and only allows the administrator to initiate the registration transaction, the nodeK-nodeM need to make a request to the nodeN, so that the nodeN initiates the registration transaction to the subnet 0; if nodeN is an administrator but allows a normal user to initiate a registration transaction, nodeK-nodeL may all initiate the registration transaction to subnet 0.

As described above, when a block chain sub-network is established based on a block chain main network, a logical hierarchical relationship exists between the block chain sub-network and the block chain main network, so as to form a multi-layer block chain system, and this mechanism is referred to as a dynamic networking mechanism hereinafter; for example, when the subnet1 and the subnet2 are grouped on the subnet0 shown in fig. 6, the subnet0 may be considered as a first layer, and the subnet1 and the subnet2 may be considered as a second layer. Similarly, a multi-layer blockchain system is formed by registering the second blockchain network as a subnet of the first blockchain network, so that a logical hierarchical relationship is formed between the first blockchain network and the second blockchain network, and this mechanism is hereinafter referred to as a registration mechanism; for example, as shown in fig. 6, by registering subnet3 with subnet0, subnet0 can be considered to be in the first layer and subnet3 can be considered to be in the second layer.

In the multi-layer block chain system formed by the dynamic networking mechanism or the registration mechanism, the block chain main network may be a bottom-layer block chain network, the bottom-layer block chain network is not a block chain sub-network constructed based on the dynamic networking mechanism on the basis of other block chain networks, and the bottom-layer block chain network is not a sub-network of other block chain networks through the registration mechanism, that is, the bottom-layer block chain network does not have a corresponding main network and is not managed by other block chain networks, for example, the subnet0 in fig. 6 may be regarded as a block chain main network belonging to the bottom-layer block chain network type; alternatively, the blockchain main network may also become a subnet of another blockchain network through a dynamic networking mechanism or a registration mechanism, for example, another blockchain subnet may be further configured through a dynamic networking mechanism on the basis of the subnet1 (or subnet2, subnet 3) in fig. 6, or another blockchain network may be registered as a subnet of the subnet1 (or subnet2, subnet 3), and at this time, it may be considered that the subnet1 (or subnet2, subnet 3) is the blockchain main network corresponding to the blockchain subnet, and this does not affect the subnet1 (or subnet2, subnet 3) and also belong to the blockchain subnet 0. 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 a multi-layer blockchain system, it may include both sets of blockchain main networks and blockchain sub-networks formed by a dynamic networking mechanism and a registration mechanism, for example, subnet1 and subnet2 in fig. 6 become subnets of subnet0 through the dynamic networking mechanism, and subnet3 becomes a subnet of subnet0 through the registration mechanism. Of course, in some cases, a multi-layer blockchain system may also include only the groups of blockchain main networks and blockchain sub-networks formed by the dynamic networking mechanism, or only the groups of blockchain main networks and blockchain sub-networks formed by the registration mechanism.

The registration transaction described above includes a transaction that invokes a contract. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the invoked contract may be the aforementioned startup contract or system contract, the invoked method may be a method that registers for a blockchain subnet, and the incoming parameters may include identity information for the second blockchain network. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet-M

method：RegSubnet(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-M contract, and the to field is specifically the address of the Subnet-M contract; the method field is a method called, for example, a method for registering a blockchain Subnet in a Subnet-M contract may be RegSubnet (string), and string is a parameter in the RegSubnet () method, and the value of the parameter is represented by a representation in the above example, which is specifically the aforementioned identity information of the second blockchain network.

According to the received registration transaction, the block link node in the first block chain network executes the RegSubnet () method called by the registration transaction so as to associate and store the identity information of the second block chain network and the subnet identifier allocated to the second block chain network, thereby being equivalent to that the first block chain network registers the second block chain network as the subnet of the block chain network. If all the blockchain nodes in the first blockchain network are common nodes, then all the blockchain nodes will typically perform the registration transaction described above. If the block chain nodes in the first block chain network comprise common nodes and non-common nodes, the registration transaction can be executed only by the common nodes, and the registration transaction is not executed by the non-common nodes; of course, in addition to differentiating between different nodes based on whether they are in common or not, block chain nodes may be differentiated from other dimensions, such as some nodes may not participate in a common sense but may still perform the registration transaction described above, while other nodes may not participate in a common sense nor perform the registration transaction.

The identity information of the second blockchain network may include: information of all blockchain nodes comprised by the second blockchain network. For example, the information of each blockchain node may include: a node public key, a node IP, a node port number, etc., which is not limited in this specification.

The subnet identification assigned to the second blockchain network, i.e., the subnet ID of the second blockchain network. The generation manner of the subnet ID is not limited in this specification as long as global uniqueness is ensured. For example, a subnet ID may be temporarily generated for the second blockchain network by the RegSubnet () method described above after being called. As another example, the subnet ID may be selected for the second blockchain network from a pre-formed ID pool by the RegSubnet () method described above after being called. For another example, the subnet ID may be generated by the second blockchain network itself and passed into the RegSubnet () method via the aforementioned genetics along with the identity information of the second blockchain network.

By executing the intelligent contract, the block link points in the first block chain network can generate corresponding execution results. The execution result of the contract may include the subnet ID described above; in particular, in the case where the subnet ID is assigned by the first blockchain network, but not self-generated by the second blockchain network, the subnet ID assigned to the second blockchain network needs to be known in this way. Of course, even if the subnet ID is generated by the second blockchain network, it is possible to determine whether the first blockchain network has completed registration with the second blockchain network by monitoring the execution result of the contract. The result of the execution of the contract may include a receipt as described above, which may contain an event related to the execution of the RegSubnet () method, i.e., a subnet registration event. The topic of a subnet registration event may contain a predefined subnet registration event identification to distinguish it from other events. For example, in an event related to the execution of the RegSubnet () method, the content of topic is the keyword RegSubnet, and the keyword is distinguished from topic in the event generated by other methods. Then, by monitoring topic contained in each event in a receipt generated by any blockchain node in the first blockchain network, it is possible to determine to monitor events related to execution of the RegSubnet () method, that is, subnet registration events, in the case of monitoring topic containing the keyword RegSubnet. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:RegSubnet][data]

......

then, when the 1 st event is monitored, the event is determined to be irrelevant to the RegSubnet () method because the contained topic content is other; and when the 2 nd event is monitored, determining that the event is related to a RegSubnet () method because the contained topic content is RegSubnet, and further reading a data field corresponding to the event, wherein the data field comprises the subnet ID. In addition, the subnet registration event may also include identity information of the second blockchain network, so as to determine that the subnet registration event is indeed generated for the second blockchain network.

Based on the monitored subnet registration event, it can be determined that the first blockchain network has registered the second blockchain network as its own subnet on the one hand, and can learn the subnet ID of the second blockchain network on the other hand. Accordingly, an anchoring transaction, described below, may be initiated accordingly to the second blockchain network to complete the anchoring of the relevant information.

The subnet registration event described above may be monitored by the initiator of the registration transaction at a blockchain node in the first blockchain network and the initiator may then initiate an anchor transaction to the second blockchain network. It is also possible that objects other than the initiator of the registration transaction listen for subnet registration events and in turn initiate an anchor transaction to the second blockchain network. Of course, the initiator of the anchor transaction is not necessarily the same as the object that monitors the subnet registration event; in fact, there is no inevitable association between the object initiating the registration transaction, the object listening for the subnet registration event, and the object initiating the anchor transaction, and they may be selected as the same object or different objects according to the actual situation.

The registration transaction 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, and thus the first blockchain network performs associated certificate storage on the identity information of the second blockchain network and the subnet identifier allocated to the second blockchain network. For example, a subnet registration transaction type identifier may be predefined, and when a transaction includes the subnet registration transaction type identifier, it indicates that the transaction is used for registering a new blockchain subnet, i.e. the transaction is a registration transaction. The blockchain platform code may include related processing logic for registering 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 subnet registration transaction type identifier, the identity information of the second blockchain network and the subnet identifier allocated to the second blockchain network may be stored in an associated manner based on the processing logic. At this time, the subnet identification assigned to the second blockchain network may be included in the registration transaction; alternatively, the blockchain platform code may also contain logic to assign subnet identifications, such that the blockchain platform code may assign a corresponding subnet ID to the second blockchain network for the registration transaction.

After the registration transaction is sent to the first blockchain network, the consensus node in the first blockchain network performs consensus, and after the consensus is passed, the transaction is executed by the blockchain node, so that the second blockchain network is registered as the subnet of the second blockchain network. 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. Similarly, an anchoring transaction described below is agreed upon by consensus nodes within the second blockchain network after being sent to the second blockchain network, and the transaction is executed by blockchain nodes after passing consensus to anchor the first blockchain network as its primary network. 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.

Step 504, a block link point in the second block link network receives the anchor transaction, acquires the identity information of the first block link network and the subnet identifier allocated to the second block link network from the anchor transaction, and updates the acquired identity information of the first block link network and the subnet identifier allocated to the second block link network into the identity information of the second block link network, so as to anchor the first block link network as a master network of the second block link network.

By updating the identity information of the first blockchain network and the subnet identification allocated to the second blockchain network into the identity information of the second blockchain network, the identity information of the second blockchain network can anchor the management relationship between the first blockchain network and the second blockchain network. By combining the identity information of the second blockchain network and the subnet identification thereof stored in the first blockchain network, mutual authentication and cross validation between the first blockchain network and the second blockchain network are realized, the management relationship between the first blockchain network and the second blockchain network is ensured to be approved by both parties, and corresponding management operation can be realized subsequently based on the management relationship.

Similar to the registration transaction described above, the anchor transaction may be initiated by an administrator of the second blockchain network. In some cases, the common member of the second blockchain network may also be allowed to initiate the above-described anchoring transaction, so that the common member can still quickly complete the anchoring in the event that the administrator does not have the convenience of initiating the transaction.

The above-described anchor transaction includes a transaction that invokes a contract. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the invoked contract may be a make contract or a system contract in the second blockchain network, the invoked method may be a method of the anchor blockchain primary network, and the incoming parameters may include identity information of the first blockchain network and a subnet ID assigned to the second blockchain network. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet-S

method：AnchSubnet(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-S contract, and the to field is specifically the address of the Subnet-S contract; the method field is a called method, for example, the method used for anchoring the blockchain main network in the Subnet-S contract may be AnchSubnet (string), and string is a parameter in the AnchSubnet () method, and the value of the parameter is represented in the above example by the generic information, specifically, the aforementioned identity information of the first blockchain network and the Subnet ID assigned to the second blockchain network.

And the block link point in the second block chain network executes the AnchSubnet () method called by the anchor transaction according to the received anchor transaction so as to update the identity information of the first block chain network and the subnet identification allocated to the second block chain network into the identity information of the second block chain network, thereby being equivalent to the fact that the second block chain network registers the first block chain network as a main network of the second block chain network. Wherein, the second blockchain network may maintain its own identity information through the world state in the Subnet-S contract, and then the updating of the identity information of the second blockchain network may actually include updating the world state for maintaining the identity information by invoking the Subnet-S contract. If all the blockchain nodes in the second blockchain network are common nodes, then these blockchain nodes will typically perform the anchor transaction described above. If the block chain link points in the second block chain network comprise a common node and a non-common node, the common node can only execute the anchoring transaction, and the non-common node does not execute the anchoring transaction; of course, in addition to differentiating between different nodes based on consensus, the block link points may be differentiated from other dimensions, such as some nodes may not participate in consensus but may still perform the anchor transaction described above, while other nodes may not participate in consensus nor perform the anchor transaction.

The identity information of the first blockchain network may include at least one of: information of all blockchain nodes included in the first blockchain network, a network identifier of the first blockchain network, and the like. Wherein, the information of each blockchain node may include: a node public key, a node IP, a node port number, etc., which is not limited in this specification. Identity information of a first blockchain network may be obtained by initiating an inquiry transaction to a blockchain link point in the first blockchain network; of course, the identity information of the first blockchain network may also be obtained in other manners, which is not limited in this specification.

Based on the registration transaction and the anchor transaction, a management relationship approved by both parties is established between the first blockchain network and the second blockchain network, and the management relationship enables the first blockchain network to become a main network of the second blockchain network and the second blockchain network to become a sub-network of the first blockchain network, so that the first blockchain network can implement corresponding management operation on the second blockchain network based on the management relationship.

The management operations described above may include routing of blockchain messages. For example, if any blockchain node in a first blockchain network receives a blockchain message, and the blockchain message contains a subnet identifier allocated to a second blockchain network, since the first blockchain network has registered the identity information of the second blockchain network and its subnet identifier, the blockchain node may query the identity information of the second blockchain network according to the subnet identifier contained in the blockchain message, and forward the blockchain message to the second blockchain network. Therefore, based on the establishment of the management relationship, the first blockchain network can route the blockchain message to the second blockchain network, which is beneficial to improving the transmission success rate of the blockchain message. Moreover, when the network environment between an object and the first blockchain network is good and the network environment between the object and the second blockchain network is poor, the first blockchain network can be substantially used as a message transmission relay between the object and the second blockchain network, thereby being beneficial to improving the transmission rate and the success rate of the blockchain message. The blockchain message may include various types of messages such as blockchain transaction, blockchain data, consensus message, and the like, which is not limited in this specification.

The block link point in the first block chain network may also record an operation status of the second block chain network, for example, the operation status may include an available status, a disabled status, a suspended status, and the like. Then, when any blockchain node in the first blockchain network receives the above blockchain message and determines that the blockchain message includes the subnet ID of the second blockchain network, the operating state of the second blockchain network may be further queried, so that the blockchain message is forwarded when the second blockchain network is in an available state, otherwise, the blockchain message may not be forwarded to save network resources.

The management operation described above may include direct management for the second blockchain network. For example, management may be performed for a second blockchain network by initiating a management transaction for the second blockchain network to the first blockchain network. The initiator of the management transaction may be, for example, an administrator of the first blockchain network, although other objects are not excluded. Correspondingly, the block link point in the first block chain network can receive the management transaction, obtain the subnet identification and the management instruction distributed to the second block chain network from the management transaction, and send the management instruction to the second block chain network; specifically, the identity information of the corresponding subnet may be queried based on the subnet identification in the management transaction, for example, when the identity information of the second blockchain network is queried, a management command may be sent to the second blockchain network. And under the condition that the block chain link point in the second block chain network determines that the management command is sent by the main network corresponding to the block chain point, executing the management command to complete corresponding management operation.

In actual operation, the management instructions may be transferred to the second blockchain network in a variety of ways. For example: the management command may be included in a subnet management event generated by the first blockchain network executing the management transaction, where the subnet management event includes the management command and a subnet identification included in the management transaction. Then, when the second blockchain network monitors a subnet management event containing its own subnet identification, it can be determined that the management instruction contained in the subnet management event is directed to manage itself. Or, the node device where any blockchain node in the first blockchain network is located may monitor the subnet management event, and send a management instruction to the second blockchain network according to the subnet identifier included in the subnet management event. Alternatively, the first blockchain network may send the management instruction to the second blockchain network through a cross-chain mechanism in the related art in the process of executing the management transaction.

The management instructions described above may be used to implement at least one of: changing an operating state of the second blockchain network, managing blockchain nodes included in the second blockchain network, defining business rules of the second blockchain network, changing functional components used by the second blockchain network, and the like, which are not limited in this specification. When the management command is used to change the operating state of the second blockchain network, the operating state of the second blockchain network may be switched between an available state, a suspended state and a deactivated state, for example. When the management command is used to manage the block link points included in the second block chain network, for example, the block link points included in the second block chain network may be added or deleted. When the management instruction is used to define a business rule of the second blockchain network, the business rule of the second blockchain network may be added, deleted, or modified, where the business rule may include, for example, a data format of a blockchain message that the second blockchain network supports decoding, a contract deployment permission, a contract invocation permission, a contract upgrade permission on the second blockchain network, data that needs to be interacted and certified in the second blockchain network to the first blockchain network, and the like. When the management instruction is used to change the functional element used by the second blockchain network, the functional element is formed by each blockchain node in the second blockchain network running blockchain platform code, such as a consensus element, a privacy protection element, a cross-chain element, a down-chain secret calculation element, a subnet management element, and the like, and the management instruction can be used to add or delete the functional element used by the second blockchain network, or change the functional element used by the second blockchain network, such as changing a consensus algorithm adopted by the consensus element, and the like.

In the embodiment shown in fig. 6, subnet3 may be registered as a subnet of subnet0 based on a registration mechanism by sending a registration transaction to subnet0 and an anchor transaction to subnet 3. On the other hand, as shown in fig. 7, on the basis of the embodiment of fig. 6, if it is desired to register subnet4 as subnet1, subnet2 or subnet3, it is possible to improve the efficiency of the registration mechanism by only directly interacting with subnet0, without interaction with subnet 6342, subnet 6342 and subnet 68628, subnet3 and subnet3, respectively, based on the administrative relationship between subnet1, subnet2 and subnet3 and subnet0, respectively, in addition to sending registration transactions to subnet1, subnet2 or subnet3 and anchor transactions to subnet4 in a manner similar to the way in which subnet3 is registered to subnet0, subnet 6384 and subnet3, respectively, and subnet 4. The improved registration mechanism is described below in conjunction with fig. 8.

Fig. 8 is a flowchart of another method for forming a multi-layer blockchain system based on a registration mechanism according to an example embodiment. As shown in fig. 8, the method may include the steps of:

step 802, a block chain node in a first block chain network receives a registration transaction, acquires identity information of a second block chain network and a target subnet identification from the registration transaction, and sends a registration instruction containing the identity information of the second block chain network to a third block chain network corresponding to the target subnet identification under the condition that the target subnet identification corresponds to a subnet of the first block chain network.

If it is desired to register the second blockchain network with the third blockchain network, the target subnet identification contained in the registration transaction sent to the first blockchain network should assign the subnet ID of the first blockchain network to the third blockchain network, so that the first blockchain network can match to the third blockchain network based on the target subnet identification, and then send the aforementioned registration instruction to the third blockchain network. The process of obtaining the registration instruction by the third blockchain network is similar to the process of obtaining the management instruction by the second blockchain network in the foregoing embodiment, and details are not repeated here. For the object initiating the registration transaction, reference may also be made to the foregoing embodiments, and details are not described here.

Step 804, the third blockchain network performs association and verification storage on the identity information of the second blockchain network contained in the registration instruction and the subnet identification allocated to the second blockchain network under the condition that the registration instruction is determined to be sent by the master network corresponding to the third blockchain network, so as to register the second blockchain network as the subnet of the third blockchain network.

The management relationship between the third blockchain network and the first blockchain network may be formed based on a dynamic networking mechanism or a registration mechanism, which is not limited in this specification. For example, as shown in fig. 7, the subnet4 may be registered as a subnet of subnet1, subnet2, or subnet3 through subnet0, where subnet1 and subnet2 are formed based on a dynamic networking mechanism and subnet3 is formed based on a registration mechanism, and the registration process of subnet4 does not differ accordingly. Of course, although subnet0 is shown in fig. 7 as an underlay blockchain network, i.e., subnet0 is not a subnet of other blockchain networks, the first blockchain network in the present embodiment may not be an underlay blockchain network, i.e., the first blockchain network may also be a subnet of other blockchain networks.

Based on the management relationship between the third block chain network and the first block chain network, the third block chain network may determine whether the block chain network that sends the registration instruction is the own master network, and only process the registration instruction sent by the own master network. The registration instruction may be submitted to the third blockchain network in a form of transaction, for example, a node device that deploys a blockchain node in the first blockchain network or the third blockchain network may monitor an event generated by executing a registration transaction on the first blockchain network, thereby obtaining the aforementioned registration instruction, and further submit a transaction including the registration instruction to the third blockchain network, where the transaction may be verified by invoking an intelligent contract deployed on the third blockchain network or related processing logic included in a blockchain platform code that triggers the third blockchain network to operate, so that the third blockchain network performs an association between the identity information of the second blockchain network and the subnet identifier assigned to the second blockchain network, specifically, refer to a process in which the identity information of the second blockchain network and the subnet identifier assigned to the second blockchain network are verified by the first blockchain network in the foregoing embodiment, and will not be described in detail herein.

Step 806, the block link point in the second block chain network receives the anchor transaction, acquires the identity information of the third block chain network and the subnet identifier allocated to the second block chain network from the anchor transaction, and updates the acquired identity information of the third block chain network and the subnet identifier allocated to the second block chain network into the identity information of the second block chain network, so as to anchor the third block chain network as the master network of the second block chain network.

Step 806 is similar to step 504 in the previous embodiment, and reference may be made to the related description above, which is not repeated herein. Then, based on the association relationship established between the second blockchain network and the third blockchain network, the third blockchain network may implement a corresponding management operation on the second blockchain network, and refer to the management operation implemented on the second blockchain network by the first blockchain network.

For example, any one of the blockchain nodes in the third blockchain network receives a blockchain message, which contains the subnet identification assigned to the second blockchain network; and any block chain node in the third block chain network inquires the identity information of the second block chain network according to the subnet identification contained in the block chain message and forwards the block chain message to the second block chain network. Further, the block link point in the third block chain network also records the operating state of the second block chain network, so that any one of the block link points in the third block chain network can query the operating state of the second block chain network, so as to forward the block chain message when the second block chain network is in an available state, otherwise, the block chain message may not be forwarded.

For another example, the block chain node in the third block chain network receives a management transaction, acquires the subnet identifier and the management instruction distributed to the second block chain network from the management transaction, and sends the management instruction to the second block chain network; and executing the management command by the block link point in the second block chain network under the condition that the management command is determined to be sent by the main network corresponding to the block link point. Wherein the management instructions are for implementing at least one of: the method comprises the steps of changing the running state of the second blockchain network, managing blockchain nodes contained in the second blockchain network, defining business rules of the second blockchain network and changing functional components used by the second blockchain network.

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

a first blockchain network 901, wherein a blockchain node in the first blockchain network 901 receives a registration transaction, acquires identity information of a second blockchain network 902 from the registration transaction, and associates and stores the acquired identity information of the second blockchain network 902 with a subnet identifier allocated to the second blockchain network 902, so as to register the second blockchain network 902 as a subnet of the first blockchain network 901;

the second blockchain network 902, where the blockchain nodes in the second blockchain network 902 receive the anchor transaction, acquire the identity information of the first blockchain network 901 and the subnet identifier allocated to the second blockchain network 902 from the anchor transaction, and update the acquired identity information of the first blockchain network 901 and the subnet identifier allocated to the second blockchain network 902 into the identity information of the second blockchain network 902, so as to anchor the first blockchain network 901 as the master network of the second blockchain network 902.

Optionally:

any block chain link point in the first block chain network 901 receives a block chain message, where the block chain message includes a subnet identifier allocated to the second block chain network 902;

the any blockchain link point in the first blockchain network 901 queries the identity information of the second blockchain network 902 according to the subnet identifier included in the blockchain message, and forwards the blockchain message to the second blockchain network 902.

Optionally, the block link points in the first block chain network 901 further record the operating state of the second block chain network 902; any blockchain node in the first blockchain network 901 queries the operating status of the second blockchain network 902 to forward the blockchain message when the second blockchain network 902 is in an available state.

Optionally:

a block chain node in the first block chain network 901 receives a management transaction, acquires a subnet identifier and a management instruction which are allocated to the second block chain network 902 from the management transaction, and sends the management instruction to the second block chain network 902;

the block link point in the second blockchain network 902 executes the management command when determining that the management command is sent by the master network corresponding to the block link point.

Optionally, the management instruction is configured to implement at least one of:

changing the operating state of the second blockchain network 902, managing blockchain nodes included in the second blockchain network 902, defining business rules of the second blockchain network 902, and changing functional components used by the second blockchain network 902.

Optionally, the registration transaction and/or the anchor transaction comprises a transaction invoking a contract.

Optionally, the contracts include startup contracts or system contracts.

Optionally, the registration transaction and/or the anchor transaction is initiated by an administrator of the second blockchain network 902.

Optionally, the first blockchain network 901 does not have a corresponding main network; alternatively, the first blockchain network 901 is a subnet of other blockchain networks, so as to be managed by the other blockchain networks.

Fig. 10 is a schematic block diagram of another blockchain system provided in an exemplary embodiment. As shown in fig. 10, the block chain system 1000 includes:

the method comprises the steps that a first blockchain network 1001 receives a registration transaction, acquires identity information and a target subnet identification of a second blockchain network 1002 from the registration transaction, and sends a registration instruction containing the identity information of the second blockchain network 1002 to a third blockchain network 1003 corresponding to the target subnet identification under the condition that the target subnet identification corresponds to a subnet of the first blockchain network 1001;

the third blockchain network 1003 associates and verifies the identity information of the second blockchain network 1002 contained in the registration instruction with the subnet identifier allocated to the second blockchain network 1002 under the condition that the registration instruction is determined to be sent by the master network corresponding to the third blockchain network 1003, so that the second blockchain network 1002 is registered as the subnet of the third blockchain network 1003;

and the second blockchain network 1002, the blockchain link point in the second blockchain network 1002 receives the anchor transaction, acquires the identity information of the third blockchain network 1003 and the subnet identifier allocated to the second blockchain network 1002 from the anchor transaction, and updates the acquired identity information of the third blockchain network 1003 and the subnet identifier allocated to the second blockchain network 1002 into the identity information of the second blockchain network 1002, so as to anchor the third blockchain network 1003 as the master of the second blockchain network 1002.

Optionally:

any one of the blockchain link points in the third blockchain network 1003 receives a blockchain message, where the blockchain message includes a subnet identifier assigned to the second blockchain network 1002;

any blockchain link point in the third blockchain network 1003 queries the identity information of the second blockchain network 1002 according to the subnet identifier included in the blockchain message, and forwards the blockchain message to the second blockchain network 1002.

Optionally, the block link points in the third block chain network 1003 further record the operating state of the second block chain network 1002; any blockchain node in the third blockchain network 1003 queries the operational status of the second blockchain network 1002 to forward the blockchain message when the second blockchain network 1002 is in an available state.

Optionally:

the block chain nodes in the third block chain network 1003 receive the management transaction, acquire the subnet identifier and the management instruction distributed to the second block chain network 1002 from the management transaction, and send the management instruction to the second block chain network 1002;

the block link point in the second blockchain network 1002 executes the management command when determining that the management command is sent by the master network corresponding to the block link point.

changing the operational state of second blockchain network 1002, managing blockchain nodes included in second blockchain network 1002, defining business rules for second blockchain network 1002, changing functional components used by second blockchain network 1002.

Optionally, the contracts include startup contracts or system contracts.

Optionally, the registration transaction and/or the anchor transaction are initiated by an administrator of the second blockchain network 1002.

Optionally, the first blockchain network 1001 does not have a corresponding master network; alternatively, the first blockchain network 1001 is a subnet of other blockchain networks to be managed by the other blockchain networks.

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. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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 forming a multi-tiered blockchain system based on a registration mechanism, comprising:

2. The method of claim 1, further comprising:

any block chain link point in a first block chain network receives a block chain message, wherein the block chain message comprises a subnet identification distributed to a second block chain network;

and the any block chain node in the first block chain network inquires the identity information of a second block chain network according to the subnet identification contained in the block chain message, and forwards the block chain message to the second block chain network.

3. The method of claim 2, wherein a block link point in a first block chain network further records an operational status of a second block chain network; the method further comprises the following steps:

and the any blockchain node in the first blockchain network inquires the running state of the second blockchain network so as to forward the blockchain message when the second blockchain network is in an available state.

4. The method of claim 1, further comprising:

a block chain node in a first block chain network receives a management transaction, acquires a subnet identifier and a management instruction distributed to a second block chain network from the management transaction, and sends the management instruction to the second block chain network;

and executing the management command by the block link point in the second block chain network under the condition that the management command is determined to be sent by the main network corresponding to the block link point.

5. The method of claim 4, the management instructions to implement at least one of:

the method comprises the steps of changing the running state of the second blockchain network, managing blockchain nodes contained in the second blockchain network, defining business rules of the second blockchain network and changing functional components used by the second blockchain network.

6. The method of claim 1, the registration transaction and/or the anchor transaction comprising a transaction that invokes a contract.

7. The method of claim 6, the contract comprising a startup contract or a system contract.

8. The method of claim 1, the registration transaction and/or the anchoring transaction initiated by an administrator of the second blockchain network.

9. The method of claim 1, the first blockchain network having no corresponding master network; or the first blockchain network is a subnet of other blockchain networks, so as to be managed by the other blockchain networks.

10. A method of forming a multi-tiered blockchain system based on a registration mechanism, comprising:

11. The method of claim 10, further comprising:

any block chain link point in a third block chain network receives a block chain message, wherein the block chain message comprises a subnet identifier distributed to a second block chain network;

and any block chain node in the third block chain network inquires the identity information of the second block chain network according to the subnet identification contained in the block chain message, and forwards the block chain message to the second block chain network.

12. The method of claim 11, wherein a block link point in the third block chain network further records an operational status of the second block chain network; the method further comprises the following steps:

and any blockchain node in the third blockchain network inquires the running state of the second blockchain network so as to forward the blockchain message when the second blockchain network is in an available state.

13. The method of claim 10, further comprising:

a block chain node in a third block chain network receives a management transaction, acquires a subnet identifier and a management instruction distributed to a second block chain network from the management transaction, and sends the management instruction to the second block chain network;

14. The method of claim 13, the management instructions to implement at least one of:

15. The method of claim 10, the registration transaction and/or the anchor transaction comprising a transaction that invokes a contract.

16. The method of claim 15, the contract comprising a startup contract or a system contract.

17. The method of claim 10, the registration transaction and/or the anchoring transaction initiated by an administrator of the second blockchain network.

18. The method of claim 10, the first blockchain network having no corresponding master network; or the first blockchain network is a subnet of other blockchain networks, so as to be managed by the other blockchain networks.

19. A blockchain system, comprising:

20. A blockchain system, comprising: