CN113609231A

CN113609231A - Method and device for maintaining network architecture information of block chain system

Info

Publication number: CN113609231A
Application number: CN202111167427.7A
Authority: CN
Inventors: 卓海振
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-09-30
Filing date: 2021-09-30
Publication date: 2021-11-05
Anticipated expiration: 2041-09-30
Also published as: CN113609231B; WO2023050986A1

Abstract

The present specification provides a method and an apparatus for maintaining network architecture information of a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used to describe the blockchain sub-network included in the blockchain system; the method is applied to a master network node in the block chain master network, and comprises the following steps: receiving a transaction to alter the network architecture information; in a network architecture Merkle tree generated based on the network architecture information, leaf nodes are subnet identifications corresponding to the block chain subnets in the block chain system; when a new block corresponding to the transaction is generated, anchoring the tree root of the network architecture Merkle tree at the block head of the new block, and writing the leaf node of the network architecture Merkle tree into the block body of the new block.

Description

Method and device for maintaining network architecture information of block chain system

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and in particular, to a method and an apparatus for maintaining network architecture information of a blockchain system.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Nodes in the blockchain network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their associated data. Therefore, the blockchain sub-network can be further established on the basis of the blockchain main network, so that a blockchain system comprising the blockchain main network and the blockchain sub-network is formed.

Since different block chain subnets are isolated from each other and cannot exchange information with each other in time, for a certain block chain subnet, it cannot know subnet information of other block chain subnets, and particularly when the network architecture of the block chain system changes, the network architecture information of the block chain system maintained by each block chain subnet is asymmetric, for example, a specific block chain subnet that has exited is mistaken to be still in a running state, thereby affecting normal operation of cross-chain interaction between block chain subnets.

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method, an apparatus, an electronic device, and a storage medium for maintaining and verifying network architecture information of a blockchain system.

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

according to a first aspect of one or more embodiments of the present specification, a method for maintaining network architecture information of a blockchain system is provided, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used for describing the blockchain sub-networks included in the blockchain system; the method is applied to a master network node in the block chain master network, and comprises the following steps:

receiving a transaction to alter the network architecture information; in a network architecture Merkle tree generated based on the network architecture information, leaf nodes are subnet identifications corresponding to the block chain subnets in the block chain system;

when a new block corresponding to the transaction is generated, anchoring the tree root of the network architecture Merkle tree at the block head of the new block, and writing the leaf node of the network architecture Merkle tree into the block body of the new block.

According to a second aspect of one or more embodiments of the present specification, there is provided a method for verifying network architecture information of a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used for describing the blockchain sub-network included in the blockchain system; the method comprises the following steps:

initiating an SPV verification request aiming at target information in the network architecture information to a full-scale main network node in the block chain main network, wherein a main network block maintained by the full-scale main network node is recorded with a network architecture Merkle tree generated based on the network architecture information, a block head is used for anchoring a tree root of the network architecture Merkle tree, a block body is recorded with leaf nodes of the network architecture Merkle tree, and the leaf nodes of the network architecture Merkle tree are subnet identifications corresponding to block chain subnets in the block chain system;

receiving verification auxiliary information which is determined and returned by the full-scale main network node from the network architecture Merkle tree;

and performing SPV verification on the target information based on the verification auxiliary information and the block header of the main network block maintained by the SPV main network node.

According to a third aspect of one or more embodiments of the present specification, an apparatus for maintaining network architecture information of a blockchain system is provided, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used for describing the blockchain sub-networks included in the blockchain system; the apparatus is applied to a master network node in the blockchain master network, and the apparatus includes:

a framework change unit for receiving a transaction for changing the network framework information; in a network architecture Merkle tree generated based on the network architecture information, leaf nodes are subnet identifications corresponding to the block chain subnets in the block chain system;

and the block generating unit is used for anchoring the tree root of the network architecture Merkle tree at the block head of the new block and writing the leaf node of the network architecture Merkle tree into the block body of the new block when generating the new block corresponding to the transaction.

According to a fourth aspect of one or more embodiments of the present specification, there is provided an apparatus for verifying network architecture information of a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used for describing the blockchain sub-network included in the blockchain system; the device comprises:

a request unit, configured to initiate an SPV verification request for target information in the network architecture information to a full-volume master network node in the block chain master network, where a network architecture Merkle tree generated based on the network architecture information is recorded in a master network block maintained by the full-volume master network node, a block head is used to anchor a tree root of the network architecture Merkle tree, a block body is recorded with leaf nodes of the network architecture Merkle tree, and the leaf nodes of the network architecture Merkle tree are subnet identifiers corresponding to a block chain subnet in the block chain system;

the receiving unit is used for receiving verification auxiliary information which is determined and returned by the total main network node from the network architecture Merkle tree;

and the verification unit is used for performing SPV verification on the target information based on the verification auxiliary information and the block header of the main network block maintained by the SPV main network node.

According to a fifth aspect of embodiments herein, there is provided an electronic apparatus including:

a processor; a memory for storing processor-executable instructions; the processor executes the executable instructions to implement the steps of the method for maintaining or verifying the network architecture information of the blockchain system.

According to a sixth aspect of embodiments herein, there is provided a computer-readable storage medium having stored thereon executable instructions; wherein the instructions, when executed by the processor, implement the steps of the method for maintaining or verifying network architecture information of a blockchain system.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.

Drawings

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

Fig. 2 is a flowchart of a method for maintaining network architecture information of a blockchain system according to an exemplary embodiment.

Fig. 3 is a schematic structural diagram of a Merkle tree in a network architecture according to an exemplary embodiment.

Fig. 4 is a schematic structural diagram of a subnet Merkle tree according to an exemplary embodiment.

Fig. 5 is a schematic structural diagram of another subnet Merkle tree provided in an exemplary embodiment.

Fig. 6 is a flowchart of a method for verifying network architecture information of a blockchain system according to an exemplary embodiment.

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

Fig. 8 is a block diagram of an apparatus for maintaining network architecture information of a blockchain system according to an exemplary embodiment.

Fig. 9 is a block diagram of an apparatus for verifying network architecture information of a blockchain system according to an exemplary embodiment.

Detailed Description

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

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

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

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 link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in establishing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to reveal the configuration information, and when the configuration information comprises identity information of a node member corresponding to a first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on an innovation block comprising the configuration information.

For example, as shown in fig. 1, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build 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, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, regardless of the administrator or the general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, 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 building a blockchain subnet1 on subnet0 shown in fig. 1, subnet0 may be considered to be at a first level and subnet1 may be considered to be at a 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. 1 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification may also be a subnet of another blockchain network, for example, another blockchain subnet may be further configured on the basis of the subnet1 in fig. 1, and at this time, the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect that the subnet1 belongs to the blockchain subnet created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

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, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, which is not limited by this 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 the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet 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 master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is constructed, the first master network node does not directly participate in the construction of the blockchain subnet and becomes a node member thereof, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member in the blockchain subnet by the first subnet node. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node 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 main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 1, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and at this time, all the blockchain 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 blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

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

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

Event：

[topic][data]

......

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

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

It can be seen that the execution result of the Subnet 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 AddSubnet () 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, nodeA to nodeE can determine to monitor the event related to executing the AddSubnet () method, that is, the networking event, when the topic including the keyword subnet is monitored by monitoring topic included in each event in the generated receipt. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the nodeA-nodeE monitors the 1 st event, the event is determined to be irrelevant to the AddSubnet () method because the contained topic content is other; and when the 2 nd event is monitored by the nodeA to nodeE, determining that the event is related to the AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field comprises 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, nodeA-nodeE can determine whether the subnet1 already exists according to the recorded network identifiers of all the created subnet block chains; 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. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. 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 further loads the generated created block by nodeA1, 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 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so that the node device 1 becomes 1 subnet node in 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 node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt 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.

The node device realizes the deployment of a blockchain node on the node device by creating an instance of running blockchain platform codes in the process. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. 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 first subnet 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. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 1 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as new blockchain main networks, and a blockchain subnet is further constructed on the basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again. As can be seen, in the manner of initiating a transaction on the blockchain main network to select a node member to create a blockchain subnet, the subnet nodes of the newly created blockchain subnet can all be deployed on the node device where the main network node of the blockchain main network is located, that is, from the perspective of the slave node device, the node device where the subnet node of the blockchain subnet is located belongs to the subset of the node device where the main network node is located, in other words, the main network node in the blockchain main network is deployed on the node device where the subnet node of the blockchain subnet is located.

In addition to the above-mentioned manner of selecting a node member to create a blockchain subnet by initiating a transaction on the blockchain main network, the blockchain subnet may be created by other means and managed by the blockchain main network. For example, a block chain sub-network (hereinafter referred to as a registration networking mode for short) may be established on the block chain main network through a registration mode, and an existing block chain network is directly registered to the block chain main network, so that the newly registered block chain network is managed by the block chain main network, and the newly registered block chain network becomes the block chain sub-network of the block chain main network. By means of the registration networking mode, subnet information of a block chain subnet to be established is directly registered to a block chain main network, so that the block chain main network obtains relevant information of the block chain subnet to be established (by receiving and executing a transaction which is sent by the block chain network to be established and used for carrying out association storage on identity information of the block chain subnet to be established and a subnet identifier distributed to the block chain network to be established), such as a subnet identifier and an operation state of the block chain subnet to be established, wherein public keys and plug-in configuration information of each node member, IP addresses and port information of each node device and the like, the information can be written into a contract state of a system contract corresponding to the block chain main network, and therefore the block chain main network obtains a management right of the block chain subnet to be established, and after the registration is completed, the block chain subnet establishment is completed. Since the registration networking manner does not require designating node members to form a blockchain subnet on the blockchain main network through transactions, subnet nodes in the blockchain subnet constructed through the registration networking manner may be completely or partially different from node devices disposed at each node in the blockchain main network, for example, subnet0 in fig. 1 creates a subnet4 in the registration networking manner, and assuming that main network nodes nodeA to nodeE included in the subnet0 themselves are respectively disposed at the node devices 1 to 5, a subnet node corresponding to the subnet4 may be disposed at any node device other than the node devices 1 to 5, or one or more subnet nodes in the subnet4 may be respectively disposed at any node device within the node devices 1 to 5 (it is still required to ensure that only one subnet node in the subnet4 is disposed on one node device), and other subnet nodes in the subnet4 are disposed at any node device other than the node devices 1 to 5, of course, the subnet nodes in subnet4 may all be deployed in node devices 1 to 5.

As mentioned above, in any way, different blockchain subnets created on the blockchain main network are independent and isolated from each other, for example, the transactions commonly identified on subnet1 are only eventually received by nodeA 1-nodeD 1, but not nodeA2, nodeB2, nodeC2 and nodeE2 in subnet2, so that different blockchain subnets logically belong to different blockchain networks, which makes the blockchain subnets have a need for information interaction, whereas for a blockchain subnet, subnet information of other blockchain subnets needs to be obtained before information interaction with other blockchain subnets, so as to ensure the correctness of information interaction, especially the existence information of the blockchain subnet currently contained in the entire blockchain main network needs to be obtained, and the network information block of the entire blockchain system including the blockchain main network and the blockchain main network, thereby preventing information interaction with the blockchain subnet which has exited the blockchain system from causing network failure. In order for the blockchain subnet to acquire the network architecture information of the blockchain system, the blockchain subnet generally needs to request the blockchain main network managing each blockchain subnet to acquire the network architecture information, the block chain main network and the block chain sub network belong to logically independent block chain networks, so that information interaction is also completed through a cross-chain technology if necessary, such as traditional chain-crossing technologies based on side chain technology, witness mechanism or relay technology, however, these chain-crossing technologies are usually complicated and time-consuming in the process of specific implementation, moreover, the conventional cross-link technology does not consider the difference between the cross-link scenario of the blockchain sub-network and the blockchain main network and the conventional cross-link scenario, this makes it necessary to pass through traditional cross-chaining technique between the blockchain sub-network and the blockchain main network to be able to implement the trusted verification of the blockchain data.

Therefore, the present specification provides a method for maintaining and verifying network architecture information of a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used to describe the blockchain sub-network included in the blockchain system, and a Merkle tree formed by the network architecture information is anchored on a block maintained by the blockchain main network, so that when any verifier needs to verify the network architecture information in the blockchain system, the verification can be achieved only by acquiring the block maintained by the blockchain main network or verification auxiliary information extracted from the block, and complex cross-chain interaction, intelligent contract invocation, and other processes are not required, and a method for maintaining and quickly verifying existence of the blockchain sub-network based on the blockchain information is implemented.

Fig. 2 is a flowchart of a method for maintaining network architecture information of a blockchain system according to an exemplary embodiment. The block chain system comprises a block chain main network and a block chain sub-network managed by the block chain main network, and the network architecture information is used for describing the block chain sub-network contained in the block chain system; the method is applied to a master network node in the block chain master network, and comprises the following steps:

step 202: receiving a transaction to alter the network architecture information; in the network architecture Merkle tree generated based on the network architecture information, the leaf nodes are subnet identifications corresponding to the subnet of the blockchain in the blockchain system.

The blockchain system according to the embodiment of the present disclosure refers to a blockchain system formed by a blockchain main network and a blockchain sub-network managed by the blockchain main network, for example, a blockchain system formed by a subnet0, a subnet1, and a subnet2 shown in fig. 1, where the subnet0 is the blockchain main network and the subnet1 and the subnet2 are blockchain sub-networks, the main node of the subnet0 includes nodeA, nodeB, nodeC, nodeD, and nodeE, the sub-network node in the subnet1 includes nodeA1, nodeB1, nodeC1, and nodeD1, and the sub-network node in the subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE 2. The subnet0 can manage subnet1 and subnet2, which is shown in the following: the subnet management transaction can be initiated on the subnet0, so that each master network node executes the subnet management transaction and generates a corresponding subnet management event, and the subnet nodes in each blockchain subnet in the blockchain system acquire the subnet management event generated by the master network node (specifically, for the subnet nodes where the master network nodes are all deployed, the subnet management event generated by the master network node deployed on the same device can be directly acquired by monitoring, and for the subnet nodes where the node devices where the subnet nodes are not deployed, the corresponding subnet management event needs to be acquired to the relay node where the master network node is deployed), thereby implementing information transfer from the blockchain master network to the blockchain subnet, and implementing corresponding management operation for the blockchain subnet based on the subnet management event. For example, after the master node nodeb has performed the subnet management transaction and generated the corresponding subnet management event, the subnet nodes nodeb1 and nodeb2, which are located in the node device 1 together with nodeb, can acquire the subnet management event, thereby implementing the corresponding management operation.

The network architecture information according to the embodiment of the present disclosure is used to describe the blockchain subnets included in the blockchain system, and specifically, the network architecture information may be in the form of a network list to show subnet identifications of the blockchain subnets included in the blockchain system, and is maintained at each main network node in the blockchain main network (for example, in an intelligent contract or in blockchain platform code), for example, for the subnet0 shown in fig. 1, the network architecture information { subnet1, subnet2} of the blockchain system is maintained for each main network node nodeA to node e included in the blockchain main network subnet0, that is, the blockchain subnets included in the blockchain main network subnet1 and subnet2, and of course, the network architecture information may also be used to describe the blockchain subnets included in the blockchain system, and in the form of a network list, the network architecture information may also be denoted as { subnet0, subnet1, subnet2 }; further, the network architecture information may also be used to describe the master network node included in the blockchain master network and the subnet node included in the blockchain subnet, and may be represented as { { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} }.

As previously described, in the present embodiment, each master node in the blockchain master, upon completion of consensus on receipt of the subnet management transaction, the subnet management transaction will be executed and a subnet management event triggered to be generated will be written in the receipt corresponding to the subnet management transaction, in which the change information brought by the management operation corresponding to the subnet management transaction is recorded, for example, for a subnet registration transaction, the generated subnet registration event is triggered to record the network identifier corresponding to the newly generated blockchain subnet and the identity information of the node members (such as the node public key), since the subnet management event records the change information of the state change of the blockchain subnet caused by the management operation or the changed subnet information, therefore, the latest subnet information of the block chain subnet can be obtained through the information carried in the subnet management event.

For example, the aforementioned transaction for building the blockchain subnet belongs to a sub-network management transaction, and an administrator can initiate a transaction for building the blockchain subnet on the blockchain main network, so that each main network node in the blockchain main network executes the transaction to generate a networking event, and each node device with the main network node deployed determines whether to start a new blockchain node or not by monitoring the networking event and according to configuration information carried by the networking event, so that a node device meeting corresponding requirements starts the new blockchain subnet node, thereby forming a new blockchain subnet. Therefore, under the scenario of a scheme of implementing management of a blockchain subnet by initiating a subnet management transaction on a blockchain main network, due to the independence of transaction consensus between the blockchain main network and the blockchain subnet, a subnet management transaction is only sent to each main network node on the blockchain main network, but a blockchain subnet or node device really needs to perform management operation, so it can be understood that initiating a subnet management transaction plays a role in communicating management messages to each node device deployed with a main network node, and finally the complete execution of a management operation depends on the event monitoring mechanism and the mutual participation of each node device deployed with a main network node, that is, a node device where a main network node is located, other subnet nodes deployed on the node device, or subnet nodes not deployed with a main network node on the located node device execute corresponding management operations by monitoring and responding to a subnet management event, to enable management of blockchain subnets. In this embodiment of the present specification, generating an externally open subnet management event on each master network node is a main technical idea of implementing management of a blockchain subnet by initiating a transaction on a blockchain master network, and is an important means for converting a management transaction on a chain into a management instruction under the chain, where any node device with the master network node deployed and/or a subnet node deployed on any node device executes a management operation corresponding to the monitored subnet management event.

And after the main network node receives the transaction for changing the network architecture information, updating the network architecture information maintained by the main network node according to the transaction. The transaction for changing the network architecture information according to the embodiment of the present specification, that is, belonging to a sub-network management transaction, may include at least one of the following: the method comprises a subnet registration transaction for creating a new blockchain subnet, a subnet exit transaction for deleting an existing blockchain subnet, a subnet start-stop transaction for changing the running state of the existing blockchain subnet, a subnet node adjustment transaction for adjusting node members of the existing blockchain subnet, and a master network node adjustment transaction for adjusting node members of the blockchain master network. The main network node can identify the transaction type of the transaction through the received transaction type field of the transaction, and after the main network node receives the transaction for changing the network architecture information, necessary network architecture change indication information is obtained from the transaction so as to update the network architecture information maintained by the main network node.

The subnet registration transaction comprises the transaction for establishing the blockchain subnet and the transaction for associating and storing the identity information of the existing blockchain network and the subnet identification distributed to the existing blockchain network related to the registration networking mode. After receiving the subnet registration transaction, the master node updates the network architecture information maintained by the master node based on the subnet identifier included in the subnet registration transaction or the identity information of the subnet node, for example, assuming that a subnet registration transaction for creating a subnet3 is initiated to the subnet0 in fig. 1, and the corresponding node members are nodeA3 and nodeB3, then after receiving the subnet registration transaction, each master node updates the network architecture information maintained by the master node from { subnet1, subnet2} to { subnet1, subnet2, subnet3} in the case that the network architecture information is only used for describing a blockchain subnet included in the blockchain system; in the case where the network architecture information is also used to describe the nodes included in the blockchain master and blockchain subnets, each master node will maintain the network architecture information as set forth by { { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} } to { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, node 2}, { subnet 3: nodeA3, nodeB3} }. The effect of the subnet start-stop transaction for changing the running state of the existing blockchain subnet into the open state is similar to the subnet registration transaction, and is not described herein again.

Similarly, if a subnet deletion transaction for exiting subnet2 is initiated to subnet0 in fig. 1, each master network node will update its maintained network architecture information from { subnet1, subnet2} to { subnet 1} in the case that the network architecture information is only used to describe the blockchain subnet included in the blockchain system after receiving the subnet deletion transaction. The effect of the subnet start-stop transaction for changing the running state of the existing blockchain subnet into the closed state is similar to the subnet deletion transaction, and is not described herein again.

For example, assuming that a subnet node adjustment transaction for adjusting a node member of subnet1 is initiated to subnet0 in fig. 1 and indicates to delete nodeA1, after each master node receives the subnet registration transaction, if the network architecture information is also used to describe nodes included in the blockchain master network and the blockchain subnet, the maintained network architecture information is represented by { { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} } to { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeB1, nodeC1, nodeD1, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} }.

For example, if a master node adjustment transaction is initiated to subnet0 in fig. 1 and indicates to add a nodeF, after each master node receives the subnet registration transaction, if the network architecture information is also used to describe the nodes included in the blockchain master network and the blockchain sub-network, the maintained network architecture information is represented by { { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} } to { subnet 0: nodeA, nodeB, nodeC, nodeD, nodeE, nodeF }, { subnet 1: nodeA1, nodeB1, nodeC1, nodeD1}, { subnet 2: nodeA2, nodeB2, nodeC2, nodeE2} }.

Meanwhile, the transaction for changing the network architecture information is used as a sub-network management transaction, and after the transaction is initiated to a blockchain main network and executed by each main network node, a network architecture change event corresponding to the transaction is generated, as described above, the network architecture change event belongs to a sub-network management event, and is used for indicating a node device where the main network node is located to execute corresponding node start-stop operation based on execution, so that the network architecture of the blockchain system is matched with the changed network architecture information, and the network architecture includes the existence state and/or the operation state of the blockchain main network and the blockchain sub-network in the blockchain system. For example, assuming that a subnet deletion transaction for exiting the subnet2 is initiated to the subnet0 in fig. 1, after the subnet registration transaction is completed and executed, each master node generates a network architecture change event, and since the master node is disposed on the node device where any subnet node in the subnet2 is located, after monitoring the network architecture change event generated by the master node disposed on the node device where the node device 1, the node device 2, the node device 3, and the node device 5 respectively, the slave node deletes the respective disposed nodeA2, nodeB2, nodeC2, and nodeE2 based on the indication information describing deletion of the subnet2 carried in the network architecture change event, so as to delete the subnet2, so that the network architecture of the block chain system after executing the subnet deletion transaction matches the network architecture information after being changed by the transaction. The other transaction processes for changing the network architecture information are basically the same, and the execution results thereof all cause the network architecture of the blockchain system to be capable of matching with the changed network architecture information, which is not described herein again.

As is common in the art, a Merkle tree is a binary Hash tree, which was invented by Ralph Merkle in 1979, stores data in leaf nodes of a tree structure, and ensures non-tamper-ability of data through a step-by-step Hash (Hash) operation on the data. Any change in the leaf node data is passed on to the node at the previous level and ultimately reflects the change to the root of the tree.

The Merkle tree of the network architecture related to the embodiment of the present specification is generated by a main network node based on network architecture information maintained by the main network node, and leaf nodes of the Merkle tree are subnet identifications corresponding to subnet of a blockchain in the blockchain system. Since the Merkle tree has the following properties: only the sequentially arranged leaf nodes need to be known to construct a complete Merkle tree. Therefore, only the leaf node of the network architecture Merkle tree needs to be determined, so as to generate the network architecture Merkle tree, whereas in the embodiment of the present specification, the subnet identifier of the blockchain subnet directly or indirectly recorded in the network architecture information, and the main network node may determine the leaf node from the network architecture information maintained by the main network node itself to generate the network architecture Merkle tree. Specifically, subnet identifications (or hash values corresponding to the subnet identifications) of each blockchain subnet in a blockchain system are used as leaf nodes of a Merkle tree to be generated to perform step-by-step hash combination to generate the Merkle tree, and in the case that a plurality of leaf nodes exist, the Merkle tree is used as an ordered tree, and the leaf nodes are required to be arranged according to a preset sequence and then perform step-by-step hash combination to generate the Merkle tree, wherein one leaf node corresponds to a subnet identification of one blockchain subnet, and the preset sequence is a creation sequence of the blockchain subnets corresponding to each leaf node. Taking fig. 3 as an example, fig. 3 is a schematic structural diagram of a network architecture Merkle tree provided in an exemplary embodiment, in this embodiment, a blockchain system includes 4 blockchain subnets, and then the network architecture Merkle tree constructed and generated by the blockchain system includes 4 leaf nodes, where the 4 leaf nodes correspond to subnet identifiers of the 4 blockchain subnets included in the blockchain system one by one and are arranged from left to right according to a sequence of creation of the corresponding blockchain subnets, as shown in fig. 3, the 4 leaf nodes are first paired two by two to perform hash merging once to obtain 2 intermediate nodes, and then the 2 intermediate nodes (also called branch nodes) are further subjected to hash merging once to obtain a root node, that is, a root of the Merkle tree, thereby generating a complete network architecture Merkle tree.

Step 204: when a new block corresponding to the transaction is generated, anchoring the tree root of the network architecture Merkle tree at the block head of the new block, and writing the leaf node of the network architecture Merkle tree into the block body of the new block.

In the embodiment of the present specification, generation of a new block depends on packaging a preset number of transactions, and in the related art, when a block link point generates a new block, a predetermined number of transactions selected from a transaction pool need to be written into a block body of the new block, at the same time, a root (referred to as a transaction root) corresponding to a transaction Merkle tree constructed according to the transactions, a root (referred to as a receipt root) of a receipt Merkle tree constructed according to receipts corresponding to the transactions, and a root (referred to as a state root) of a state Merkle tree constructed according to a world state are written into a block head of the new block, and information such as a hash value of the block, a hash value of a previous block, and a hash value of a consensus algorithm is written into the block head, so that a block is finally generated to be spliced on an original block link.

In this embodiment of the present disclosure, when the primary network node needs to generate a new block obtained by packaging the transaction (i.e. the transaction for changing the network architecture information), in addition to the above-mentioned generation process of the new block in the prior art, the following process is additionally included: anchoring the tree root of the network architecture Merkle tree at the block head of the new block, and writing the leaf node of the network architecture Merkle tree into the block body of the new block. On the basis of such a block generation method, any block in a block chain maintained by a block chain main network contains a corresponding network architecture Merkle tree, and the network architecture Merkle tree contains network architecture information of a block chain system, so that the block generated by the block generation method can assist a verifier in verifying the network architecture information.

In an embodiment, the master network node maintains a dynamically changing network architecture information, and also maintains a dynamically changing network architecture Merkle tree (including leaf nodes, branch nodes, and root nodes of the network architecture Merkle tree), so that the master network node updates the network architecture Merkle tree maintained by the master network node in real time when receiving a transaction for changing the network architecture information each time to change the network architecture information maintained by the master network node. In another embodiment, the master network node only maintains dynamically changing network architecture information, but does not dynamically maintain a network architecture Merkle tree, and when a new block needs to be generated, the master network node temporarily generates the network architecture Merkle tree based on the network architecture information, thereby reducing the computing cost for maintaining the network architecture Merkle tree in real time.

According to the embodiment of the specification, the network architecture information is changed in time when a transaction for changing the network architecture information is received, and the Merkle tree generated based on the network architecture information is anchored on the block maintained by the block chain main network, so that when any verifier needs to verify the network architecture information in the block chain system, the verification can be realized only by acquiring the block maintained by the block chain main network or verification auxiliary information extracted from the block, complex cross-chain interaction, intelligent contract calling and other processes are not needed, and the method for maintaining and quickly verifying the existence of the block chain sub-network based on the block information is realized.

Optionally, the anchoring the root of the Merkle tree of the network architecture to the block head of the new block includes: writing the tree root of the network architecture Merkle tree into the block head of the new block; or, taking the tree root of the network architecture Merkle tree as a leaf node of the state tree corresponding to the new block, and writing the calculated state root into the block head of the new block. In the embodiment of the present specification, when anchoring the root of the network architecture Merkle tree to the block head of the new block, two ways may be adopted, one way is to directly store the root of the network architecture Merkle tree as an individual field in the block head, so that the status of the root of the network architecture Merkle tree is the same as the transaction root, the state root and the receipt root in the block head, and this way can facilitate the verifier to perform less verification calculation when verifying the network architecture information (only calculating from the leaf node of the network architecture Merkle tree to the root of the network architecture Merkle tree); in another way, the root of the Merkle tree of the network architecture is used as a leaf node of the state tree corresponding to the new block, and a state root anchored with the root of the Merkle tree of the network architecture is calculated, so that the verifier performs more verification calculation processes (from the leaf node of the Merkle tree of the network architecture to the root of the Merkle tree of the network architecture and then to the state root of the state tree) when needing to verify the information of the network architecture, but the method is equivalent to deeply binding the Merkle tree with isolation function and other transactions changing the world state in the block, and the transactions are used as the trust certificate of the Merkle tree of the network architecture, so as to improve the credibility of the verifier to the Merkle tree of the network architecture corresponding to the block.

Optionally, the network architecture information is further used to describe node members included in the blockchain subnet; the subnet identification corresponding to any block chain subnet comprises: a node member information set corresponding to any block chain sub-network or a tree root of a sub-network Merkel tree; and the node member information set and the leaf nodes of the subnet Merkle tree are respectively used for representing the subnet nodes contained in any block chain subnet. In this embodiment, the network architecture information further includes node members included in each blockchain subnet, and the subnet identifier as a leaf node of the Merkle tree of the network architecture is used to represent subnet nodes included in any blockchain subnet, that is, the leaf node of the Merkle tree of the network architecture can not only represent the blockchain subnet included in the blockchain system, but also represent corresponding node members in the corresponding blockchain subnet. The subnet identifier corresponding to any blockchain subnet may include a node member information set corresponding to the blockchain subnet or a tree root of the subnet Merkel tree, where the node member information set may be a node member list of the corresponding blockchain subnet, for example, leaf nodes of a network architecture Merkel tree generated by a main network node in the subnet0 in fig. 1 may be set as a node member list { node a1, node b1, node c1, node d1} of the subnet1 and a node member list { node a2, node b2, node c2, node e2} of the subnet2, respectively, or a hash value of the corresponding node member list. Therefore, the main network node can determine the values of the leaf nodes of the network architecture Merkle tree based on the network architecture information maintained by the main network node, so that the Merkle tree containing the network architecture information is further generated. Obviously, the network architecture information contained in the Merkle tree of the network architecture is richer, so that the verification party can be assisted in verifying more network architecture information including the sub-network node members.

Optionally, a master network node in the block chain master network is deployed on a node device where a subnet node in any block chain subnet is located; the node member information set comprises a character string, character bits of the character string correspond to the master network nodes in the block chain master network one by one, and values of the character bits are used for representing whether the node equipment where the corresponding master network node is located is provided with the sub-network node in any block chain sub-network or not. In this embodiment of the present specification, it is required that a master network node in a block chain master network is deployed on a node device where a subnet node in any block chain subnet is located, in this scenario, the master network node may convert node member information of any block chain subnet in network architecture information into a character string form for representing the subnet node included in any block chain subnet, where the character string satisfies the following form requirement: the bit number of the character string is that the number of main network nodes in a block chain main network is the same; character bits in the character string correspond to the master network nodes in the block chain master network one by one, and values of the character bits (for example, a value of "0" indicates that the master network node is not deployed, and a value of "1" indicates that the master network node is deployed) are used for indicating whether the sub-network nodes in any block chain sub-network are deployed on the node device where the corresponding master network node is located; and arranging the character positions in the character string according to a preset sequence, wherein the preset sequence comprises the sequence of the character positions corresponding to the node serial number of the main network node or the sequence of the character positions corresponding to the equipment serial number of the node equipment where the main network node is located. For example, the main network node in subnet0 in fig. 1, the generated network architecture Merkle tree includes 2 leaf nodes, and the left to right are the node member information set corresponding to subnet1 and the node member information set of subnet2, respectively, where a character string corresponding to the node member information corresponding to subnet1 is "11110" and is used to represent that the subnet node in subnet1 is deployed on node device 1, node device 2, node device 3, and node device 4, respectively, and a character string corresponding to the node member information corresponding to subnet2 is "11101" and is used to represent that the subnet node in subnet2 is deployed on node device 1, node device 2, node device 3, and node device 5, respectively. In the embodiment of the present specification, a character string containing node member information of a blockchain subnet is used as a leaf node of a Merkle tree of a network architecture, so that a tree root of the Merkel tree of the network architecture is anchored with member information of each blockchain subnet, and a proof of existence of any blockchain subnet node member can be provided to a verifier.

Optionally, the leaf nodes in the subnet Merkel tree correspond to the subnet nodes included in any blockchain subnet one by one. In the embodiment of the present specification, the subnet identifier used as the leaf node of the network architecture Merkle tree is specifically the root of the subnet Merkel tree of the blockchain subnet, and therefore, the root of the network architecture Merkle tree actually anchors the subtree Merkle tree corresponding to each blockchain subnet, thereby including all network architecture information including each subnet node member. In this embodiment, it is not required that the node device where the subnet node in any block chain subnet is located is deployed with a master network node in the block chain master network, the leaf nodes of the subtree Merkle tree corresponding to any block chain subnet are only determined by the subnet node of any block chain subnet, specifically, the leaf nodes of the subtree Merkle tree correspond to the subnet nodes included in any block chain subnet one by one, and each leaf node needs to be arranged according to a preset sequence to form the subnet Merkle tree, the preset sequence may include a sequence of node numbers of the subnet nodes corresponding to each leaf node or a sequence of device numbers of the located node devices, and a value of any leaf node may be identity information of the corresponding subnet node, such as a node public key or a node identifier, or any related information associated with the subnet node, this specification does not put any limitation on it. As shown in fig. 4, fig. 4 is a schematic structural diagram of a subnetwork Merkle tree provided in an exemplary embodiment, and it is assumed that a blockchain subnetwork corresponding to the subnetwork Merkle tree shown in the diagram includes 4 subnetwork nodes, which are respectively node1, node3, node5 and node7, so that 4 leaf nodes corresponding to the subnetwork Merkle tree respectively correspond to node1, node3, node5 and node7 and are arranged in the illustrated order, and specific values thereof may be node public keys (or hash values of nodes) corresponding to node1, node3, node5 and node7 respectively from left to right, in this embodiment, the 4 leaf nodes are combined by two hashes to finally obtain a tree root of a root node Merkle tree, so as to generate a complete subnetwork Merkle tree, and it should be noted that generation of the subnetwork tree is also generated by a network tree structure maintained by a master network node based on information of the network tree, and a similar network tree generation manner, the tree root of the subtree Merkle tree is used as a leaf node of the network architecture Merkle tree, so that two trees are connected in series, and the tree root of the network architecture Merkle tree can be finally anchored with the block chain sub-network contained in the block chain system and the node members contained in each block chain sub-network.

Optionally, a master network node in the block chain master network is deployed on a node device where a subnet node in any block chain subnet is located; leaf nodes in the subnet Merkel tree correspond to the main network nodes in the blockchain main network one by one, and the leaf nodes in the subnet Merkel tree are used for representing whether the node equipment where the corresponding main network node is located is provided with the subnet node in any blockchain subnet. In this embodiment of the present specification, it is required that a master network node in a block chain master network is deployed on a node device where a subnet node in any block chain subnet is located, in this scenario, leaf nodes of a subtree Merkle tree corresponding to any block chain subnet are determined by the subnet node of any block chain subnet and the master network node in the block chain master network, specifically, leaf nodes of the subtree Merkle tree correspond to the master network node included in the block chain master network one by one, and each leaf node needs to be arranged according to a preset order to form the Merkle tree, where the preset order may include an order of node numbers of the master network node corresponding to each leaf node or an order of device numbers of the located node devices, and a value of any leaf node may be identity information of the subnet node in the node device where the corresponding master network node is located, or the flag information is used to characterize whether the node device where the corresponding main network node is located is deployed with the subnet node in any block chain subnet, which is not limited in this specification. As shown in fig. 5, fig. 5 is a schematic structural diagram of another subnet Merkel tree provided in an exemplary embodiment, assuming that a block chain subnet corresponding to the subnet Merkel tree shown in the diagram includes 4 subnet nodes, and the device serial numbers of the node devices in the subnet are respectively node1, node3, node5 and node7, whereas in this embodiment, a block chain master network includes 8 master nodes, and the device serial numbers of the node devices in the subnet are respectively node1, node2, node3, node4, node5, node6, node7 and node8, then 8 leaf nodes corresponding to the subnet Merkel tree respectively correspond to node 1-node 8 and are arranged in the illustrated order, and their specific values may be "existant", "node-existant" and "are respectively deployed in the subnet chain, where" the subnet node is used for any subnet node of the subnet node-existant tree "and" node-node "deployed in the subnet, and the non-existence is used for representing that the corresponding node equipment is not provided with the subnet nodes in any block chain subnet. In this embodiment, the root node, that is, the tree root of the subnet Merkle tree, is finally obtained by three times of hash merging for 8 leaf nodes, so as to generate a complete subnet Merkle tree, it should be noted that the generation of the subnet Merkle tree is also generated by the main network node based on the network architecture information maintained by itself, and two trees are connected in series by using the tree root of the subtree Merkle tree as the leaf node of the network architecture Merkle tree, so that the tree root of the network architecture Merkle tree can finally anchor the blockchain subnets included in the blockchain system and the node members included in each blockchain subnetwork.

Optionally, the method further includes: and writing the leaf nodes of the subnet Merkel tree into the zone blocks of the new blocks under the condition that the leaf nodes of the network architecture Merkel tree are the tree roots of the subnet Merkel tree. Through the embodiment of the specification, the main network node can restore the subnet Merkle tree based on the leaf node of the subnet Merkle tree recorded in the zone block under the condition that the leaf node of the network architecture Merkle tree is the tree root of the subnet Merkle tree, and because the subnet Merkle tree contains the node member information of the subnet of the corresponding zone chain, the main network node can subsequently provide the existence certification about the internal subnet node in the zone chain subnet, thereby providing more types of network architecture information verification services for a verifier.

Optionally, the method further includes: and writing the branch nodes of the network architecture Merkle tree into the block body of the new block. As mentioned above, when the master node generates a new block corresponding to the transaction, it writes the leaf nodes of the Merkle tree of the network architecture into the block body of the new block, in the embodiment of the present specification, the main network node will write not only the leaf node of the network architecture Merkle tree but also the branch node of the network architecture Merkle tree into the block, therefore, when the main network node needs to restore the network architecture Merkle tree corresponding to the block in the following, the network architecture Merkle tree is generated without carrying out the hash combination step by step from the leaf nodes, but the network architecture Merkle tree can be directly restored based on the leaf nodes and the branch nodes recorded in the block, and especially when the subsequent main network node needs to provide verification auxiliary information for verifying the network architecture information to a verifier, the calculation burden of the main network node can be greatly reduced, and the verification efficiency is accelerated. Similarly, when the leaf node of the network architecture Merkle tree is the tree root of the subnet Merkel tree, the branch node of the subnet Merkel tree is written into the zone block of the new zone block, so that the subnet Merkle tree can be conveniently and rapidly restored by the main network node.

Optionally, the method further includes: receiving an SPV verification request initiated aiming at target information in the network architecture information; and determining corresponding verification auxiliary information from the network architecture Merkle tree, and returning the verification auxiliary information to the initiator of the SPV verification request. In the embodiment of the present specification, SPV (simple Payment Verification) refers to a technology that requests a full node (a blockchain node maintaining a complete blockchain including a blockhead and a blockbody) from a light node (i.e., only a blockchain link point maintaining a blockhead in a blockchain, also referred to as SPV node) to verify the existence of data on a chain, and the implementation process mainly utilizes the property of a Merkle tree, and since only a unique set of leaf nodes arranged in a predetermined order can generate a unique corresponding tree root, the existence and the non-tampering of the leaf nodes can be determined by using a manner of requesting to recalculate the Merkle root and comparing the tree root with a reference tree root. In the embodiment of the present specification, a master network node that generates a new block is used as a full node, which maintains a complete block chain corresponding to a block chain master network, and when the master network node receives an SPV authentication request initiated for target information in the network architecture information, the master network node first determines a block height of a target block that the SPV authentication request needs to authenticate, then finds a target block corresponding to the block height, and restores a network architecture Merkle tree based on leaf nodes of the network architecture Merkle tree recorded in a block body of the target block, and then further finds a path where the target information is located in the network architecture Merkle tree, and selects leaves and/or branches of a tree root for fast recalculating the network architecture Merkle node according to the path of the leaf node as authentication auxiliary information under the condition that the target information includes values of leaf nodes corresponding to leaf nodes of a to-be-authenticated block chain subnet in the network architecture Merkle tree, and returning the verification request to the initiator of the SPV verification request, the initiator may recalculate the tree root of the network architecture Merkle tree by verifying the auxiliary information and the target information, and compare the tree root with the tree root (i.e., the reference tree root) of the network architecture Merkle tree in the block header of the target block maintained by the initiator, and in case of a comparison match, may consider that the to-be-verified block chain subnet exists in the current block chain system.

Optionally, the initiator of the SPV authentication request includes: an SPV master network node in the block chain master network; or, the sub-network nodes are deployed on the node device where the SPV main network node is located, and the sub-network nodes share the block header maintained by the SPV main network node. In this embodiment of the present specification, an initiator of the SPV authentication request generally needs to maintain a block header of a block chain corresponding to a block chain master network, for example, the initiator may be an SPV master network node in the block chain master network, and such a node only maintains the block chain formed by the block header, but does not maintain a complete block chain including the block header and the block, or the initiator may also be a subnet node deployed on a node device where the SPV master network node is located. Taking the example that nodeA1 in subnet1 in fig. 1 wishes to verify whether subnet2 exists, since nodeA and nodeA1 are deployed in the same node device 1, nodeA1 can obtain the chunk header of the chunk link main network maintained by nodeA through a shared plug-in deployed on node device 1, nodeA1 can initiate an SPV authentication request for subnet2 to a whole number of nodes in subnet0, nodeB receives the SPV authentication request, reduces a network architecture Merkle tree and returns the determined authentication auxiliary information to nodeA1, and nodeA1 can independently complete the process of recalculating Merkle tree root and tree root comparison after receiving the authentication auxiliary information, thereby completing the verification of the existence of subnet 2.

Fig. 6 is a flowchart of a method for verifying network architecture information of a blockchain system according to an exemplary embodiment. The block chain system comprises a block chain main network and a block chain sub-network managed by the block chain main network, and the network architecture information is used for describing the block chain sub-network contained in the block chain system; the method comprises the following steps:

step 602: and initiating an SPV verification request aiming at target information in the network architecture information to a full-scale main network node in the block chain main network, wherein a main network block maintained by the full-scale main network node records a network architecture Merkle tree generated based on the network architecture information, a block head is used for anchoring a tree root of the network architecture Merkle tree, a block body records leaf nodes of the network architecture Merkle tree, and the leaf nodes of the network architecture Merkle tree are subnet identifications corresponding to block chain subnets in the block chain system.

Step 604: and receiving the authentication auxiliary information which is determined and returned by the full-scale main network node from the network architecture Merkle tree. As described above, the full-scale master network node selects the leaf node and/or branch node for fast recalculating the tree root of the network architecture Merkle according to the path of the target information in the network architecture Merkle tree as the verification auxiliary information.

Step 606: and performing SPV verification on the target information based on the verification auxiliary information and the block header of the main network block maintained by the SPV main network node. The method mainly comprises the steps of recalculating the root of the network architecture Merkle tree by using target information and verification auxiliary information, comparing the calculated root to be verified with the root (namely a reference root) of the network architecture Merkle tree recorded on the block head of a main network block maintained by an SPV main network node, and proving the existence of the target information under the condition of consistent comparison.

In this embodiment of the present specification, the SPV authentication request carries the block height of the master network block of the request, so that the full-scale master network node may determine, based on the block height, a corresponding master network block maintained by itself, and obtain a leaf node of the network architecture Merkle tree from its block body to generate the network architecture Merkle tree, and therefore the authentication auxiliary information obtained by the initiator of the SPV authentication is determined based on the master network block of the corresponding block height, and then subsequently, when performing authentication by using the authentication auxiliary information, it is also necessary to obtain, from the SPV master network node, the block header of the master network block corresponding to the block height, so that the authentication auxiliary information provided by the full-scale master network node and the reference tree root provided by the SPV master network node are from the master network block of the same block height, so as to ensure the accuracy of the SPV authentication.

In an embodiment of the present disclosure, although the SPV verification request carries the block height of the main network block of the required request, the total number of main network nodes will not generate the network architecture Merkle tree based on the block body of the block corresponding to the block height, but generate the network architecture Merkle tree according to the self-maintained dynamically changing network architecture information. Since there is a certain hysteresis in the network architecture Merkle tree anchored on the block (because there is a phenomenon that a transaction for changing the network architecture information is already executed but is not packed into a block temporarily), in the embodiment of the present specification, the network architecture Merkle tree generated by the master network full node has real-time performance, and can overcome SPV verification errors caused by the hysteresis.

In the embodiment of the present specification, the initiator of the SPV authentication request may initiate the SPV authentication request to all master network nodes, or may initiate the SPV authentication request to any network node maintaining a complete blockchain corresponding to a blockchain master network, because the block of the master network block related to the present specification includes a leaf node for restoring a Merkle tree of a network architecture, only the block of the master network block corresponding to the blockchain master network needs to be maintained, and the initiator of the SPV authentication request can be provided with a proof of existence of network architecture information related to the blockchain system.

As previously mentioned, the initiator of the SPV authentication request includes: the SPV master network node, or a subnet node deployed on a node device where the SPV master network node is located, and the subnet node shares a block header maintained by the SPV master network node.

As described above, the target information includes values of leaf nodes corresponding to the to-be-verified blockchain subnet in the network architecture Merkle tree.

As mentioned above, the network architecture information is also used to describe the node members included in the blockchain subnet; the subnet identification corresponding to any block chain subnet comprises: a node member information set corresponding to any block chain sub-network or a tree root of a sub-network Merkel tree; and the node member information set and the leaf nodes of the subnet Merkle tree are respectively used for representing the subnet nodes contained in any block chain subnet. In an embodiment of the present specification, the target information may include: a member information set of nodes to be verified corresponding to the block chain subnet to be verified; or, the value of the leaf node corresponding to the subnet node to be verified in the subnet Merkle tree, wherein the subnet node to be verified is contained in the block chain subnet to be verified. In this specification embodiment, the full number of master network nodes can provide not only proof of the presence of the subnet, but also proof of the presence of the node members in the subnet. For example, in a case where the subnet identifier corresponding to any blockchain subnet is the tree root of the subnet Merkel tree corresponding to any blockchain subnet, an initiator of the SPV authentication request may request the full-scale master network node to authenticate the existence of a specific subnet node in a specific blockchain subnet, and in this case, the full-scale master network node also needs to maintain a subnet Merkel tree corresponding to each blockchain subnet, so as to return the authentication auxiliary information determined from the subnet Merkel tree corresponding to the specific blockchain subnet and the authentication auxiliary information determined from the network architecture Merkel tree to the initiator together, so that the initiator may recalculate the tree root of the network architecture Merkel tree according to the authentication auxiliary information.

The method for verifying network architecture information of a blockchain system provided in the present specification will be described in an embodiment.

Assuming that the blockchain system according to the embodiment of the present disclosure includes 4 blockchain subnets, and the structure of the Merkle tree corresponding to the network architecture of the blockchain system is as shown in fig. 3, where the structure of the Merkle tree corresponding to the subnet corresponding to the first blockchain subnet corresponding to the leftmost leaf node is as shown in fig. 4, it is apparent that the node members of the first blockchain subnet include node1, node3, node5, and node 7.

Under the network architecture of the blockchain system, assuming that a verifier wants to verify whether a node1 is deployed in a first blockchain subnet, an SPV verification request for whether a node1 exists in the first blockchain subnet may be initiated to a total number of master network nodes in the blockchain master network, and at this time, the SPV verification request includes a subnet identifier of the first blockchain subnet and a node public key of the node 1.

After receiving the SPV verification request, the full-scale master network node first generates a network architecture Merkle tree based on the leaf nodes of the network architecture Merkle tree recorded in the block, then determines the subnet required to be verified by the verifier as the first block chain subnet based on the subnet identifier of the first block chain subnet carried in the SPV verification request, and determines the path of the leaf node corresponding to the to-be-verified block chain subnet in the generated network architecture Merkle tree (the path is used to represent that the leaf node is the leftmost leaf node in the network architecture Merkle tree), thereby determining that the verification auxiliary information corresponding to the leaf node is the leaf node a and the branch node B shown in fig. 3 in the network architecture Merkle tree.

Meanwhile, since the SPV verification request also carries the node public key of node1, the full-scale master network node needs to further provide verification auxiliary information for verifying whether the first blockchain subnet includes node1, specifically, the full-scale master network node generates the subnet Merkle tree corresponding to the first blockchain subnet based on the leaf node of the subnet Merkle tree corresponding to the first blockchain subnet recorded in the block, and then determines the path of the leaf node corresponding to the node to be verified (the path is used for representing that the leaf node is the leaf at the leftmost end in the subnet Merkle tree of the first blockchain subnet) according to the node public key of node1, so as to determine that the verification auxiliary information corresponding to the leaf node is the leaf node a and the branch node b shown in fig. 4 in the subnet Merkle tree.

Therefore, the values corresponding to the leaf node a, the branch node B, the leaf node a and the branch node B determined by the full-scale main network node based on the SPV verification request are returned to the verifier as verification auxiliary information corresponding to the SPV verification request.

After receiving the verification auxiliary information corresponding to the SPV verification request, the verifier performs a process of recalculating a tree root of a network architecture Merkle tree according to a node public key of the node1 and the verification auxiliary information, specifically, an intermediate node obtained by hash-merging the node public key of the node1 and a leaf node a is denoted as an intermediate node c, and the value of the intermediate node c is c = hash (key 1+ a), wherein "hash ()" represents hash operation, "key 1" represents a public key of the node1, "a" represents a value of the leaf node a, and "+" represents a merging algorithm sensitive to an order of "summands"; similarly, the intermediate node c and the branch node b are subjected to hash combination to obtain a root of the to-be-verified tree of the subtree Merkle tree, which is recorded as a subtree root node and has a value of m = hash (c + b), wherein "b" is a value of the branch node b; after the subtree root node is obtained, recalculating an intermediate node C in the network architecture Merkle tree in the same way, wherein the value of the intermediate node C is C = hash (m + A); and finally, determining the value of the root of the recomputed network architecture Merkle tree as N = hash (C + B).

After recalculating the tree root of the network architecture Merkle tree, the verifier compares the tree root with the tree root (reference tree root) of the network architecture Merkle tree recorded in the self-maintained block header, if the tree root and the reference tree root are the same, the verifier can prove that the node1 indeed exists in the first blockchain subnet, and if the tree root and the reference tree root are different, the verifier cannot prove that the node1 indeed exists in the first blockchain subnet.

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

Fig. 8 is a block diagram of an apparatus for maintaining network architecture information of a blockchain system according to an exemplary embodiment, which may be applied to the device shown in fig. 7 to implement the technical solution of the present specification, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used to describe the blockchain sub-network included in the blockchain system; the apparatus is applied to a master network node in the blockchain master network, and the apparatus includes:

a framework change unit 801 configured to receive a transaction for changing the network framework information; in a network architecture Merkle tree generated based on the network architecture information, leaf nodes are subnet identifications corresponding to the block chain subnets in the block chain system;

a block generating unit 802, configured to anchor a root of the network architecture Merkle tree to a block header of the new block and write a leaf node of the network architecture Merkle tree into a block body of the new block when generating a new block corresponding to the transaction.

Optionally, the network architecture information is further used to describe node members included in the blockchain subnet; the subnet identification corresponding to any block chain subnet comprises:

a node member information set corresponding to any block chain sub-network or a tree root of a sub-network Merkel tree; and the node member information set and the leaf nodes of the subnet Merkle tree are respectively used for representing the subnet nodes contained in any block chain subnet.

Optionally, a master network node in the block chain master network is deployed on a node device where a subnet node in any block chain subnet is located;

the node member information set comprises a character string, character bits of the character string correspond to the master network nodes in the block chain master network one by one, and values of the character bits are used for representing whether the node equipment where the corresponding master network node is located is provided with the sub-network node in any block chain sub-network or not.

Optionally, the leaf nodes in the subnet Merkel tree correspond to the subnet nodes included in any blockchain subnet one by one.

leaf nodes in the subnet Merkel tree correspond to the main network nodes in the blockchain main network one by one, and the leaf nodes in the subnet Merkel tree are used for representing whether the node equipment where the corresponding main network node is located is provided with the subnet node in any blockchain subnet.

Optionally, the apparatus further comprises:

a node writing unit 803, configured to write the leaf node of the subnet Merkel tree into the zone block of the new block if the leaf node of the network architecture Merkel tree is the tree root of the subnet Merkel tree.

Optionally, the block generating unit 802 is specifically configured to:

writing the tree root of the network architecture Merkle tree into the block head of the new block; or,

and taking the tree root of the network architecture Merkle tree as a leaf node of the state tree corresponding to the new block, and writing the calculated state root into the block head of the new block.

Optionally, the method further includes:

an SPV verification unit 804, configured to receive an SPV verification request initiated for target information in the network architecture information; and determining corresponding verification auxiliary information from the network architecture Merkle tree, and returning to the initiator of the SPV verification request.

Optionally, the initiator of the SPV authentication request includes:

an SPV master network node in the block chain master network; or,

and the sub-network nodes are deployed on the node equipment where the SPV main network node is located, and share the block header maintained by the SPV main network node.

Optionally, the transaction includes at least one of:

a subnet registration transaction for creating a new blockchain subnet;

a subnet exit transaction for deleting an existing blockchain subnet;

a subnet node adjustment transaction for adjusting node members of an existing blockchain subnet.

Optionally, the apparatus further comprises:

a node start/stop unit 805, configured to generate a network architecture change event corresponding to the transaction, where the network architecture change event is used to instruct a node device where the master network node is located to perform a corresponding node start/stop operation, so that a network architecture of the blockchain system is matched with the changed network architecture information.

Fig. 9 is a block diagram of an apparatus for verifying network architecture information of a blockchain system according to an exemplary embodiment, which may be applied to the device shown in fig. 7 to implement the technical solution of the present specification, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used to describe the blockchain sub-network included in the blockchain system; the device comprises:

a requesting unit 901, configured to initiate an SPV verification request for target information in the network architecture information to a full-volume master network node in the block chain master network, where a network architecture Merkle tree generated based on the network architecture information is recorded in a master network block maintained by the full-volume master network node, a block head is used to anchor a tree root of the network architecture Merkle tree, a block body is recorded with a leaf node of the network architecture Merkle tree, and the leaf node of the network architecture Merkle tree is a subnet identifier corresponding to a block chain subnet in the block chain system;

a receiving unit 902, configured to receive verification auxiliary information that is determined and returned by the full-scale master network node from the network architecture Merkle tree;

an authentication unit 903, configured to perform SPV authentication on the target information based on the authentication auxiliary information and a block header of the master network block maintained by the SPV master network node.

Optionally, the initiator of the SPV authentication request includes:

the SPV master network node, or,

Optionally, the target information includes values of leaf nodes corresponding to the block chain sub-network to be verified in the network architecture Merkle tree.

Optionally, the target information includes:

a member information set of nodes to be verified corresponding to the block chain subnet to be verified; or,

and the value of the leaf node corresponding to the subnet node to be verified in the subnet Merkle tree, wherein the subnet node to be verified is contained in the subnet of the blockchain to be verified.

Correspondingly, the present specification also provides an apparatus comprising a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of the method for maintaining or verifying the network architecture information of the blockchain system provided by all the above method embodiments.

Accordingly, the present specification also provides a computer readable storage medium having executable instructions stored thereon; wherein, when executed by the processor, the instructions implement the steps of the method for maintaining or verifying the network architecture information of the blockchain system provided by all the above method embodiments.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for maintaining network architecture information of a block chain system, wherein the block chain system comprises a block chain main network and a block chain sub-network managed by the block chain main network, and the network architecture information is used for describing the block chain sub-network contained in the block chain system; the method is applied to a master network node in the block chain master network, and comprises the following steps:

2. The method of claim 1, wherein the network architecture information is further used to describe node members included in the blockchain subnet; the subnet identification corresponding to any block chain subnet comprises:

3. The method according to claim 2, wherein a master network node in the block chain master network is deployed on a node device where a subnet node in any block chain subnet is located;

4. The method of claim 2, wherein the leaf nodes in the subnet Merkel tree correspond to the subnet nodes included in any blockchain subnet one by one.

5. The method according to claim 2, wherein a master network node in the block chain master network is deployed on a node device where a subnet node in any block chain subnet is located;

6. The method of claim 2, further comprising:

and writing the leaf nodes of the subnet Merkel tree into the zone blocks of the new blocks under the condition that the leaf nodes of the network architecture Merkel tree are the tree roots of the subnet Merkel tree.

7. The method of claim 1, anchoring a root of the network architecture Merkle tree to a block header of the new block, comprising:

8. The method of claim 1, further comprising:

receiving an SPV verification request initiated aiming at target information in the network architecture information;

and determining corresponding verification auxiliary information from the network architecture Merkle tree, and returning the verification auxiliary information to the initiator of the SPV verification request.

9. The method of claim 8, the initiator of the SPV authentication request comprising:

an SPV master network node in the block chain master network; or,

10. The method of claim 1, the transaction comprising at least one of:

a subnet registration transaction for creating a new blockchain subnet;

a subnet exit transaction for deleting an existing blockchain subnet;

11. The method of claim 1, further comprising:

and generating a network architecture change event corresponding to the transaction, wherein the network architecture change event is used for indicating the node device where the main network node is located to execute corresponding node start-stop operation so as to enable the network architecture of the blockchain system to be matched with the changed network architecture information.

12. A method for verifying network architecture information of a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain sub-network managed by the blockchain main network, and the network architecture information is used for describing the blockchain sub-network contained in the blockchain system; the method comprises the following steps:

13. The method of claim 12, the initiator of the SPV authentication request comprising:

the SPV master network node, or,

14. The method of claim 12, wherein the target information includes values of leaf nodes corresponding to the blockchain sub-network to be verified in the Merkle tree of the network architecture.

15. The method of claim 12, wherein the network architecture information is further used to describe node members included in the blockchain subnet; the subnet identification corresponding to any block chain subnet comprises:

16. The method of claim 15, the target information comprising:

17. An apparatus for maintaining network architecture information of a blockchain system, the blockchain system comprising a blockchain main network and a blockchain sub-network managed by the blockchain main network, the network architecture information being used for describing the blockchain sub-network included in the blockchain system; the apparatus is applied to a master network node in the blockchain master network, and the apparatus includes:

18. An apparatus for verifying network architecture information of a blockchain system, the blockchain system comprising a blockchain main network and a blockchain sub-network managed by the blockchain main network, the network architecture information being used for describing the blockchain sub-network contained in the blockchain system; the device comprises:

19. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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