WO2023050986A1 - 维护区块链系统的网络架构信息 - Google Patents

维护区块链系统的网络架构信息 Download PDF

Info

Publication number
WO2023050986A1
WO2023050986A1 PCT/CN2022/107800 CN2022107800W WO2023050986A1 WO 2023050986 A1 WO2023050986 A1 WO 2023050986A1 CN 2022107800 W CN2022107800 W CN 2022107800W WO 2023050986 A1 WO2023050986 A1 WO 2023050986A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain
node
subnet
network
network architecture
Prior art date
Application number
PCT/CN2022/107800
Other languages
English (en)
French (fr)
Inventor
卓海振
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023050986A1 publication Critical patent/WO2023050986A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a method and device for maintaining network architecture information of a blockchain system.
  • Blockchain technology is built on top of transmission networks such as peer-to-peer networks.
  • Nodes in the blockchain network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.
  • some nodes sometimes need to implement small-scale transactions to prevent other nodes from obtaining these transactions and their related data. Therefore, a blockchain subnet can be further established on the basis of the blockchain main network, thereby forming a blockchain system including the blockchain main network and the blockchain subnet.
  • one or more embodiments of this specification provide a method, device, electronic device and storage medium for maintaining and verifying network architecture information of a blockchain system.
  • a method for maintaining network architecture information of a blockchain system includes a blockchain main network and a blockchain main network Managed blockchain subnet, the network architecture information is used to describe the blockchain subnet contained in the blockchain system; the method is applied to the main network nodes in the blockchain main network, and the method Including: receiving a transaction for changing the network architecture information; wherein, in the network architecture Merkle tree generated based on the network architecture information, the leaf node is the subnet corresponding to the blockchain subnet in the blockchain system Network identification; when generating a new block corresponding to the transaction, anchor the root of the Merkle tree of the network architecture to the block header of the new block, and write the leaf nodes of the Merkle tree of the network architecture into The block body of the new block.
  • a method for verifying network architecture information of a blockchain system includes a blockchain main network and a blockchain main network managed block chain subnet, the network architecture information is used to describe the block chain subnet contained in the block chain system;
  • the SPV verification request of the target information in the network architecture information, the network architecture Merkle tree generated based on the network architecture information is recorded in the main network block maintained by the full number of main network nodes, wherein the block header is used for anchoring
  • the root and block body of the network architecture Merkle tree record the leaf nodes of the network architecture Merkle tree, and the leaf nodes of the network architecture Merkle tree correspond to the blockchain subnet in the blockchain system subnet ID; receive the verification auxiliary information determined and returned by the full number of main network nodes from the network architecture Merkle tree; based on the verification auxiliary information and the area of the main network block maintained by the SPV main network node Block header, performing SPV verification on the target information.
  • a device for maintaining network architecture information of a blockchain system includes a blockchain main network and the blockchain main network Managed blockchain subnet, the network architecture information is used to describe the blockchain subnet contained in the blockchain system; the device is applied to the main network node in the blockchain main network, and the device Including: a structure change unit, which is used to receive a transaction for changing the network structure information; wherein, in the network structure Merkle tree generated based on the network structure information, the leaf node is the area in the block chain system A subnet identification corresponding to the block chain subnet; a block generation unit, configured to anchor the root of the Merkle tree of the network architecture to the block header of the new block when generating a new block corresponding to the transaction, and Write the leaf nodes of the network architecture Merkle tree into the block body of the new block.
  • a structure change unit which is used to receive a transaction for changing the network structure information
  • the leaf node is the area in the block chain system A subnet identification corresponding to the block chain subnet
  • a block generation unit configured to
  • a device for verifying network architecture information of a blockchain system includes a blockchain main network and the blockchain main network Managed block chain subnet, the network architecture information is used to describe the block chain subnet contained in the block chain system;
  • the main network node initiates an SPV verification request for the target information in the network architecture information, and the network architecture Merkle tree generated based on the network architecture information is recorded in the main network blocks maintained by the full number of main network nodes, where the block
  • the block header is used to anchor the root of the Merkle tree of the network architecture, and the block body records the leaf nodes of the Merkle tree of the network architecture, and the leaf nodes of the Merkle tree of the network architecture are in the blockchain system
  • the receiving unit is used to receive the verification auxiliary information determined and returned by the full amount of main network nodes from the network architecture Merkle tree;
  • the verification unit is used to based on the verification auxiliary information and
  • an electronic device including a processor and a memory for storing instructions executable by the processor.
  • the processor implements the steps of the method for maintaining or verifying the network architecture information of the blockchain system by running the executable instructions.
  • a computer-readable storage medium on which executable instructions are stored; wherein, when the instructions are executed by a processor, the above maintenance or verification of the network architecture information of the blockchain system is realized steps of the method.
  • Fig. 1 is a schematic diagram of building a blockchain subnet based on the blockchain main network provided by an exemplary embodiment.
  • Fig. 2 is a flowchart of a method for maintaining network architecture information of a blockchain system provided by an exemplary embodiment.
  • Fig. 3 is a schematic structural diagram of a network architecture Merkle tree provided by an exemplary embodiment.
  • Fig. 4 is a schematic structural diagram of a subnetwork Merkle tree provided by an exemplary embodiment.
  • Fig. 5 is a schematic structural diagram of another subnet Merkle tree provided by an exemplary embodiment.
  • Fig. 6 is a flowchart of a method for verifying network architecture information of a blockchain system provided by an exemplary embodiment.
  • Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 8 is a block diagram of an apparatus for maintaining network architecture information of a blockchain system provided by an exemplary embodiment.
  • Fig. 9 is a block diagram of an apparatus for verifying network architecture information of a blockchain system provided by an exemplary embodiment.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or less steps than those described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.
  • all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes.
  • all consortium members that is, node members in the consortium
  • all consortium members can form a blockchain network, and all consortium members have corresponding blockchain nodes in the blockchain network, and can pass the corresponding zone Block chain nodes obtain all transactions and related data that occur on the block chain network.
  • there may be some alliance members who want to complete some transactions that require confidentiality. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other transactions. affiliate members see these transactions and related data.
  • the establishment method is similar to the above-mentioned blockchain network that includes all alliance members, but building a new blockchain network from scratch requires a lot of resources, and regardless of The establishment process of the blockchain network or the configuration process after completion is very time-consuming.
  • the needs among alliance members are often temporary or have a certain timeliness, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network .
  • the needs of alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever the alliance members change, it may be necessary to form a new blockchain network, resulting in resource and time constraints. A lot of waste.
  • the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be formed on the basis of the blockchain main network.
  • the consortium members can build the required blockchain subnet based on their own needs while already participating in the blockchain main network. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet is compared to the completely independent establishment of a blockchain network, the resources consumed and the time required, etc. Both are greatly reduced, and the flexibility is extremely high.
  • each blockchain node in the blockchain main network obtains a transaction for establishing a blockchain subnet, and the transaction includes the configuration information of the blockchain subnet , the configuration information includes the identity information of the node members participating in the formation of the block chain subnet, each block chain node in the block chain main network respectively executes the transaction to disclose the configuration information, when the When the configuration information includes the identity information of the node members corresponding to the first block chain node, the node device deploying the first block chain node starts the first block belonging to the block chain subnet based on the genesis block containing the configuration information.
  • Two blockchain nodes Two blockchain nodes.
  • the blockchain main network is subnet0
  • the blockchain nodes contained in this subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE.
  • nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to form a blockchain subnet, then nodeA can initiate the above-mentioned transaction to form a blockchain subnet to subnet0; If nodeE is an administrator and only allows the administrator to initiate the transaction of establishing a blockchain subnet, then nodeA ⁇ nodeD needs to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE is an administrator but allows Ordinary users initiate a transaction to establish a blockchain subnet, then nodeA ⁇ nodeE can initiate the above transaction to subnet0 to establish a blockchain subnet.
  • the blockchain node that initiates the transaction to form a blockchain subnet does not necessarily participate in the established blockchain subnet.
  • nodeE can initiate the above-mentioned transaction of establishing a blockchain subnet to subnet0, and not necessarily nodeA ⁇ nodeD initiate the transaction of establishing a blockchain subnet.
  • the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet formed on the basis of other blockchain networks, such as the subnet0 can be regarded as the blockchain mainnet belonging to the underlying blockchain network type.
  • the blockchain main network in this specification can also be a subnet of other blockchain networks.
  • subnet1 is the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.
  • the consensus nodes in the blockchain main network will conduct a consensus, and after the consensus is passed, each main network node will execute the transaction to complete the block The formation of the chain subnet.
  • the consensus process depends on the adopted consensus mechanism, which is not limited in this specification.
  • the configuration information can be used to configure the established blockchain subnet so that the established blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, it is possible to specify which blockchain nodes are included in the established blockchain subnet.
  • the identity information of the node members may include the public key of the node, or other information that can characterize the identity of the node such as the node ID, which is not limited in this description.
  • each blockchain node has one or more sets of corresponding public-private key pairs, the blockchain node holds the private key and the public key is public and uniquely corresponds to the private key, so it can be passed
  • the public key is used to represent the identity of the corresponding blockchain node. Therefore, for blockchain nodes that wish to be node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the transaction for forming the blockchain subnet as the identity information of the above node members.
  • the above-mentioned public-private key pair can be used in the process of signature verification.
  • nodeA1 in subnet1 uses its own private key to sign the message, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key pair of nodeA1 Signature verification is performed on the received message to confirm that the message received by itself is indeed from nodeA1 and has not been tampered with.
  • the first main network node may be a blockchain node on the blockchain main network that is a node member indicated by the configuration information.
  • the first subnet node needs to be generated by the node device used to deploy the first main network node , and the first subnetwork node becomes a node member in the blockchain subnetwork.
  • the first main network node and the first subnet node correspond to the same blockchain member, for example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first main network node
  • the node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet belong to two independent Blockchain network, so that the blocks generated by the first main network node and the blocks generated by the first subnet node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing the first
  • the storage used by the main network node and the first subnet node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized among the node members of the blockchain subnet, so that only those who participate in the blockchain main
  • the blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the requirements
  • the first main network node and the first subnet node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to deploying the first main network node and the first subnet node
  • the node devices participate in the blockchain main network and the blockchain subnet at the same time. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other, so even if the first main network node and the first subnet node can use exactly the same public key, the two should still be considered as different blockchain nodes. For example, in FIG.
  • nodeA in subnet0 is equivalent to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first main network node, it will not affect the implementation of the scheme in this specification.
  • the node members of the blockchain subnet are not necessarily only part of the node members of the blockchain main network.
  • the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network.
  • all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other.
  • the two types of The business data generated by the business are isolated from each other.
  • the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the The attribute configuration of the code, etc., is not limited in this specification.
  • the network identifier is used to uniquely represent the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network.
  • the identity information of the administrator of the blockchain subnet can be, for example, the public key of the node member who is the administrator; the administrators of the blockchain main network and the blockchain subnet can be the same or different.
  • One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has already been deployed on the node device that generates the first subnetwork node, the area used by the first mainnet node can be The block chain platform code is reused on the first subnet node, which eliminates the repeated deployment of the block chain platform code and greatly improves the efficiency of the block chain subnet.
  • the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code attribute configuration, the first subnetwork node can adopt the attribute configuration, so that the attribute configuration adopted by the first subnetwork node is not limited to the attribute configuration of the first main network node, and has nothing to do with the first main network node.
  • the attribute configuration for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., which are not limited in this specification.
  • Transactions that form blockchain subnets include transactions that call contracts.
  • the transaction can specify the address of the called smart contract, the method called and the parameters passed in.
  • the invoked contract can be the aforementioned genesis contract or system contract
  • the invoked method can be a method for building a blockchain subnet
  • the incoming parameters can include the above-mentioned configuration information.
  • the transaction may include the following information: from: Administrator to: Subnet method: AddSubnet (string) string: genesis
  • the from field is the information of the initiator of the transaction, for example, Administrator indicates that the initiator is an administrator ;
  • the to field is the address of the called smart contract, for example, the smart contract can be a Subnet contract, then the to field is the address of the Subnet contract;
  • the method field is the calling method, for example, it is used in the Subnet contract to build a blockchain
  • the method of the net can be AddSubnet(string), and string is a parameter in the AddSubnet() method.
  • the value of the parameter is represented by genesis, which is specifically the aforementioned configuration information.
  • nodeA ⁇ nodeE Take nodes nodeA ⁇ nodeE on Subnet0 executing a transaction calling the AddSubnet() method in the Subnet contract as an example. After the transaction passes the consensus, nodeA ⁇ nodeE respectively execute the AddSubnet() method and pass in the configuration information to obtain the corresponding execution results.
  • Contract execution results can be expressed as events in receipts.
  • the message mechanism can implement message delivery through events in the receipt to trigger blockchain nodes to perform corresponding processing.
  • the structure of the event can be, for example: Event: [topic][data][topic][data]...
  • the number of events can be one or more; each event includes a topic (topic) and data (data) and other fields.
  • Blockchain nodes can listen to the topic of the event to perform preset processing when listening to a predefined topic, or read relevant content from the data field of the corresponding event, and can execute preset based on the read content deal with.
  • the monitoring code can be embedded in the blockchain platform code running on the blockchain node, so that the monitoring code can monitor the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc. or multiple types of data, and send the monitored data to a predefined listener.
  • the monitoring code is deployed in the blockchain platform code instead of the listener's client, this implementation based on the monitoring code is relatively more active than the event mechanism.
  • the above monitoring code can be added to the blockchain platform code by the developers of the blockchain platform during the development process, or can be embedded by the monitoring party based on its own needs, which is not limited in this manual.
  • the execution result of the above-mentioned Subnet contract may include the configuration information, and the execution result may be included in the above-mentioned receipt, and the receipt may include an event related to the execution of the AddSubnet() method, that is, a networking event.
  • the topic of networking events can contain predefined networking event identifiers to distinguish them from other events. For example, in the event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods.
  • nodeA ⁇ nodeE can determine to monitor the event related to the execution of the AddSubnet() method, that is, the networking event, when the topic containing the keyword subnet is monitored.
  • the events in the receipt are as follows: Event: [topic:other][data][topic:subnet][data]...
  • the content of the data field may include, for example: ⁇ subnet1; nodeA’s public key, nodeA’s IP, nodeA’s port number...; nodeB’s public key, nodeB’s IP, port number of nodeB...; public key of nodeC, IP of nodeC, port number of nodeC...; public key of nodeD, IP of nodeD, port number of nodeD...; ⁇
  • subnet1 is the blockchain subnet you want to create network ID.
  • Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets, such information can be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the values of one or more contract states included in the Subnet contract. Then, nodeA ⁇ nodeE can determine whether the above-mentioned subnet1 already exists according to the recorded network identifiers of all blockchain subnets that have been created; if it does not exist, it means that subnet1 is a new blockchain subnet that needs to be created currently, and if it exists, it means that subnet1 already exists.
  • a predefined new network identifier which indicates that the corresponding networking event is used to form a new blockchain subnet.
  • the above-mentioned subnet1 can be replaced with newsubnet, which is a predefined new network identifier.
  • nodeA ⁇ nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created.
  • Blockchain subnet When nodeA ⁇ nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created.
  • the above data field also includes identity information of each node member and so on.
  • the node device deploying the first main network node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the deployment second A node device of a main network node obtains the configuration information or the genesis block included in the networking event.
  • the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, trigger the deployment of the first blockchain node.
  • a node device of a blockchain node acquires the configuration information or the genesis block included in the networking event.
  • node devices can listen for receipts directly. Assuming that nodeA ⁇ nodeE are respectively deployed on node devices 1 ⁇ 5, and node devices 1 ⁇ 5 can monitor the receipts generated by nodeA ⁇ nodeE respectively, then when it is detected that subnet1 is a blockchain subnet that needs to be newly established, node device 1 ⁇ 5 will further identify the identity information of the node members contained in the data field to determine its own processing method.
  • nodeA and node device 1 Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as nodeA's public key, IP address, and port number, then node device 1 obtains configuration information from the data field based on the above message mechanism , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and then nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node Device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block according to the configuration information in the data field, nor will it generate a blockchain node in subnet1.
  • identity information such as nodeA's public key, IP address, and port number
  • the blockchain nodes in the blockchain main network can monitor receipts, and trigger node devices to perform related processing according to the monitoring results.
  • nodeA ⁇ nodeE will further identify the identity information of the node members contained in the data field in order to determine their own processing methods when they determine that subnet1 is a blockchain subnet that needs to be newly established.
  • nodeA ⁇ nodeD will find that the data field contains their own identity information such as their public key, IP address, and port number. Assume that nodeA ⁇ nodeD are deployed on node devices 1 ⁇ 4 respectively.
  • nodeA will Trigger node device 1, so that node device 1 obtains configuration information from the data field based on the above message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and nodeA1 will load the generated genesis block, Thus, it becomes a subnet node in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1.
  • nodeE will find that the identity information contained in the data field does not match itself, assuming that nodeE is deployed on node device 5, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1 nodes in .
  • the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD.
  • nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and nodeA1 loads the genesis block; or, if nodeA is in the data field If the identity information of nodeA1 is found in , then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block.
  • the processing methods of other blockchain nodes or node devices are similar and will not be repeated here.
  • the execution result of the contract can include the genesis block.
  • the corresponding node devices 1-4 can directly obtain the genesis block from the data field through the message mechanism without generating it by themselves, which can improve the deployment efficiency of nodeA1-nodeD1.
  • the node device implements the deployment of a blockchain node on the node device by creating an instance of running the blockchain platform code in the process.
  • the node device creates the first instance in the above process, and the first instance runs the blockchain platform code to form.
  • the node device creates a second instance different from the first instance in the above process, and the second instance runs the blockchain platform code to form.
  • the node device can first create the first instance in the process to form the first blockchain node in the blockchain main network; In the above process, a second instance is created, which is different from the above-mentioned first instance, and the second instance forms a second blockchain node in the blockchain subnet.
  • the node device can create the first instance in the first process to form the first blockchain node in the blockchain main network; and when the node When the node member corresponding to the device wants to participate in the establishment of a blockchain subnet, it can start a second process different from the first process, and create a second instance in the second process, which is different from the first instance above. Furthermore, the second instance forms a second blockchain node in the blockchain subnet.
  • each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device, and each blockchain node deployed on any node device
  • the blocks generated by the nodes are respectively stored in different storages (such as databases) on any node device, and the storages used by each blockchain node deployed by any node device are isolated from each other.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally included nodeA ⁇ nodeE
  • subnet1 can be built on the basis of subnet0.
  • This subnet1 includes nodeA1 ⁇ nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device.
  • subnet2 or more blockchain subnets can also be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device.
  • subnet1, subnet2, etc. can be used as the new blockchain main network, and a blockchain subnet can be further formed on this basis. The process is similar to the formation of subnet1 or subnet2, and will not be repeated here.
  • the above-mentioned method of initiating transactions on the blockchain main network to select node members to create a blockchain subnet can make the subnet nodes of the newly created blockchain subnet all deployed on the main network nodes of the blockchain main network.
  • 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.
  • the main network node in the blockchain main network is deployed on the node device at .
  • a blockchain subnet can be established on the blockchain main network through registration (subsequently referred to as the registration network method), and the existing blockchain network can be directly registered to the blockchain main network, so that the newly registered blockchain network Managed by the blockchain main network, the newly registered blockchain network becomes a blockchain subnet of the blockchain main network.
  • the subnet information of the block chain subnet to be formed is directly registered to the block chain main network, so that the block chain main network can obtain the relevant information of the block chain subnet to be formed (by receiving and executing the A transaction issued by the block chain network for associating its identity information with the subnet identification assigned to the block chain network to be formed), such as the subnet identification and operating status of the block chain subnet to be formed, where
  • the public key and plug-in configuration information of each node member, the IP address and port information of each node device, etc. will be written into the contract state of the system contract corresponding to the blockchain main network, so that the blockchain main network will Obtain the management right of the blockchain subnet to be formed.
  • the registration networking method does not need to specify node members on the blockchain main network through transactions to form a blockchain subnet
  • the subnet nodes in the blockchain subnet formed through the registration networking method can be deployed on the blockchain main network.
  • the node devices of each node in the network are completely different or partly different. For example, in Figure 1, subnet0 creates a subnet4 in the form of registered networking.
  • subnet nodes corresponding to subnet4 can be deployed on any other node devices except node devices 1 ⁇ 5, or one or more subnet nodes in subnet4 are respectively deployed on any node devices within node devices 1 ⁇ 5 (but It is still necessary to ensure that only one subnet node in subnet4 is deployed on a node device), and other subnet nodes in subnet4 are deployed on any node device except node devices 1 to 5.
  • subnets in subnet4 Nodes may also be deployed in node devices 1-5.
  • the different blockchain subnets created on the blockchain mainnet are independent and isolated from each other.
  • the consensus transactions on subnet1 will only be finally received by nodeA1 ⁇ nodeD1 , and will not be received by nodeA2, nodeB2, nodeC2, and nodeE2 in subnet2, therefore, different blockchain subnets logically belong to different blockchain networks, which makes information exchange between blockchain subnets necessary , and for a blockchain subnet, before it interacts with other blockchain subnets, it needs to obtain the subnet information of other blockchain subnets to ensure the correctness of information interaction, especially the need to obtain information about the entire
  • the existence information of the blockchain subnet currently contained in the blockchain main network that is, the network architecture information of the entire blockchain system including the blockchain main network and the blockchain subnet, so as to prevent the connection with the already exited zone
  • the blockchain subnet of the blockchain system interacts with information and causes network failures.
  • the block chain subnet is also a logically independent block chain network, so if information interaction is required, it needs to be completed through cross-chain technology, such as traditional cross-chain technologies based on side chain technology, witness mechanism or relay technology.
  • cross-chain technology is usually cumbersome and time-consuming in the actual implementation process, and the traditional cross-chain technology does not take into account the differences between the cross-chain scenario of the blockchain subnet and the blockchain main network and the traditional cross-chain scenario , which requires traditional cross-chain technology between the blockchain subnet and the blockchain main network to achieve trusted verification of blockchain data.
  • this specification proposes a method for maintaining and verifying the network architecture information of a blockchain system, wherein the blockchain system includes a blockchain main network and a blockchain subnet managed by the blockchain main network.
  • the network architecture information is used to describe the blockchain subnet contained in the blockchain system, and the Merkle tree formed by the network architecture information is anchored on the block maintained by the blockchain main network, so that
  • any verifier needs to verify the network architecture information in the blockchain system, it only needs to obtain the block maintained by the blockchain main network or the verification auxiliary information extracted from the block, without the need for verification.
  • the process of complex cross-chain interaction and smart contract invocation realizes a method to maintain and quickly verify the existence of blockchain subnets based on block information.
  • Fig. 2 is a flowchart of a method for maintaining network architecture information of a blockchain system provided by an exemplary embodiment.
  • the blockchain system includes a blockchain main network and a blockchain subnet managed by the blockchain main network, and the network architecture information is used to describe the blockchain subnet contained in the blockchain system ;
  • the method is applied to the main network node in the block chain main network, and the method includes: Step 202: receiving a transaction for changing the network architecture information; wherein, based on the network architecture information generated In the Merkle tree of the network architecture, the leaf node is the subnet identifier corresponding to the blockchain subnet in the blockchain system.
  • the blockchain system involved in the embodiment of this specification refers to the blockchain system composed of the blockchain main network and the blockchain subnet managed by the blockchain main network, such as the blockchain system shown in Figure 1.
  • the subnet nodes in subnet include nodeA1, nodeB1, nodeC1, and nodeD1, and the subnet nodes in subnet2 include nodeA2, nodeB2, nodeC2, and nodeE2.
  • subnet0 can manage subnet1 and subnet2, which is reflected in: subnet management transactions can be initiated on subnet0, so that each main network node executes the subnet management transactions and generates corresponding subnet management events, while the blockchain system
  • the subnet nodes in each block chain subnet obtain the subnet management events generated by the main network nodes (specifically, for the subnet nodes where the main network nodes are deployed on the node devices, they can directly obtain the same
  • subnet management events realize the information transmission from the blockchain main network to the blockchain subnet, and enable the blockchain subnet to implement corresponding management operations based on the subnet management events. For example, after the main network node nodeA executes the subnetwork management transaction and generates the corresponding subnetwork management event, the subnetwork nodes nodeA1 and nodeA2 that are in the same node device 1 as nodeA can obtain the subnetwork management event, so as to realize the corresponding management operations.
  • the network architecture information involved in the embodiments of this specification is used to describe the blockchain subnet contained in the blockchain system.
  • the network architecture information can be displayed in the form of a network list to display the blockchain subnets contained in the blockchain system.
  • the subnet ID of the blockchain subnet is maintained on each mainnet node in the blockchain mainnet (for example, maintained in a smart contract or in the blockchain platform code), for example, as shown in Figure 1
  • each main network node nodeA ⁇ nodeE contained in it maintains the network architecture information ⁇ subnet1, subnet2 ⁇ of the blockchain system, which is used to describe the blockchain subnet contained in the current blockchain main network subnet0
  • network architecture information can also be used to describe the blockchain main network contained in the blockchain system, that is, in the form of a network list, the network architecture information can also be expressed as ⁇ subnet0, subnet1, subnet2 ⁇ ; further, network architecture information can also be used to describe the main network nodes contained in the blockchain main
  • each main network node in the blockchain main network will execute the subnet management transaction and execute the subnet management transaction in the subnet management
  • the receipt corresponding to the transaction writes the subnet management event that triggers the generation.
  • the subnet management event records the change information brought about by the management operation corresponding to the subnet management transaction.
  • the trigger generation The subnet registration event of the newly generated blockchain subnet corresponds to the network identity and the identity information of the node members (such as the node public key).
  • the change information of the state change or the subnet information after the change, so the latest subnet information of the blockchain subnet can be obtained through the information carried in the subnet management event.
  • the management operation for the blockchain subnet needs to be realized by initiating the corresponding subnet management transaction on the blockchain main network.
  • the aforementioned transaction for establishing a blockchain subnet is a kind of subnet management transaction.
  • the administrator can pass Initiate a transaction to establish a blockchain subnet on the blockchain main network, so that each main network node in the blockchain main network executes the transaction and generates a networking event, and each node device deployed with the main network node listens to the group Network events and decide whether to start a new blockchain node according to the configuration information carried by the networking event, so that the node devices that meet the corresponding requirements start a new blockchain subnet node, thereby forming a new blockchain subnet.
  • the role of initiating a subnet management transaction It is equivalent to conveying management messages to each node device deployed with the main network node, and the complete execution of a final management operation depends on the event monitoring mechanism and the joint participation of each node device deployed with the main network node, that is, where the main network node is located
  • the node device of the node device, other subnet nodes deployed on the node device, or the subnet node where the main network node is not deployed on the node device perform corresponding management operations by listening to and responding to subnet management events, so as to achieve block Chain subnet management.
  • the generation of open subnetwork management events on each mainnet node is the main technical idea to realize the management of blockchain subnetworks by initiating transactions on the blockchain mainnet.
  • Any node device deployed with a main network node and/or a subnet node deployed on any node device executes the management operations corresponding to the monitored subnet management events.
  • the transaction used to change the network architecture information involved in the embodiments of this specification belongs to a subnet management transaction, which may include at least one of the following: a subnet registration transaction for creating a new blockchain subnet, a subnet registration transaction for Subnet exit transactions for deleting existing blockchain subnets, subnet start-stop transactions for changing the operating status of existing blockchain subnets, and subnetworks for adjusting node members of existing blockchain subnets
  • a node adjustment transaction a main network node adjustment transaction used to adjust the node members of the blockchain main network.
  • the main network node can identify the transaction type of the transaction through the transaction type field of the received transaction. When the main network node receives the above-mentioned transaction for changing the network architecture information, it will obtain the necessary network architecture from the transaction. Change instruction information to update the network architecture information maintained by itself.
  • the subnet registration transaction includes the above-mentioned transaction of establishing a blockchain subnet, as well as the registration and networking method involved in assigning the identity information of the existing blockchain network to the subnet of the existing blockchain network. Identifies the transaction for which the associated certificate is deposited. After the main network node receives the subnet registration transaction, it will update the network architecture information maintained by itself based on the subnet identification contained in the subnet registration transaction or the identity information of the subnet node.
  • each main network node will maintain the network architecture information from ⁇ subnet0: nodeA, nodeB, nodeC, nodeD, nodeE ⁇ , ⁇ subnet1: nodeA1, nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ changed to ⁇ subnet0: nodeA, nodeB, nodeC, nodeD, nodeE ⁇ , ⁇ subnet1: nodeA1, nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ , ⁇ subnet3: nodeA3, nodeB3 ⁇ .
  • the network architecture information is only used to describe the blockchain system.
  • the network architecture information maintained by itself will be updated from ⁇ subnet1, subnet2 ⁇ to ⁇ subnet1 ⁇ .
  • the effect of the subnet start-stop transaction used to change the operation state of the existing blockchain subnet to the closed state is similar to that of the subnet deletion transaction, and will not be repeated here.
  • Subnet node adjustment transactions are used to add new node members and/or delete existing node members in the specified blockchain subnet. For example, suppose a subnet node adjustment is initiated to subnet0 in Figure 1 to adjust the node members of subnet1 transaction, and instruct to delete nodeA1, then each main network node will maintain The network architecture information is changed from ⁇ subnet0: nodeA, nodeB, nodeC, nodeD, nodeE ⁇ , ⁇ subnet1: nodeA1, nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ to ⁇ subnet0: nodeA, nodeB, nodeC, nodeD, nodeE ⁇ , ⁇ subnet1: nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ .
  • the main network node adjustment transaction is used to add new node members and/or delete the original node members in the blockchain main network. For example, suppose a main network node adjustment transaction is initiated to subnet0 in Figure 1 and instructs to add nodeF, Then each main network node, after receiving the subnet registration transaction, will maintain the network architecture information by ⁇ subnet0: nodeA, nodeB, nodeC, nodeD, nodeE ⁇ , ⁇ subnet1: nodeA1, nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ changed to ⁇ subnet0: nodeA, nodeB, nodeC, nodeD , nodeE, nodeF ⁇ , ⁇ subnet1: nodeA1, nodeB1, nodeC1, nodeD1 ⁇ , ⁇ subnet2: nodeA2, nodeB2, nodeC2, nodeE2 ⁇ .
  • the above-mentioned transaction for changing the network architecture information is regarded as a subnetwork management transaction.
  • a network architecture change event corresponding to the transaction will be generated , as mentioned above, the network architecture change event belongs to a subnet management event, and the network architecture change event is used to instruct the node device where the main network node is located to perform the corresponding node startup and shutdown operations, so that the zone
  • the network architecture of the block chain system matches the changed network architecture information, and the network architecture includes the existence status and/or operation status of the blockchain main network and the blockchain subnet in the blockchain system.
  • each main network node will generate a network architecture change event after completing the consensus on the subnet registration transaction and executing it.
  • the main network node is deployed on the node device where any subnet node is located, so node device 1, node device 2, node device 3 and node device 5 respectively monitor the main network nodes deployed on their respective node devices.
  • nodeA2, nodeB2, nodeC2, and nodeE2 deployed respectively will be deleted based on the instruction information carried in the network architecture change event to describe the deletion of subnet2, thereby deleting subnet2, making the network of the blockchain system
  • the architecture after executing the subnet deletion transaction matches the network architecture information changed by the transaction.
  • the execution process of other transactions for changing the network architecture information is basically the same, and the execution results will cause the network architecture of the blockchain system to match the changed network architecture information, which will not be repeated here. repeat.
  • Merkle tree (Merkle tree, Merkle tree) is a kind of hash binary tree, invented by Ralph Merkle in 1979, which stores data in the leaf nodes of the tree structure, and passes through the data
  • the level-by-level hash (Hash) operation ensures data cannot be tampered with. Any changes in the data of the leaf nodes will be passed to the upper-level nodes and finally reflected to the changes in the root of the tree.
  • the network architecture Merkle tree involved in the embodiment of this specification is generated by the main network node based on the network architecture information maintained by itself, and its leaf nodes are the subnet identifiers corresponding to the blockchain subnets in the blockchain system. Due to the following properties of the Merkle tree: a complete Merkle tree can be constructed only by knowing the orderly arranged leaf nodes. Therefore, it is only necessary to determine the leaf nodes of the network architecture Merkle tree to generate the network architecture Merkle tree.
  • the subnet ID of the blockchain subnet directly or indirectly recorded in the network Network nodes can determine leaf nodes from the network architecture information maintained by themselves to generate a network architecture Merkle tree.
  • the subnet ID (or the hash value corresponding to the subnet ID) of each blockchain subnet in the blockchain system is used as the leaf node of the Merkle tree to be generated to perform hash merging step by step to generate Merkle
  • the Merkle tree is an ordered tree, and the leaf nodes need to be arranged in a preset order, and then hash merged step by step to generate a Merkle tree.
  • a leaf node corresponds to a subnet ID of a blockchain subnet
  • the preset order is the creation sequence of each leaf node corresponding to the blockchain subnet.
  • the blockchain system contains a total of 4 blockchain subnets, so the The generated network architecture Merkle tree contains 4 leaf nodes, where these 4 leaf nodes correspond to the subnet identifiers of the 4 blockchain subnets contained in the blockchain system, and from left to The right is arranged according to the order of creation of the corresponding blockchain subnets, as shown in Figure 3, the four leaf nodes are first paired in pairs to perform a hash merge to obtain two intermediate nodes, and then the two intermediate nodes ( Also known as branch nodes) and finally get the root node, which is the root of the Merkle tree, through a hash merge, thereby generating a complete network architecture Merkle tree.
  • Step 204 When generating a new block corresponding to the transaction, anchor the root of the Merkle tree of the network architecture to the block header of the new block, and write the leaf nodes of the Merkle tree of the network architecture into The block body of the new block.
  • the generation of a new block depends on packaging a preset number of transactions.
  • a blockchain node when a blockchain node generates a new block, it needs to write a predetermined number of transactions selected from the transaction pool to At the same time, the tree root corresponding to the transaction Merkle tree constructed according to these transactions (called the transaction root), and the tree root of the receipt Merkle tree constructed according to the receipts corresponding to these transactions (called the receipt Root) and the root of the state Merkle tree constructed by the state of the world (become the state root) is written into the block header of the new block, and the hash value of this block and the hash value of the previous block are written in the block header And information such as the hash value of the consensus algorithm, so that a block is finally generated to be spliced on the original blockchain.
  • the process when the main network node needs to generate a new block obtained by packaging the transaction (that is, the aforementioned transaction for changing the network architecture information), in addition to the generation of the new block in the above-mentioned prior art
  • the process also additionally includes the following process: anchoring the root of the Merkle tree of the network architecture to the block header of the new block, and writing the leaf nodes of the Merkle tree of the network architecture into the block of the new block body.
  • any block in the blockchain maintained by the blockchain main network will contain the corresponding network architecture Merkle tree, and the network architecture Merkle tree contains the blockchain The network architecture information of the system, so the blocks generated by the above-mentioned block generation method can assist the verifier to verify the network architecture information.
  • the main network node in addition to maintaining a dynamically changing network architecture information, the main network node will also maintain a dynamically changing network architecture Merkle tree (including leaf nodes, branch nodes and root nodes of the network architecture Merkle tree) , so that each time the main network node receives a transaction for changing the network architecture information to change the network architecture information maintained by itself, it also updates the network architecture Merkle tree maintained by itself in real time. Therefore, when generating a new area When building a block, the main network node does not need to convert the network architecture information to the network architecture Merkle tree, but can directly add the root and leaf nodes of the Merkel tree maintained by itself to the block header and block body of the new block, respectively.
  • a dynamically changing network architecture Merkle tree including leaf nodes, branch nodes and root nodes of the network architecture Merkle tree
  • the main network node only maintains dynamically changing network architecture information, but does not dynamically maintain a network architecture Merkle tree.
  • the network architecture Merkle tree is temporarily generated based on the network architecture information , thereby reducing the computational cost of maintaining the Merkle tree of the network architecture in real time.
  • the network architecture information when the transaction for changing the network architecture information is received, the network architecture information is changed in time, and the Merkle tree generated based on the network architecture information is anchored to the blockchain main network.
  • the blockchain main network On the block, so that when any verifier needs to verify the network architecture information in the blockchain system, it only needs to obtain the block maintained by the blockchain main network or the verification auxiliary information extracted from the block. It can be realized without complex cross-chain interaction, smart contract invocation and other processes, and realizes a method to maintain and quickly verify the existence of blockchain subnets based on block information.
  • anchoring the root of the Merkle tree of the network architecture to the block header of the new block includes: writing the root of the Merkle tree of the network architecture into the block header of the new block; or , using the root of the Merkle tree of the network architecture as a leaf node of the state tree corresponding to the new block, and writing the calculated state root into the block header of the new block.
  • two methods can be adopted when anchoring the root of the Merkle tree of the network architecture on the block header of the new block.
  • One way is to directly use the root of the Merkle tree of the network architecture as a separate
  • the field is stored in the block header, so that the status of the root of the Merkle tree of the network architecture is the same as the transaction root, status root, and receipt root in the block header.
  • This method can facilitate the verifier to verify the network architecture information with less effort.
  • the verification calculation (only needs to be calculated from the leaf node of the network architecture Merkle tree to the root of the network architecture Merkle tree); another way is to use the tree root of the network architecture Merkle tree as a leaf of the state tree corresponding to the new block node, and calculate a state root anchored to the tree root of the network architecture Merkle tree.
  • this method makes the verifier need to verify the network architecture information, it needs to perform more verification and calculation processes (from the network architecture Merkle tree).
  • the leaf node of the network structure is calculated to the root of the Merkle tree of the network architecture, and then to the state root of the state tree), but this is equivalent to deeply binding the isolated Merkle tree with other transactions that change the state of the world in the block, and These transactions are used as trust certificates of the Merkle tree of the network architecture to improve the credibility of the verifier on the Merkle tree of the network architecture corresponding to the block.
  • the network architecture information is also used to describe the node members contained in the block chain subnet;
  • the subnet identification corresponding to any block chain subnet includes: the node member corresponding to any block chain subnet An information set or a tree root of a subnetwork Merkel tree; wherein, the node membership information set and the leaf nodes of the subnetwork Merkle tree are respectively used to characterize the subnetwork nodes included in any blockchain subnetwork.
  • the network architecture information also includes the node members contained in each block chain subnet, and the subnet identification as the leaf node of the network architecture Merkle tree is used to represent any block chain subnet.
  • the included subnet nodes that is, the leaf nodes of the network architecture Merkle tree can not only represent the blockchain subnet contained in the blockchain system, but also represent the corresponding node members in the corresponding blockchain subnet.
  • the subnet identification corresponding to any block chain subnet may include the node member information set corresponding to any block chain subnet or the root of the subnet Merkel tree, wherein the node member information set may be the corresponding block chain subnet.
  • the node member list for example, the leaf nodes of the network architecture Merkle tree generated by the main network nodes in subnet0 in Figure 1 can be set as the node member list of subnet1 ⁇ nodeA1, nodeB1, nodeC1, nodeD1 ⁇ and the node member list of subnet2 ⁇ nodeA2, nodeB2, nodeC2, nodeE2 ⁇ , or the hash value of the corresponding node member list.
  • the main network node can determine the value of the leaf node of the network architecture Merkle tree based on the network architecture information maintained by itself, so as to further generate a Merkle tree containing network architecture information.
  • the network architecture information contained in the network architecture Merkle tree in the embodiment of this specification is more abundant, so as to assist the verifier to verify more network architecture information including subnetwork node members.
  • the main network node in the blockchain main network is deployed on the node device where the subnet node in any of the blockchain subnets is located;
  • the node member information set includes a character string, so The character bits of the above string correspond to the main network nodes in the blockchain main network one by one, and the value of the character bits is used to indicate whether the node device where the corresponding main network node is located is deployed with any of the zones A subnetwork node in a blockchain subnetwork.
  • it is required that the node device where the subnet node in any blockchain subnet is located is deployed with the main network node in the blockchain main network.
  • the main network Nodes can convert the node membership information of any blockchain subnet in the network architecture information into a string form to represent the subnetwork nodes contained in any blockchain subnet, and the string meets the following format requirements: 1 The number of digits of the string is the same as the number of main network nodes in the blockchain main network; 2 the character bits in the string correspond to the main network nodes in the blockchain main network one by one, and the value of the character bits (for example A value of "0" indicates that it is not deployed, and a value of "1" indicates that it has been deployed) to indicate whether the node device where the corresponding main network node is located is deployed with a subnet node in any of the blockchain subnets; 3 Each character bit in the string is arranged in a preset order, and the preset order includes the order in which each character bit corresponds to the node serial number of the main network node or the device serial number corresponding to the node device where the main network node is located.
  • the Merkle tree of the network structure generated by it includes two leaf nodes, which are the node member information set corresponding to subnet1 and the node member information set of subnet2 respectively from left to right.
  • the string corresponding to the node membership information corresponding to subnet1 is "11110", which is used to indicate that the subnet nodes in subnet1 are deployed on node device 1, node device 2, node device 3, and node device 4 respectively, and the node membership information corresponding to subent2
  • the corresponding character string is "11101", which is used to indicate that the subnetwork nodes in subnet2 are deployed on node device 1, node device 2, node device 3 and node device 5 respectively.
  • the character string containing the node membership information of the blockchain subnet is used as the leaf node of the network architecture Merkel tree, so that the root of the network architecture Merkel tree is anchored with the member information of each blockchain subnet, In this way, the proof of existence of any blockchain subnet node member can be provided to the verifier.
  • the leaf nodes in the subnetwork Merkel tree correspond to the subnetwork nodes contained in any one of the blockchain subnetworks.
  • the subnet identification used as the leaf node of the Merkle tree of the network architecture is specifically the root of the subnet Merkel tree of the blockchain subnet. Therefore, the root of the Merkle tree of the network architecture actually anchors
  • the subtree Merkle tree corresponding to each blockchain subnetwork is created, which contains all network architecture information including the node members of each subnetwork.
  • any blockchain subnet The leaf nodes of the corresponding subtree Merkle tree are only determined by the subnetwork nodes of any blockchain subnetwork. Specifically, the leaf nodes of the subtree Merkle tree correspond to any block The subnetwork nodes contained in the chain subnetwork, and each leaf node needs to be arranged in a preset order to form a subnetwork Merkle tree.
  • the preset order may include the order of the node serial numbers of each leaf node corresponding to the subnetwork node or the The order of the device serial numbers of the node devices, and the value of any leaf node can be the identity information of the corresponding subnet node, such as the node public key or node ID, or any relevant information associated with the subnet node.
  • the manual does not impose any restrictions on this.
  • Figure 4 is a schematic structural diagram of a subnetwork Merkle tree provided by an exemplary embodiment, assuming that the block chain subnetwork corresponding to the subnetwork Merkle tree shown in the figure contains 4 subnetwork nodes, node1 respectively , node3, node5, and node7, so the four leaf nodes corresponding to the Merkle tree of this subnet correspond to node1, node3, node5, and node7 respectively and are arranged in the order shown in the figure, and their specific values from left to right can be The node public key (or the hash value of the node public key) corresponding to node1, node3, node5 and node7, in this embodiment, the four leaf nodes are merged through two hashes to finally obtain the root node, that is, the subnet The root of the Merkle tree, so as to generate a complete subnet Merkle tree.
  • the block chain subnetwork corresponding to the subnetwork Merkle tree shown in the figure contains 4 subnetwork nodes, node1 respectively , node3, no
  • the generation of the subnet Merkle tree is also generated by the main network nodes based on the network architecture information maintained by themselves.
  • the generation method is the same as that of the generated network architecture Similar to the Merkle tree, by using the root of the subtree Merkle tree as the leaf node of the network architecture Merkle tree, the two trees are connected in series, so that the root of the network architecture Merkle tree can finally anchor the blockchain system. Blockchain subnets, and the node members contained in each blockchain subnet.
  • the node device where the subnet node in any of the blockchain subnets is located is deployed with the main network node in the blockchain main network;
  • the leaf node in the Merkel tree of the subnet is a One corresponds to the main network node in the blockchain main network, and the leaf node in the subnet Merkel tree is used to represent whether any block is deployed on the node device where the corresponding main network node is located A subnet node in a chain subnet.
  • it is required that the node device where the subnet node in any blockchain subnet is located is deployed with the main network node in the blockchain main network.
  • any The leaf nodes of the subtree Merkle tree corresponding to the blockchain subnet are jointly determined by the subnet node of any blockchain subnet and the main network node in the blockchain main network, specifically, the subnet
  • the leaf nodes of the tree Merkle tree correspond to the main network nodes contained in the blockchain main network one by one, and each leaf node needs to be arranged in a preset order to form a subnet Merkle tree, and the preset order can be Including the order of the node serial numbers of each leaf node corresponding to the main network node or the equipment serial number of the node device where the node is located, and the value of any leaf node can be the identity of the subnet node in the node device where the corresponding main network node is located Information, or the tag information used to indicate whether the node device where the corresponding main network node is located is deployed with any subnet node in any blockchain subnet, this specification does not make any restrictions on this.
  • Figure 5 is a schematic structural diagram of another subnet Merkle tree provided by an exemplary embodiment, assuming that the blockchain subnet corresponding to the subnet Merkel tree shown in the figure contains a total of 4 subnet nodes, where The device serial numbers of the node devices are node1, node3, node5, and node7 respectively, and the blockchain main network includes 8 main network nodes in total, and the device serial numbers of the node devices where they are located are node1, node2, node3, node4, node5, node6, node7, and node8, then the 8 leaf nodes corresponding to the subnet Merkle tree correspond to node1 ⁇ node8 and are arranged in the order shown in the figure.
  • the specific values can be "existent” and "existent” from left to right.
  • non-existent is used to indicate that the corresponding node device is deployed with the A subnet node in any blockchain subnet
  • “non-existent” is used to indicate that the subnet node in any blockchain subnet is not deployed in the corresponding node device.
  • 8 leaf nodes are merged through three hashes to finally obtain the root node, which is the root of the subnetwork Merkle tree, thereby generating a complete subnetwork Merkle tree. It should be pointed out that the subnetwork The generation of the Merkle tree is also generated by the main network nodes based on the network architecture information maintained by themselves.
  • the root of the subtree Merkle tree As the leaf node of the network architecture Merkle tree, the two trees are connected in series, making the network architecture Merkle
  • the root of the tree can finally anchor the blockchain subnets contained in the blockchain system and the node members contained in each blockchain subnet.
  • the method further includes: when the leaf node of the network architecture Merkel tree is the root of the subnetwork Merkel tree, writing the leaf node of the subnetwork Merkel tree into the new block block body.
  • the main network node can be based on the leaf node of the subnet Merkle tree recorded in the block body when the leaf node of the Merkle tree of the network architecture is the root of the subnet Merkel tree. Restore the subnet Merkle tree, because the subnet Merkel tree contains the node membership information of the corresponding blockchain subnet, which enables the main network node to provide proof of the existence of internal subnet nodes in the blockchain subnet, so as to verify Party provides more types of network architecture information verification services.
  • it also includes: writing the branch nodes of the network architecture Merkle tree into the block body of the new block.
  • the main network node when the main network node generates a new block corresponding to the transaction, it will write the leaf node of the Merkle tree of the network architecture into the block body of the new block, and in the embodiment of this specification , the main network node will not only write the leaf nodes of the network architecture Merkle tree into the block body, but also write the branch nodes of the network architecture Merkle tree, so that the main network node can subsequently restore the block corresponding to the
  • the Merkle tree of the network structure can be directly restored based on the leaf nodes and branch nodes recorded in the block body , especially when the subsequent main network nodes need to provide verification auxiliary information for verifying network architecture information to the verifier, it can greatly reduce the computing burden of the main network nodes and speed up the
  • SPV Simple Payment Verification, simple payment verification
  • SPV Simple payment verification
  • a light node that is, a blockchain node that only maintains the block header in the blockchain, also known as an SPV node
  • SPV node Blockchain nodes that maintain a complete blockchain including block headers and block bodies
  • the implementation process mainly uses the nature of the Merkle tree.
  • leaf nodes arranged in a predetermined order can generate a unique corresponding tree root. Therefore, the existence and unusedness of leaf nodes can be judged by requesting to recalculate the Merkle tree root and comparing it with the reference tree root. Tampering.
  • the main network node that generates a new block is a full node, which maintains a complete blockchain corresponding to the main network of the blockchain, and the main network node receives the target in the network architecture information
  • the SPV verification request initiated by the information it will first determine the block height of the target block that needs to be verified by the SPV verification request, and then find the target block with the corresponding block height, and based on the block body of the target block
  • the leaf nodes of the recorded network architecture Merkle tree restore the network architecture Merkle tree, and then further search for the path of the target information in the network architecture Merkle tree.
  • the target information includes the block chain subnet to be verified in the network architecture
  • the leaf node and/or branch node used to quickly recalculate the tree root of the network architecture Merkle will be selected according to the path of the leaf node as a verification aid information, and return it to the initiator of the SPV verification request, then the initiator can recalculate the root of the Merkle tree of the network architecture by verifying the auxiliary information and target information, and combine it with the target block it maintains
  • the root of the Merkle tree of the network structure in the block header (that is, the reference tree root) is compared. If it is relatively consistent, it can be considered that the blockchain subnet to be verified exists in the current blockchain system.
  • the initiator of the SPV verification request includes: the SPV main network node in the blockchain main network; or, the subnet node deployed on the node device where the SPV main network node is located, and the The subnetwork nodes share the block header maintained by the SPV mainnetwork nodes.
  • the initiator of the SPV verification request usually needs to maintain the block header corresponding to the blockchain main network
  • the initiator can be the SPV main network node in the blockchain main network , this kind of node will only maintain the block chain composed of block headers, but will not maintain a complete block chain including block headers and block bodies, or, the initiator can also be identified by the SPV main network node
  • the subnet node deployed on the node device because the subnet node and the SPV main network node belong to the same node device, therefore, although the subnet node will not directly participate in the maintenance of the block header of the blockchain main network, it can also use
  • the shared plug-in on the node device shares some information with the SPV main network node on the same node device, thereby indirectly maintaining the block header of the blockchain main network.
  • nodeA1 in subnet1 in Figure 1 Take nodeA1 in subnet1 in Figure 1 as an example to verify the existence of subnet2. Since nodeA and nodeA1 are deployed on the same node device 1, nodeA1 can obtain the blockchain main network maintained by nodeA through the shared plug-in deployed on node device 1. Therefore, nodeA1 can initiate an SPV verification request for subnet2 to the full number of nodes in subnet0, such as nodeB. After receiving the SPV verification request, nodeB will restore the network architecture Merkle tree and return the verified auxiliary information to nodeA1, then nodeA1 can complete the process of recalculating the Merkle tree root and tree root comparison after receiving the verification auxiliary information, thereby completing the verification of the existence of subnet2.
  • Fig. 6 is a flowchart of a method for verifying network architecture information of a blockchain system provided by an exemplary embodiment.
  • the blockchain system includes a blockchain main network and a blockchain subnet managed by the blockchain main network, and the network architecture information is used to describe the blockchain subnet contained in the blockchain system ;
  • the method includes the following steps.
  • Step 602 Initiate an SPV verification request for the target information in the network architecture information to the full number of main network nodes in the blockchain main network, and the main network blocks maintained by the full number of main network nodes record the The network architecture Merkle tree generated by the network architecture information, wherein the block header is used to anchor the root of the network architecture Merkle tree, the block body records the leaf nodes of the network architecture Merkle tree, and the network architecture The leaf node of the Merkle tree is the subnet identifier corresponding to the blockchain subnet in the blockchain system.
  • Step 604 Receive the auxiliary verification information determined and returned by the full number of main network nodes from the Merkle tree of the network architecture.
  • the full number of main network nodes will select the leaf nodes and/or branch nodes used to quickly recalculate the root of the Merkle tree of the network architecture according to the path of the target information in the Merkle tree of the network architecture as verification auxiliary information.
  • Step 606 Perform 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.
  • This step is mainly to use the target information and verification auxiliary information to recalculate the root of the Merkle tree of the network structure, and then compare the calculated tree root to be verified with the network structure recorded on the block header of the main network block maintained by the SPV main network node
  • the root of the Merkle tree (that is, the root of the reference tree) is compared, and the existence of the target information can be proved when the comparison is consistent.
  • the SPV verification request carries the block height of the required main network block. Therefore, all main network nodes can determine the corresponding main network block maintained by themselves based on the block height, and Obtain the leaf nodes of the network architecture Merkle tree from its block body to generate the network architecture Merkle tree, so the verification auxiliary information obtained by the initiator of SPV verification is determined based on the main network block corresponding to the height of the block.
  • the SPV verification request carries the block height of the required main network block
  • the full number of main network nodes will not generate the network architecture based on the block body of the block corresponding to the block height
  • the Merkle tree will generate a network architecture Merkle tree according to the dynamically changing network architecture information maintained by itself. Due to the lag of the network structure Merkle tree anchored on the block (because there is a phenomenon that the transaction used to change the network structure information has been executed but has not yet been packaged to form a block), therefore, the full number of nodes on the main network
  • the generated network architecture Merkle tree is real-time and can overcome SPV verification errors caused by the above-mentioned hysteresis.
  • the initiator of the SPV verification request can initiate an SPV verification request to any network node that maintains a complete blockchain corresponding to the blockchain main network, in addition to sending an SPV verification request to all main network nodes.
  • Request because the block body of the main network block involved in this specification contains the leaf nodes used to restore the Merkle tree of the network architecture, so only the block of the main network block corresponding to the blockchain main network needs to be maintained The body can provide the initiator of the SPV verification request with proof of the existence of the network architecture information of the blockchain system.
  • the initiator of the SPV verification request includes: the SPV main network node, or the subnet node deployed on the node device where the SPV main network node is located, and the subnet node shares the The block header maintained by the SPV main network node.
  • the target information includes the value of the leaf node corresponding to the block chain subnet to be verified in the Merkle tree of the network architecture.
  • the network architecture information is also used to describe the node members contained in the blockchain subnet;
  • the subnet identification corresponding to any blockchain subnet includes: the node member information set or subnet corresponding to any blockchain subnet The tree root of the network Merkel tree; wherein, the node member information set and the leaf nodes of the subnet Merkle tree are respectively used to characterize the subnet nodes contained in any blockchain subnet.
  • the target information may include: a set of member information of nodes to be verified corresponding to the blockchain subnet to be verified; or, the subnetwork nodes to be verified contained in the blockchain subnet to be verified are in the The value of the corresponding leaf node in the Merkle tree.
  • the full number of main network nodes can not only provide proof of the existence of the subnet, but also provide proof of the existence of node members in the subnet.
  • the initiator of the SPV verification request can request verification specific The existence of specific subnet nodes in the blockchain subnet, in this case, the full main network nodes also need to maintain the subnet Merkle tree corresponding to each blockchain subnet, so that the subnet corresponding to the specific blockchain subnet.
  • the verification auxiliary information determined in the network Merkle tree and the verification auxiliary information determined from the network architecture Merkle tree are returned to the initiator together, so that the initiator can recalculate the tree of the network architecture Merkle tree based on these verification auxiliary information root.
  • the blockchain system involved in the embodiment of this specification contains a total of 4 blockchain subnets, and the structure of the network architecture Merkle tree corresponding to the blockchain system is shown in Figure 3, where the leftmost leaf node The Merkle tree structure of the subnet corresponding to the first blockchain subnet is shown in Figure 4.
  • the node members of the first blockchain subnet include node1, node3, node5 and node7.
  • the verifier wishes to verify whether node1 is deployed in the first blockchain subnet, he can initiate an attack on the first blockchain subnet to the full number of mainnet nodes in the blockchain mainnet.
  • the SPV verification request will include the subnet ID of the first blockchain subnet and the node public key of node1.
  • all main network nodes After receiving the SPV verification request, all main network nodes first generate a network architecture Merkle tree based on the leaf nodes of the network architecture Merkle tree recorded in the block body, and then generate a network architecture Merkle tree based on the subnet of the first blockchain subnet carried in the SPV verification request.
  • the network identifier determines that the subnet that the verifier needs to verify is the first blockchain subnet, and determines the path of the leaf node corresponding to the block chain subnet to be verified in the generated network architecture Merkle tree (the path is used to represent the leaf The node is the leftmost leaf node in the Merkle tree of the network architecture), so it is determined in the Merkle tree of the network architecture that the verification auxiliary information corresponding to the leaf node is the leaf node A and the branch node B shown in Figure 3 .
  • the full main network node needs to further provide verification auxiliary information for verifying whether node1 is included in the first blockchain subnet, specifically, the full main network
  • the node will generate the subnet Merkle tree corresponding to the first blockchain subnet based on the leaf nodes of the subnet Merkle tree corresponding to the first blockchain subnet recorded in the block body, and then determine the node to be verified according to the node public key of node1
  • the path of the corresponding leaf node (the path is used to represent that the leaf node is the leftmost leaf node in the subnetwork Merkle tree of the first blockchain subnetwork), so that the leaf node is determined in the subnetwork Merkle tree Verification auxiliary information corresponding to a point is leaf node a and branch node b shown in FIG. 4 .
  • the verifier After receiving the verification auxiliary information corresponding to the above SPV verification request, the verifier will recalculate the root of the Merkle tree of the network architecture according to the node public key of node1 and the verification auxiliary information.
  • the verifier After recalculating the root of the Merkle tree of the network architecture, the verifier compares it with the root of the Merkle tree of the network architecture (reference tree root) recorded in the block header maintained by itself. If the two are the same, it can prove that Node1 does exist in the first blockchain subnet, if the two are different, it cannot prove that node1 does exist in the first blockchain subnet.
  • Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 702 , an internal bus 704 , a network interface 706 , a memory 708 and a non-volatile memory 710 , and of course it may also include hardware required by other services.
  • the processor 702 reads a corresponding computer program from the non-volatile memory 710 into the memory 708 and then executes it.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.
  • FIG. 8 is a block diagram of a device for maintaining network architecture information of a blockchain system according to an exemplary embodiment provided in this specification.
  • the device can be applied to the device shown in FIG. 7 to
  • the blockchain system includes a blockchain main network and a blockchain subnet managed by the blockchain main network, and the network architecture information is used to describe the information contained in the blockchain system.
  • the block chain subnet; the device is applied to the main network node in the block chain main network, and the device includes: a structure change unit 801, which is used to receive a transaction for changing the network structure information; wherein , in the network architecture Merkle tree generated based on the network architecture information, the leaf node is the subnet identifier corresponding to the blockchain subnet in the blockchain system; the block generation unit 802 is used to generate When a new block of the above transaction is made, anchor the root of the Merkle tree of the network architecture to the block header of the new block, and write the leaf nodes of the Merkle tree of the network architecture into the block body of the new block .
  • a structure change unit 801 which is used to receive a transaction for changing the network structure information
  • the leaf node is the subnet identifier corresponding to the blockchain subnet in the blockchain system
  • the block generation unit 802 is used to generate When a new block of the above transaction is made, anchor the root of the Merkle tree of the network architecture to the block header of the new block, and
  • the network architecture information is also used to describe the node members contained in the block chain subnet;
  • the subnet identification corresponding to any block chain subnet includes: the node member corresponding to any block chain subnet An information set or a tree root of a subnetwork Merkel tree; wherein, the node membership information set and the leaf nodes of the subnetwork Merkle tree are respectively used to characterize the subnetwork nodes included in any blockchain subnetwork.
  • the main network node in the blockchain main network is deployed on the node device where the subnet node in any of the blockchain subnets is located;
  • the node member information set includes a character string, so The character bits of the above string correspond to the main network nodes in the blockchain main network one by one, and the value of the character bits is used to indicate whether the node device where the corresponding main network node is located is deployed with any of the zones A subnetwork node in a blockchain subnetwork.
  • the leaf nodes in the subnetwork Merkel tree correspond to the subnetwork nodes contained in any one of the blockchain subnetworks.
  • the node device where the subnet node in any of the blockchain subnets is located is deployed with the main network node in the blockchain main network;
  • the leaf node in the Merkel tree of the subnet is a One corresponds to the main network node in the blockchain main network, and the leaf node in the subnet Merkel tree is used to represent whether any block is deployed on the node device where the corresponding main network node is located A subnet node in a chain subnet.
  • the device further includes: a node writing unit 803, configured to write the subnetwork Merkel tree to The leaf node writes the block body of the new block.
  • a node writing unit 803 configured to write the subnetwork Merkel tree to The leaf node writes the block body of the new block.
  • the block generation unit 802 is specifically configured to: write the root of the network architecture Merkle tree into the block header of the new block; or use the root of the network architecture Merkle tree as the The new block corresponds to a leaf node of the state tree, and the calculated state root is written into the block header of the new block.
  • an SPV verification unit 804 configured to receive an SPV verification request initiated for the target information in the network architecture information; and determine corresponding verification auxiliary information from the network architecture Merkle tree, And return to the initiator of the SPV verification request.
  • the initiator of the SPV verification request includes: the SPV main network node in the blockchain main network; or, the subnet node deployed on the node device where the SPV main network node is located, and the The subnetwork nodes share the block header maintained by the SPV mainnetwork nodes.
  • the transaction includes at least one of the following: a subnet registration transaction for creating a new blockchain subnet; a subnet exit transaction for deleting an existing blockchain subnet; The subnet nodes of the node members of the block chain subnet adjust the transaction.
  • the device further includes: a node start-stop unit 805, configured to generate a network architecture change event corresponding to the transaction, and the network architecture change event is used to indicate that the node device where the main network node is located is based on execution The corresponding node starts and stops operations, so that the network architecture of the blockchain system matches the changed network architecture information.
  • a node start-stop unit 805 configured to generate a network architecture change event corresponding to the transaction, and the network architecture change event is used to indicate that the node device where the main network node is located is based on execution The corresponding node starts and stops operations, so that the network architecture of the blockchain system matches the changed network architecture information.
  • FIG. 9 is a block diagram of a device for verifying network architecture information of a blockchain system according to an exemplary embodiment provided in this specification.
  • the device can be applied to the device shown in FIG. 7 to
  • the blockchain system includes a blockchain main network and a blockchain subnet managed by the blockchain main network, and the network architecture information is used to describe the information contained in the blockchain system.
  • the block chain subnet includes: a request unit 901, configured to initiate an SPV verification request for the target information in the network architecture information to the full amount of main network nodes in the block chain main network, the full amount
  • the network architecture Merkle tree generated based on the network architecture information is recorded in the main network block maintained by the main network node, where the block header is used to anchor the root of the network architecture Merkle tree, and the block body records the The leaf node of the network architecture Merkle tree, and the leaf node of the network architecture Merkle tree is the subnet identification corresponding to the blockchain subnet in the blockchain system
  • the receiving unit 902 is used to receive the full main network
  • the verification unit 903 is configured to, based on the verification auxiliary information and the block header of the main network block maintained by the SPV main network node, verify the The target information is verified by SPV.
  • the initiator of the SPV verification request includes: the SPV main network node, or a subnet node deployed on a node device where the SPV main network node is located, and the subnet node shares the SPV The block header maintained by the main network nodes.
  • the target information includes the value of the corresponding leaf node of the block chain subnet to be verified in the Merkle tree of the network architecture.
  • the network architecture information is also used to describe the node members contained in the block chain subnet;
  • the subnet identification corresponding to any block chain subnet includes: the node member corresponding to any block chain subnet An information set or a tree root of a subnetwork Merkel tree; wherein, the node membership information set and the leaf nodes of the subnetwork Merkle tree are respectively used to characterize the subnetwork nodes included in any blockchain subnetwork.
  • the target information includes: a member information set of nodes to be verified corresponding to the block chain subnet to be verified; or, the subnetwork nodes to be verified contained in the block chain subnet to be verified correspond to in the Merkle tree of the subnetwork The value of the leaf node of .
  • this specification also provides a device, the device includes a processor; a memory for storing processor-executable instructions; wherein, the processor is configured to realize the implementation, maintenance or Steps in a method of verifying network architecture information of a blockchain system.
  • this specification also provides a computer-readable storage medium on which executable instructions are stored; wherein, when the instructions are executed by the processor, the implementation, maintenance or verification of the blockchain system provided by all the above-mentioned method embodiments can be realized.
  • the steps of the method of network architecture information can be realized.
  • the device embodiment since it basically corresponds to the method embodiment, for related parts, please refer to the part description of the method embodiment.
  • the device embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. It can be understood and implemented by those skilled in the art without creative effort.
  • a typical implementing device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.
  • the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can 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, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions
  • the device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • 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 Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word “if” as used herein may be interpreted as “at” or "when” or "in response to a determination.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本说明书提供一种维护区块链系统的网络架构信息的方法和装置。所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法应用于所述区块链主网中的主网节点,所述方法包括:接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。

Description

维护区块链系统的网络架构信息 技术领域
本说明书一个或多个实施例涉及区块链技术领域,尤其涉及一种维护区块链系统的网络架构信息的方法和装置。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。区块链网络中的节点利用链式数据结构来验证与存储数据,并采用分布式节点共识算法来生成和更新数据。在一些区块链网络中,部分节点有时存在实现小范围交易的需求,以避免其他节点获得这些交易及其相关数据。因此可以在区块链主网的基础上进一步建立区块链子网,从而构成一个包含区块链主网和区块链子网的区块链系统。
由于不同区块链子网之间相互隔离,彼此之间无法及时地交换信息,因此对于某一区块链子网而言,其无法知晓其他区块链子网的子网信息,特别是在区块链系统的网络架构发生变化时,将导致各区块链子网所分别维护的区块链系统的网络架构信息不对称,例如将已经退出的特定区块链子网误认为仍然处于运行状态,从而影响各区块链子网之间跨链交互的正常运作。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种维护和验证区块链系统的网络架构信息的方法、装置、电子设备和存储介质。
为实现上述目的,本说明书一个或多个实施例提供技术方案如下。
根据本说明书一个或多个实施例的第一方面,提出了一种维护区块链系统的网络架构信息的方法,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法应用于所述区块链主网中的主网节点,所述方法包括:接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
根据本说明书一个或多个实施例的第二方面,提出了一种验证区块链系统的网络架构信息的方法,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法包括:向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识;接收所述全量主网节点从所述网络架构Merkle树中确定并返回的验证辅助信息;基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。
根据本说明书一个或多个实施例的第三方面,提出了一种维护区块链系统的网络架构信息的装置,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置应用于所述区块链主网中的主网节点,所述装置包括:架构变更单元,用于接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;区块生成单元,用于在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
根据本说明书一个或多个实施例的第四方面,提出了一种验证区块链系统的网络架 构信息的装置,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置包括:请求单元,用于向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识;接收单元,用于接收所述全量主网节点从所述网络架构Merkle树中确定并返回的验证辅助信息;验证单元,用于基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。
根据本说明书实施例的第五方面,提供一种电子设备,包括处理器和用于存储处理器可执行指令的存储器。其中,所述处理器通过运行所述可执行指令以实现上述维护或验证区块链系统的网络架构信息的方法的步骤。
根据本说明书实施例的第六方面,提供一种计算机可读存储介质,其上储存有可执行指令;其中,该指令被处理器执行时,实现上述维护或验证区块链系统的网络架构信息的方法的步骤。
附图说明
图1是一示例性实施例提供的一种基于区块链主网组建区块链子网的示意图。
图2是一示例性实施例提供的一种维护区块链系统的网络架构信息的方法的流程图。
图3是一示例性实施例提供的一种网络架构Merkle树的结构示意图。
图4是一示例性实施例提供的一种子网Merkle树的结构示意图。
图5是一示例性实施例提供的另一种子网Merkle树的结构示意图。
图6是一示例性实施例提供的一种验证区块链系统的网络架构信息的方法的流程图。
图7是一示例性实施例提供的一种设备的结构示意图。
图8是一示例性实施例提供的一种维护区块链系统的网络架构信息的装置的框图。
图9是一示例性实施例提供的一种验证区块链系统的网络架构信息的装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
由于区块链网络的去中心化特性,使得区块链网络中的所有区块链节点均会维护相同的区块数据,无法满足部分节点的特殊需求。以联盟链为例,所有联盟成员(即联盟内的节点成员)可以组成一区块链网络,所有联盟成员在该区块链网络中分别存在对应的区块链节点,并可以通过对应的区块链节点获得该区块链网络上发生的所有交易和相关数据。但在一些情况下,可能存在部分联盟成员希望完成一些具有保密需求的交易,这些联盟成员既希望这些交易能够在区块链上存证或借助于区块链技术的其他优势,又能够避免其他联盟成员查看到这些交易和相关数据。虽然这些联盟成员可以额外组建一新的区块链网络,其建立方式与上述包含所有联盟成员的区块链网络类似,但是从头开始建立一条新的区块链网络需要消耗大量的资源,且无论是该区块链网络的建立过程或是建成后的配置过程都非常耗时。联盟成员之间的需求往往是临时的或者具有一定的时效性,使得新建的区块链网络很快就会由于需求消失而失去存在的意义,从而进一步增 加了上述区块链网络的建链成本。而联盟成员之间的需求经常会变化,而每一需求所对应的联盟成员也往往不同,因而每当联盟成员发生变化时就可能需要组建一新的区块链网络,从而造成资源和时间的大量浪费。
为此,可以将已组建的区块链网络作为区块链主网,并在该区块链主网的基础上组建区块链子网。那么,在诸如上述的联盟链场景下,联盟成员可以在已经参与区块链主网的情况下,基于自身需求而在区块链主网的基础上组建所需的区块链子网。由于区块链子网是在区块链主网的基础上所建立,使得区块链子网的组建过程相比于完全独立地组建一条区块链网络,所消耗的资源和所需的耗时等都极大地降低,灵活性极高。
基于区块链主网快捷组建区块链子网的过程如下:区块链主网中的各区块链节点分别获取组建区块链子网的交易,所述交易包含所述区块链子网的配置信息,所述配置信息包括参与组建所述区块链子网的节点成员的身份信息,所述区块链主网中的各区块链节点分别执行所述交易以透出所述配置信息,当所述配置信息包含第一区块链节点对应的节点成员的身份信息时,部署第一区块链节点的节点设备基于所述包含所述配置信息的创世块启动属于所述区块链子网的第二区块链节点。
以图1所示为例,区块链主网为subnet0,该subnet0包含的区块链节点为nodeA、nodeB、nodeC、nodeD和nodeE等。假定nodeA、nodeB、nodeC和nodeD希望组建一区块链子网:如果nodeA为管理员且仅允许管理员发起组建区块链子网的交易,那么可由nodeA向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员且仅允许管理员发起组建区块链子网的交易,那么nodeA~nodeD需要向nodeE进行请求,使得nodeE向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员但允许普通用户发起组建区块链子网的交易,那么nodeA~nodeE均可以向subnet0发起上述组建区块链子网的交易。当然,不论是管理员或者普通用户,发起组建区块链子网的交易的区块链节点并不一定参与所组建的区块链子网,比如虽然最终由nodeA、nodeB、nodeC和nodeD组建区块链子网,但可由nodeE向subnet0发起上述组建区块链子网的交易,而并不一定由nodeA~nodeD来发起该组建区块链子网的交易。
在区块链主网的基础上组建区块链子网时,容易理解的是,会使得该区块链子网与区块链主网之间存在逻辑上的层次关系。比如在图1所示的subnet0上组建区块链子网subnet1时,可以认为subnet0处于第一层、subnet1处于第二层。一种情况下,本说明书中的区块链主网可以为底层区块链网络,即区块链主网并非在其他区块链网络的基础上组建的区块链子网,比如图1中的subnet0可以认为属于底层区块链网络类型的区块链主网。另一种情况下,本说明书中的区块链主网也可以为其他区块链网络的子网,比如可以在图1中subnet1的基础上进一步组建另一区块链子网,此时可以认为subnet1为该区块链子网对应的区块链主网,而这并不影响该subnet1同时属于subnet0上创建的区块链子网。可见,区块链主网与区块链子网实际上是相对概念,同一区块链网络在一些情况下可以为区块链主网、另一些情况下可以为区块链子网。
上述组建区块链子网的交易在被发送至区块链主网后,由区块链主网内的共识节点进行共识,并在通过共识后由各主网节点执行该交易,以完成区块链子网的组建。共识过程取决于所采用的共识机制,本说明书并不对此进行限制。
通过在上述组建区块链子网的交易中包含配置信息,该配置信息可以用于对所组建的区块链子网进行配置,使得组建的区块链子网符合组网需求。例如,通过在配置信息中包含节点成员的身份信息,可以指定组建的区块链子网包含哪些区块链节点。
节点成员的身份信息可包括节点的公钥,或者采用节点ID等其他能够表征节点身份的信息,本说明书并不对此进行限制。以公钥为例,每个区块链节点都存在对应的一组或多组公私钥对,由区块链节点持有私钥而公钥被公开且唯一对应于该私钥,因而可通过公钥来表征相应区块链节点的身份。因此,对于希望作为区块链子网的节点成员的区块链节点,可将这些区块链节点的公钥添加至上述组建区块链子网的交易中,以作为上述节点成员的身份信息。上述的公私钥对可用于签名验证的过程。例如,在采用有签名的共识算法中,譬如subnet1上述的nodeA1采用自身维护的私钥对消息进行签名后,将经过签名的消息在subnet1中广播,而nodeB1、nodeC1和nodeD1可用nodeA1的公钥 对收到的消息进行签名验证,以确认自身收到的消息确实来自nodeA1且没有经过篡改。
第一主网节点可以为区块链主网上属于配置信息所指示的节点成员的区块链节点。在组建区块链子网时,并非由第一主网节点直接参与组建区块链子网、成为其节点成员,而是需要由用于部署该第一主网节点的节点设备生成第一子网节点,并由第一子网节点成为区块链子网中的节点成员。第一主网节点和第一子网节点对应于同一个区块链成员,比如在联盟链场景下对应于同一联盟链成员,但第一主网节点属于区块链主网、第一子网节点属于区块链子网,使得该区块链成员可以分别参与到区块链主网和区块链子网的交易中;并且,由于区块链主网和区块链子网属于相互独立的两个区块链网络,使得第一主网节点生成的区块与第一子网节点生成的区块分别存入所述节点设备上的不同存储(采用的存储譬如可以为数据库),实现了第一主网节点与第一子网节点分别使用的存储之间的相互隔离,因而区块链子网所产生的数据仅会在区块链子网的节点成员之间同步,使得仅参与了区块链主网的区块链成员无法获得区块链子网上产生的数据,实现了区块链主网与区块链子网之间的数据隔离,满足了部分区块链成员(即参与区块链子网的区块链成员)之间的交易需求。
可见,第一主网节点和第一子网节点是在逻辑上划分出来的区块链节点,而从物理设备的角度来说,相当于上述部署了第一主网节点和第一子网节点的节点设备同时参与了区块链主网和区块链子网。由于区块链主网与区块链子网之间相互独立,使得这两个区块链网络的身份体系也相互独立,因而即便第一主网节点和第一子网节点可以采用完全相同的公钥,仍然应当将两者视为不同的区块链节点。譬如在图1中,subnet0中的nodeA相当于第一主网节点,而部署该nodeA的节点设备生成了属于subnet1的nodeA1,该nodeA1相当于第一子网节点。可见,由于身份体系相互独立,所以即便第一子网节点所采用的公钥区别于第一主网节点,也不影响本说明书方案的实施。
当然,区块链子网的节点成员并不一定只是区块链主网的部分节点成员。在一些情况下,区块链子网的节点成员可以与区块链主网的节点成员完全一致,此时所有的区块链成员都可以获得区块链主网和区块链子网上的数据,但是区块链主网与区块链子网所产生的数据依然可以相互隔离,比如可以通过在区块链主网上实现一类业务、在区块链子网上实现另一类业务,从而可以使得这两类业务分别产生的业务数据之间相互隔离。
除了上述的节点成员的身份信息之外,配置信息还可以包括下述至少之一:所述区块链子网的网络标识、所述区块链子网的管理员的身份信息、针对区块链平台代码的属性配置等,本说明书并不对此进行限制。网络标识用于唯一表征该区块链子网,因而该区块链子网的网络标识应当区别于区块链主网和该区块链主网上组建的其他区块链子网。区块链子网的管理员的身份信息,譬如可以为作为管理员的节点成员的公钥;其中,区块链主网与区块链子网的管理员可以相同,也可以不同。
通过区块链主网来组建区块链子网的优势之一,就是由于生成第一子网节点的节点设备上已经部署了第一主网节点,因而可以将第一主网节点所使用的区块链平台代码复用在第一子网节点上,免去了区块链平台代码的重复部署,极大地提高了区块链子网的组建效率。那么,如果配置信息中未包含针对区块链平台代码的属性配置,第一子网节点可以复用第一主网节点上采用的属性配置;如果配置信息中包含了针对区块链平台代码的属性配置,第一子网节点可以采用该属性配置,使得第一子网节点所采用的属性配置不受限于第一主网节点的属性配置、与第一主网节点无关。针对区块链平台代码的属性配置可以包括下述至少之一:代码版本号、是否需要共识、共识算法类型、区块大小等,本说明书并不对此进行限制。
组建区块链子网的交易包括调用合约的交易。该交易中可以指明被调用的智能合约的地址、调用的方法和传入的参数。例如,调用的合约可以为前述的创世合约或系统合约,调用的方法可以为组建区块链子网的方法,传入的参数可以包括上述的配置信息。在一实施例中,该交易可以包含如下信息:from:Administrator to:Subnet method:AddSubnet(string)string:genesis其中,from字段为该交易的发起方的信息,譬如Administrator表明该发起方为管理员;to字段为被调用的智能合约的地址,譬如该智能合约可以为Subnet合约,则to字段具体为该Subnet合约的地址;method字段为调用的 方法,譬如在Subnet合约中用于组建区块链子网的方法可以为AddSubnet(string),而string为AddSubnet()方法中的参数,上述示例中通过genesis表征该参数的取值,该genesis具体为前述的配置信息。
以Subnet0上的节点nodeA~nodeE执行调用Subnet合约中AddSubnet()方法的交易为例。在交易通过共识后,nodeA~nodeE分别执行AddSubnet()方法并传入配置信息,得到相应的执行结果。
区块链网络中的节点在执行调用智能合约的交易后,会生成相应的收据(receipt),以用于记录与执行该智能合约相关的信息。这样,可以通过查询交易的收据来获得合约执行结果的相关信息。合约执行结果可以表现为收据中的事件(event)。消息机制可以通过收据中的事件实现消息传递,以触发区块链节点执行相应的处理。事件的结构譬如可以为:Event:[topic][data][topic][data]......在上述示例中,事件的数量可以为一个或多个;其中,每个事件分别包括主题(topic)和数据(data)等字段。区块链节点可以通过监听事件的topic,从而在监听到预定义的topic的情况下,执行预设处理,或者从相应事件的data字段读取相关内容,以及可以基于读取的内容执行预设处理。
上述的事件机制中,相当于在监听方(比如存在监听需求的用户)处存在具有监听功能的客户端,譬如该客户端上运行了用于实现监听功能的SDK等,由该客户端对区块链节点产生的事件进行监听,而区块链节点只需要正常生成收据即可。除了上述的事件机制之外,还可以通过其他方式实现交易信息的透出。例如,可以通过在区块链节点运行的区块链平台代码中嵌入监听代码,使得该监听代码可以监听区块链交易的交易内容、智能合约的合约状态、合约产生的收据等其中的一种或多种数据,并将监听到的数据发送至预定义的监听方。由于监听代码部署于区块链平台代码中,而非监听方的客户端处,因而相比于事件机制而言,这种基于监听代码的实现方式相对更加的主动。其中,上述的监听代码可以由区块链平台的开发人员在开发过程中加入区块链平台代码,也可以由监听方基于自身的需求而嵌入,本说明书并不对此进行限制。
可见,上述Subnet合约的执行结果可以包括所述配置信息,该执行结果可以处于前文所述的收据中,该收据中可以包含与执行AddSubnet()方法相关的event,即组网事件。组网事件的topic可以包含预定义的组网事件标识,以区别于其他的事件。譬如在与执行AddSubnet()方法相关的event中,topic的内容为关键词subnet,且该关键词区别于其他方法所产生event中的topic。那么,nodeA~nodeE通过监听生成的收据中各个event所含的topic,可以在监听到包含关键词subnet的topic的情况下,确定监听到与执行AddSubnet()方法相关的event,即组网事件。例如,收据中的event如下:Event:[topic:other][data][topic:subnet][data]......那么,nodeA~nodeE在监听到第1条event时,由于所含topic的内容为other,确定该event与AddSubnet()方法无关;以及,nodeA~nodeE在监听到第2条event时,由于所含topic的内容为subnet,确定该event与AddSubnet()方法相关,并进而读取该event对应的data字段,该data字段包含上述的配置信息。以配置信息包括区块链子网的节点成员的公钥为例,data字段的内容例如可以包括:{subnet1;nodeA的公钥,nodeA的IP、nodeA的端口号…;nodeB的公钥,nodeB的IP、nodeB的端口号…;nodeC的公钥,nodeC的IP、nodeC的端口号…;nodeD的公钥,nodeD的IP、nodeD的端口号…;}其中,subnet1为希望创建的区块链子网的网络标识。区块链主网中的各个区块链节点可以记录该区块链主网上已创建的所有区块链子网的网络标识,或者与这些区块链子网相关的其他信息,这些信息譬如可以维护在上述的Subnet合约中,具体可以对应于该Subnet合约所含的一个或多个合约状态的取值。那么,nodeA~nodeE可以根据记录的已创建的所有区块链子网的网络标识,确定上述的subnet1是否已经存在;如果不存在,说明subnet1是当前需要创建的新区块链子网,如果存在则说明subnet1已经存在。
除了采用希望创建的新的区块链子网的网络标识之外,还可以采用预定义的新建网络标识,该新建网络标识表明相应的组网事件用于组建新的区块链子网。例如,可以将上述的subnet1替换为newsubnet,该newsubnet为预定义的新建网络标识,nodeA~nodeE在识别到data字段包含newsubnet时,即可确定包含该newsubnet的event为组网事件, 需要创建新的区块链子网。
除了网络标识subnet1之外,上述data字段中还包含各个节点成员的身份信息等内容。部署第一主网节点的节点设备可以监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一主网节点属于所述节点成员的情况下,由部署第一主网节点的节点设备获取所述组网事件包含的配置信息或创世块。或者,第一区块链节点可以监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一区块链节点属于所述节点成员的情况下,触发部署第一区块链节点的节点设备获取所述组网事件包含的所述配置信息或所述创世块。
如前所述,节点设备可以直接监听收据。假定nodeA~nodeE分别部署在节点设备1~5上,节点设备1~5可以监听nodeA~nodeE分别生成的收据,那么在监听到subnet1是需要新组建的区块链子网的情况下,节点设备1~5会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。以nodeA和节点设备1为例:如果节点设备1发现data字段包含nodeA的公钥、IP地址和端口号等身份信息,那么节点设备1在基于上述的消息机制从data字段获得配置信息的情况下,生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,进而由nodeA1加载生成的创世块,从而成为subnet1的子网节点;类似地,节点设备2可以生成nodeB1、节点设备3可以生成nodeC1、节点设备4可以生成nodeD1。以及,节点设备5会发现data字段包含的身份信息与自身均不匹配,则该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的区块链节点。
如前所述,区块链主网中的区块链节点可监听收据,并根据监听结果触发节点设备执行相关处理。例如,nodeA~nodeE在确定subnet1是需要新组建的区块链子网的情况下,会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。比如,nodeA~nodeD会发现在data字段包含自身的公钥、IP地址和端口号等身份信息,假定nodeA~nodeD分别部署在节点设备1~4上,以nodeA和节点设备1为例:nodeA会触发节点设备1,使得节点设备1基于上述的消息机制从data字段获得配置信息并生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,该nodeA1加载生成的创世块,从而成为subnet1中的1个子网节点;类似地,nodeB会触发节点设备2生成nodeB1、nodeC会触发节点设备3生成nodeC1、nodeD会触发节点设备4生成nodeD1。以及,nodeE会发现data字段包含的身份信息与自身均不匹配,假定nodeE部署在节点设备5上,那么该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的节点。
如前所述,第一主网节点与第一子网节点并不一定采用相同的身份信息。因此,在上述实施例中,data字段中可以包含预先为nodeA1~nodeD1生成的身份信息,且区别于nodeA~nodeD的身份信息。仍以nodeA和节点设备1为例:节点设备1如果在data字段中发现了nodeA1的身份信息,可以生成创世块、部署nodeA1,并由nodeA1加载该创世块;或者,nodeA如果在data字段中发现了nodeA1的身份信息,那么nodeA会触发节点设备1生成创世块、部署nodeA1,并由nodeA1加载该创世块。其他区块链节点或节点设备的处理方式类似,此处不再一一赘述。
除了配置信息之外,合约的执行结果可以包括创世块。换言之,除了可以在data字段中包含配置信息,还可以直接在执行合约调用的过程中生成包含配置信息的创世块,从而将创世块包含于data字段中,那么对于上述的nodeA~nodeD而言,相应的节点设备1~4可以通过消息机制直接从data字段获得创世块,而无需自行生成,可以提升对nodeA1~nodeD1的部署效率。
节点设备通过在该进程中创建一个运行区块链平台代码的实例,实现在该节点设备上部署一区块链节点。对于第一主网节点而言,由节点设备在上述进程中创建第一实例,并由该第一实例运行区块链平台代码而形成。类似地,对于第一子网节点而言,由节点设备在上述进程中创建区别于第一实例的第二实例,并由该第二实例运行区块链平台代码而形成。例如,节点设备可首先在进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可在上述进 程中创建第二实例,该第二实例区别于上述的第一实例,并由该第二实例形成区块链子网中的第二区块链节点。当第一实例与第二实例位于同一进程时,由于不涉及跨进程交互,可降低对第一子网节点的部署难度、提高部署效率;当然,第二实例也可能与第一实例分别处于节点设备上的不同进程中,本说明书并不对此进行限制;例如,节点设备可以在第一进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可启动区别于第一进程的第二进程,并在该第二进程中创建第二实例,该第二实例区别于上述的第一实例,进而由该第二实例形成区块链子网中的第二区块链节点。事实上,本说明书实施例中涉及的任一节点设备上部署的各区块链节点均为运行在所述任一节点设备上的不同的区块链实例,任一节点设备上部署的各区块链节点生成的区块分别存入所述任一节点设备上的不同存储(例如数据库),且任一节点设备部署的各区块链节点分别使用的存储之间相互隔离。
通过上述方式,可以在区块链主网上创建出区块链子网。以图1为例,subnet0原本包含nodeA~nodeE,而在subnet0的基础上可以组建出subnet1,该subnet1包含nodeA1~nodeD1,且nodeA与nodeA1、nodeB与nodeB1、nodeC与nodeC1、nodeD与nodeD1分别部署在同一节点设备上。类似地,还可以在subnet0上组建出subnet2或更多的区块链子网,其中subnet2包含nodeA2、nodeB2、nodeC2和nodeE2,且nodeA与nodeA1、nodeA2,nodeB与nodeB1、nodeB2,nodeC与nodeC1,nodeD与nodeD1,nodeE与nodeE2分别部署在同一节点设备上。以及,可以将subnet1、subnet2等作为新的区块链主网,并在此基础上进一步组建出区块链子网,其过程与subnet1或subnet2的组建相似,此处不再赘述。可见,上述在区块链主网上发起交易选取节点成员以创建区块链子网的方式,可以使得新创建的区块链子网的子网节点均部署在区块链主网的主网节点所在的节点设备上,也就是从节点设备的角度上来说,区块链子网的子网节点所在的节点设备属于主网节点所在节点设备的子集,换言之,部署有区块链子网的子网节点所处的节点设备上部署有区块链主网中的主网节点。
除了通过上述在区块链主网上发起交易选取节点成员以创建区块链子网的方式,还可以通过其他手段创建区块链子网,并使得其受到区块链主网的管理。例如,可以通过注册方式在区块链主网上组建区块链子网(后续简称注册组网方式),将现有区块链网络直接注册至区块链主网,使新注册的区块链网络受到区块链主网的管理,从而使得新注册的区块链网络成为区块链主网的区块链子网。通过注册组网方式,待组建区块链子网的子网信息被直接注册至区块链主网,使得区块链主网获取待组建区块链子网的相关信息(通过接收并执行待组建区块链网络发出的、用于将其身份信息与分配至该待组建区块链网络的子网标识进行关联存证的交易),例如待组建区块链子网的子网标识和运行状态,其中各节点成员的公钥和插件配置信息、各节点设备的IP地址和端口信息等,这些信息会被写入区块链主网对应的系统合约的合约状态中,由此区块链主网将获取该待组建区块链子网的管理权,在完成注册后,便意味着区块链子网组建完成。由于注册组网方式并不需要通过交易在区块链主网上指定节点成员构成区块链子网,因此通过注册组网方式组建的区块链子网中的子网节点可以与部署在区块链主网中各节点的节点设备完全不同或部分不同,例如图1中subnet0以注册组网方式创建了一个subnet4,假设subnet0自身所包含的主网节点nodeA~nodeE分别部署于节点设备1~5,那么subnet4对应的子网节点可以部署于除节点设备1~5外的其他任意节点设备上,或者,subnet4中的其中一个或多个子网节点分别部署于节点设备1~5内的任意节点设备(但仍需要保证一个节点设备上仅部署subnet4中的一个子网节点),而subnet4中的其他的子网节点部署于除节点设备1~5外的其他任意节点设备上,当然,subnet4中的子网节点也可以均部署于节点设备1~5之中。
如前所述,无论通过何种方式,在区块链主网上创建的不同区块链子网之间均彼此独立、相互隔离,例如在subnet1上共识的交易就仅会最终被nodeA1~nodeD1所接收,而不会被subnet2中的nodeA2、nodeB2、nodeC2和nodeE2所接收,因此,不同区块链子网在逻辑上就属于不同的区块链网络,这使得区块链子网之间具有信息交互的需求,而对于某一区块链子网而言,其在与其他区块链子网进行信息交互之前,需要获取其他 区块链子网的子网信息以确保信息交互的正确性,特别是需要获取有关整个区块链主网中目前所包含的区块链子网的存在性信息,即包含区块链主网和区块链子网在内的整个区块链系统的网络架构信息,从而防止与已经退出区块链系统的区块链子网进行信息交互而导致网络故障。为了使区块链子网获取区块链系统的网络架构信息,通常需要区块链子网向管理各区块链子网的区块链主网进行请求以获取网络架构信息,而区块链主网和区块链子网同样属于逻辑独立的区块链网络,因此如果需要进行信息交互也需要通过跨链技术来完成,如基于侧链技术、见证人机制或中继技术等传统的跨链技术,然而这些跨链技术通常在具体实现的过程中流程繁琐且耗时较长,并且,传统的跨链技术并没有考虑到区块链子网与区块链主网的跨链场景与传统跨链场景的差异,这使得区块链子网与区块链主网之间需要通过传统的跨链技术才能够实现区块链数据的可信验证。
为此,本说明书提出了一种维护和验证区块链系统的网络架构信息的方法,其中,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网,通过将网络架构信息形成的Merkle树锚定在区块链主网所维护的区块上,从而使任意验证方在需要验证区块链系统中的网络架构信息时,只需要通过获取区块链主网所维护的区块或从区块中的提取出的验证辅助信息就能够实现,而无需进行复杂的跨链交互、智能合约的调用等过程,实现了一种基于区块信息来维护并快速验证区块链子网存在性的方法。
图2是一示例性实施例提供的一种维护区块链系统的网络架构信息的方法的流程图。其中,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法应用于所述区块链主网中的主网节点,所述方法包括:步骤202:接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识。
本说明书实施例所涉及的区块链系统,是指由区块链主网和所述区块链主网管理的区块链子网所共同构成的区块链系统,例如图1所示的由subnet0、subnet1和subnet2所构成的区块链系统,其中,subnet0为区块链主网而subnet1和subnet2为区块链子网,subnet0的主网节点包括nodeA、nodeB、nodeC、nodeD和nodeE,subnet1中的子网节点包括nodeA1、nodeB1、nodeC1和nodeD1,subnet2中的子网节点包括nodeA2、nodeB2、nodeC2和nodeE2。subnet0能够对subnet1和subnet2进行管理,这体现在:可以通过在subnet0上发起子网管理交易,从而使得各个主网节点执行该子网管理交易并生成相应的子网管理事件,而区块链系统中各区块链子网中的子网节点通过获取主网节点所生成的子网管理事件(具体而言,对于所处节点设备上均部署有主网节点的子网节点,可以直接通过监听获取同设备上部署的主网节点所生成的子网管理事件;而对于子网节点所处节点设备未部署有主网节点的子网节点,则需要通过向部署有主网节点的中继节点获取相应的子网管理事件),实现区块链主网向区块链子网的信息传递,并使区块链子网基于子网管理事件实现相应的管理操作。例如,主网节点nodeA在执行完子网管理交易并生成对应的子网管理事件后,与nodeA同处于节点设备1的子网节点nodeA1与nodeA2就能够获取该子网管理事件,从而实现相应的管理操作。
本说明书实施例所涉及的网络架构信息用于描述所述区块链系统所含的区块链子网,具体而言,网络架构信息可以以网络列表的形式以展示区块链系统中所包含的区块链子网的子网标识,并被维护在区块链主网中的各个主网节点上(例如被维护在智能合约中或区块链平台代码中),例如对于如图1所示的subnet0而言,其包含的各个主网节点nodeA~nodeE就分别维护有区块链系统的网络架构信息{subnet1,subnet2},以用于描述目前区块链主网subnet0所含的区块链子网包括subnet1和subnet2,当然,网络架构信息还可用于描述所述区块链系统中所含的区块链主网,即在以网络列表的形式下,该网络架构信息也可表示为{subnet0,subnet1,subnet2};进一步的,网络架构信息还可用于描述所述区块链主网所含的主网节点以及所述区块链子网所含的子网节点,例如可表示为{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}。
如前所述,在本说明书实施例中,区块链主网中的各主网节点在对接收到子网管理交易完成共识的情况下,将执行该子网管理交易并在该子网管理交易对应的收据中写入触发生成的子网管理事件,子网管理事件中记录有对应于子网管理交易的管理操作所带来的变化信息,例如对于子网注册交易而言,其触发生成的子网注册事件中记录有新生成的区块链子网对应的网络标识和节点成员的身份信息(例如节点公钥),由于子网管理事件中记录有因管理操作而导致区块链子网的状态发生变化的变化信息或者变化后的子网信息,因此可通过子网管理事件中携带的信息来获知区块链子网的最新子网信息。
针对区块链子网的管理操作需要通过在区块链主网上发起相应的子网管理交易来实现,例如前述的用于组建区块链子网的交易就属于一种子网管理交易,管理员可通过在区块链主网上发起组建区块链子网的交易,使区块链主网中的各主网节点执行该交易后生成组网事件,而部署有主网节点的各节点设备通过监听该组网事件并根据该组网事件携带的配置信息决定是否要启动新的区块链节点,以使满足相应要求的节点设备启动新的区块链子网节点,从而形成新的区块链子网。由此可见,在通过区块链主网上发起子网管理交易的方式实现对区块链子网的管理的方案的场景下,由于区块链主网与区块链子网之间交易共识的独立性,子网管理交易仅会被发送至区块链主网上的各主网节点,而真正需要进行管理操作的却是区块链子网或节点设备,因此,发起子网管理交易所起到的作用相当于向各个部署有主网节点的节点设备传达管理消息,而最终一个管理操作的完整执行则依赖于事件监听机制以及部署有主网节点的各节点设备的共同参与,即主网节点所处的节点设备、该节点设备上部署的其他子网节点、或者所处节点设备上未部署主网节点的子网节点通过监听并响应子网管理事件来执行相应的管理操作,以实现对区块链子网的管理。在本说明书实施例中,在各主网节点上生成对外开放的子网管理事件,是实现通过在区块链主网发起交易从而管理区块链子网的主要技术构思,是将链上的管理交易转换为链下的管理指令的重要手段,部署有主网节点的任一节点设备和/或任一节点设备上部署的子网节点执行监听到的子网管理事件对应的管理操作。
在主网节点接收到用于变更所述网络架构信息的交易后,将按照所述交易对自身所维护的网络架构信息进行更新。本说明书实施例所涉及的用于变更所述网络架构信息的交易,即属于一种子网管理交易,可以包括以下至少一项:用于创建新的区块链子网的子网注册交易、用于删除已有的区块链子网的子网退出交易、用于变更已有的区块链子网的运行状态的子网启停交易、用于调整已有的区块链子网的节点成员的子网节点调整交易、用于调整所述区块链主网的节点成员的主网节点调整交易。主网节点可以通过所接收到的交易的交易类型字段去识别该交易的交易类型,当主网节点接收到上述用于变更所述网络架构信息的交易后,将从该交易中获取必要的网络架构变更指示信息,以更新自身所维护的网络架构信息。
其中,子网注册交易包括前述的组建区块链子网的交易,以及注册组网方式所涉及的用于将现有区块链网络的身份信息与分配至该现有区块链网络的子网标识进行关联存证的交易。主网节点在接收到子网注册交易后,将基于子网注册交易中所包含的子网标识或子网节点的身份信息更新自身维护的网络架构信息,例如,假设向图1中subnet0发起一笔用于创建subnet3的子网注册交易,并指示对应的节点成员为nodeA3和nodeB3,那么各主网节点在接收到该子网注册交易后,在网络架构信息仅用于描述区块链系统所含的区块链子网的情况下,便会将自身维护的网络架构信息由{subnet1,subnet2}更新为{subnet1,subnet2,subnet3};在网络架构信息还用于描述区块链主网和区块链子网所含的节点情况下,各主网节点会将维护的网络架构信息由{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}变更为{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2},{subnet3:nodeA3,nodeB3}}。用于将已有区块链子网的运行状态变更为开启状态的子网启停交易其效果与子网注册交易类似,这里不再赘述。
同理,假设向图1中subnet0发起一笔用于退出subnet2的子网删除交易,那么各主网节点在接收到该子网删除交易后,在网络架构信息仅用于描述区块链系统所含的区块 链子网的情况下,会将自身维护的网络架构信息由{subnet1,subnet2}更新为{subnet1}。用于将已有区块链子网的运行状态变更为关闭状态的子网启停交易其效果与子网删除交易类似,这里不再赘述。
子网节点调整交易用于在指定区块链子网中新增节点成员和/或删除原有节点成员,例如,假设向图1中subnet0发起一笔用于调整subnet1的节点成员的子网节点调整交易,并指示删除nodeA1,那么各主网节点在接收到该子网注册交易后,在网络架构信息还用于描述区块链主网和区块链子网所含的节点情况下,会将维护的网络架构信息由{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}变更为{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}。
主网节点调整交易用于在区块链主网中新增节点成员和/或删除原有节点成员,例如,假设向图1中subnet0发起一笔主网节点调整交易,并指示新增nodeF,那么各主网节点在接收到该子网注册交易后,在网络架构信息还用于描述区块链主网和区块链子网所含的节点情况下,会将维护的网络架构信息由{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}变更为{{subnet0:nodeA,nodeB,nodeC,nodeD,nodeE,nodeF},{subnet1:nodeA1,nodeB1,nodeC1,nodeD1},{subnet2:nodeA2,nodeB2,nodeC2,nodeE2}}。
同时,上述用于变更所述网络架构信息的交易作一种子网管理交易,在被发起至区块链主网并由各主网节点予以执行后,将生成所述交易对应的网络架构变更事件,如前所述,网络架构变更事件属于一种子网管理事件,所述网络架构变更事件用于指示所述主网节点所处的节点设备基于执行相应的节点启停操作,以使所述区块链系统的网络架构匹配于变更后的所述网络架构信息,所述网络架构包括所述区块链系统中区块链主网和区块链子网的存在状态和/或运行状态。例如,假设向图1中subnet0发起一笔用于退出subnet2的子网删除交易,那么各主网节点在对该子网注册交易完成共识并执行后,将生成网络架构变更事件,由于subnet2中的任一子网节点所处的节点设备上均部署有主网节点,于是节点设备1、节点设备2、节点设备3和节点设备5在分别监听到各自所处节点设备上部署的主网节点所生成的网络架构变更事件后,将基于网络架构变更事件中所携带的用于描述删除subnet2的指示信息,删除各自部署的nodeA2、nodeB2、nodeC2、nodeE2,从而删除subnet2,使得区块链系统的网络架构在执行该子网删除交易后的匹配于通过该交易变更后的网络架构信息。其他的用于变更所述网络架构信息的交易的执行过程基本同理,其执行结果均会导致所述区块链系统的网络架构能够匹配于变更后的所述网络架构信息,这里不再进行赘述。
作为本领域的公知常识,Merkle树(Merkle tree,默克尔树)是一种哈希二叉树,1979年由Ralph Merkle发明,将数据存储在树状结构的叶子结点中,并通过对数据的逐级哈希(Hash)操作确保数据的不可篡改性。叶子结点数据的任何变动,都会传递到上一级节点并最终反应到树根的变化。
本说明书实施例所涉及的网络架构Merkle树,是由主网节点基于自身维护的网络架构信息所生成,其叶子结点为所述区块链系统中区块链子网对应的子网标识。由于Merkle树存在如下性质:只需要知晓顺序排列的叶子结点就能够构建出完整的Merkle树的。因此,只需要确定网络架构Merkle树的叶子结点,就能够生成该网络架构Merkle树,而在本说明书实施例中,网络架构信息中直接或间接记录的区块链子网的子网标识,主网节点可以从自身维护的网络架构信息中确定叶子结点以生成网络架构Merkle树。具体而言,是将区块链系统中各区块链子网的子网标识(或子网标识对应的哈希值)作为待生成Merkle树的叶子结点以进行逐级的哈希合并从而生成Merkle树,而在存在多个叶子结点的情况下,Merkle树作为一种有序树,还需要将叶子结点按照预设顺序进行排列后,再进行逐级的哈希合并以生成Merkle树,其中,一个叶子结点对应于一个区块链子网的子网标识,所述预设顺序为各叶子结点对应区块链子网的创建先后顺序。以 图3为例,图3是一示例性实施例提供的一种网络架构Merkle树的结构示意图,在该实施例中,区块链系统共包含4个区块链子网,那么由其所构建生成的网络架构Merkle树就包含有4个叶子结点,其中,这4个叶子结点一一对应于该区块链系统所包含的4个区块链子网的子网标识,并且从左至右按照对应区块链子网的先后创建顺序进行排列,如图3所示,4个叶子结点首先两两配对以进行一次哈希合并获得2个中间结点,然后这2个中间结点(也称分支结点)再通过一次哈希合并最终得到根结点也即Merkle树根,从而生成一个完整的网络架构Merkle树。
步骤204:在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
在本说明书实施例中,新区块的生成依赖于对预设数量的交易进行打包,在相关技术中,区块链节点在生成新区块时,需要将从交易池中选中的预定数量的交易写入新区块的区块体,同时,将根据这些交易所构建的交易Merkle树对应的树根(称为交易根)、根据这些交易对应的收据所构建的收据Merkle树的树根(称为收据根)以及世界状态所构建的状态Merkle树的树根(成为状态根)写入新区块的区块头,以及在区块头中写入本区块的哈希值、上一个区块的哈希值以及共识算法的哈希值等信息,从而最终生成一个区块以拼接在原区块链上。
在本说明书实施例中,在主网节点需要生成对所述交易(即前述的用于变更网络架构信息的交易)进行打包所得到的新区块时,除了上述现有技术中对新区块的生成过程,还额外包括以下过程:将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。在这样的区块生成方式的基础上,由区块链主网所维护的区块链中的任一区块均会蕴含对应的网络架构Merkle树,而网络架构Merkle树中蕴含有区块链系统的网络架构信息,因此通过上述区块生成方式所生成的区块,能够协助验证方对网络架构信息进行验证。
在一实施例中,主网节点除了会维护一个动态变化的网络架构信息,还会维护一个动态变化的网络架构Merkle树(包括网络架构Merkle树的叶子结点、分支结点和根结点),使得主网节点在每次接收到用于变更网络架构信息的交易以对自身维护的网络架构信息进行变更的情况下,也实时地更新自身所维护的网络架构Merkle树,因此,在生成新区块时,主网节点无需再进行网络架构信息到网络架构Merkle树的转化,而是可以直接将自身所维护的Merkel树的树根和叶子结点分别加入新区块的区块头和区块体,从而实现快速生成新区块、将网络架构Merkle树快速上链的效果。在另一实施例中,主网节点仅维护有动态变化的网络架构信息,而不会动态维护一个网络架构Merkle树,在需要生成新区块时,才会临时基于网络架构信息生成网络架构Merkle树,从而减少实时维护网络架构Merkle树的计算成本。
通过本说明书实施例,通过在接收到用于变更网络架构信息的交易的情况下对网络架构信息进行及时变更,并将基于网络架构信息生成的Merkle树锚定在区块链主网所维护的区块上,从而使任意验证方在需要验证区块链系统中的网络架构信息时,只需要通过获取区块链主网所维护的区块或从区块中的提取出的验证辅助信息就能够实现,而无需进行复杂的跨链交互、智能合约的调用等过程,实现了一种基于区块信息来维护并快速验证区块链子网存在性的方法。
可选的,所述将所述网络架构Merkle树的树根锚定在所述新区块的区块头,包括:将所述网络架构Merkle树的树根写入所述新区块的区块头;或者,以所述网络架构Merkle树的树根作为所述新区块对应状态树的一个叶子结点,并将计算得到的状态根写入所述新区块的区块头。在本说明书实施例中,在将网络架构Merkle树的树根锚定在新区块的区块头上时,可以采用两种方式,一种方式就是直接将网络架构Merkle树的树根作为一个单独的字段存储在区块头中,使得网络架构Merkle树的树根的地位与区块头中的交易根、状态根和收据根相同,采用此种方式可以方便验证方对网络架构信息进行验证时进行更少的验证计算(只需从网络架构Merkle树的叶子结点计算至网络架构Merkle树的树根);另一种方式,是将网络架构Merkle树的树根作为新区块对应的 状态树的一个叶子结点,并以此计算出一个锚定有网络架构Merkle树的树根的状态根,采用此种方式虽然使得验证方需要验证网络架构信息时进行更多的验证计算过程(从网络架构Merkle树的叶子结点计算至网络架构Merkle树的树根,再到状态树的状态根),但此举相当于将孤立作用的Merkle树与区块中其他改变世界状态的交易进行深度绑定,并将这些交易作为网络架构Merkle树的信任凭证,以提高验证方对该区块所对应的网络架构Merkle树的可信度。
可选的,所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。在本说明书实施例中,网络架构信息中还包含各区块链子网所含的节点成员,并且,作为网络架构Merkle树的叶子结点的子网标识用于表征所述任一区块链子网所包含的子网节点,也即,网络架构Merkle树的叶子结点不仅能够表征区块链系统中所含的区块链子网,还能够表征对应区块链子网中对应的节点成员。任一区块链子网对应的子网标识可以包括所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根,其中,节点成员信息集合可以为对应区块链子网的节点成员列表,例如图1中subnet0中的主网节点所生成的网络架构Merkle树的叶子结点就可以分别设置为subnet1的节点成员列表{nodeA1,nodeB1,nodeC1,nodeD1}和subnet2的节点成员列表{nodeA2,nodeB2,nodeC2,nodeE2},或者对应节点成员列表的哈希值。因此,主网节点可以基于自身维护的网络架构信息来确定网络架构Merkle树的叶子结点的取值,从而进一步生成蕴含有网络架构信息的Merkle树。显然,通过本说明书实施例网络架构Merkle树所蕴含的网络架构信息更加地丰富,从而能够协助验证方对包括子网节点成员在内的更多网络架构信息进行验证。
可选的,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;所述节点成员信息集合包括一字符串,所述字符串的字符位一一对应于所述区块链主网中的主网节点,且字符位的取值用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。在本说明书实施例中,要求所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点,在这种场景下,主网节点可以将网络架构信息中任一区块链子网的节点成员信息转化为字符串形式以用于表征所述任一区块链子网所包含的子网节点,该字符串满足以下形式要求:①字符串的位数为区块链主网中主网节点的数量相同;②字符串中字符位一一对应于所述区块链主网中的主网节点,且字符位的取值(例如取值为“0”表征未部署,取值为“1”表征已部署)用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点;③字符串中各字符位按照预设顺序进行排列,所述预设顺序包括各字符位对应主网节点的节点序号的顺序或对应主网节点所处节点设备的设备序号的顺序。例如图1中subnet0中的主网节点,其所生成的网络架构Merkle树就包括2个叶子结点,从左至右分别为subnet1对应的节点成员信息集合以及subnet2的节点成员信息集合,其中,subnet1对应的节点成员信息对应的字符串为“11110”,用于表征subnet1中的子网节点分别部署在节点设备1、节点设备2、节点设备3和节点设备4上,subent2对应的节点成员信息对应的字符串为“11101”用于表征subnet2中的子网节点分别部署在节点设备1、节点设备2、节点设备3和节点设备5上。在本说明书实施例中,将蕴含有区块链子网的节点成员信息的字符串作为网络架构Merkle树的叶子结点,使得网络架构Merkel树的树根锚定有各区块链子网的成员信息,从而可以向验证方提供任一区块链子网节点成员的存在性证明。
可选的,所述子网Merkel树中的叶子结点一一对应于所述任一区块链子网所包含的子网节点。在本说明书实施例中,用于作为网络架构Merkle树的叶子结点的子网标识具体为区块链子网的子网Merkel树的树根,因此,网络架构Merkle树的树根实际上锚定了各区块链子网对应的子树Merkle树,从而蕴含有包含各子网节点成员在内的所有网络架构信息。在本说明书实施例中,并不要求所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点,任一区块链子网所对应的子树 Merkle树的叶子结点仅由所述任一区块链子网的子网节点所确定,具体而言,子树Merkle树的叶子结点一一对应于所述任一区块链子网所包含的子网节点,且各叶子结点需要按照预设顺序进行排列以构成子网Merkle树,所述预设顺序可以包括各叶子结点对应子网节点的节点序号的顺序或所处节点设备的设备序号的顺序,而任一叶子结点的取值可以为对应子网节点的身份信息,例如节点公钥或节点标识,或者任意与该子网节点所关联的相关信息,本说明书对此并不做任何限制。如图4所示,图4是一示例性实施例提供的一种子网Merkle树的结构示意图,假设图中所示子网Merkle树对应的区块链子网共包含4个子网节点,分别为node1、node3、node5和node7,因而该子网Merkle树对应的4个叶子结点分别对应于node1、node3、node5和node7并且按照图示顺序进行排列,其具体的取值从左至右可以分别为node1、node3、node5和node7对应的节点公钥(或节点公钥的哈希值),在该实施例中,4个叶子结点通过两次哈希合并以最终得到根结点也即子网Merkle树的树根,从而生成一个完整的子网Merkle树,需要指出的是,子网Merkle树的生成也是由主网节点基于自身维护的网络架构信息所生成的,其生成方式与生成网络架构Merkle树类似,通过将子树Merkle树的树根作为网络架构Merkle树的叶子结点,从而串联起两颗树,使得网络架构Merkle树的树根能够最终锚定区块链系统中所含的区块链子网、以及各区块链子网所含的节点成员。
可选的,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;所述子网Merkel树中的叶子结点一一对应于所述区块链主网中的主网节点,且所述子网Merkel树中的叶子结点用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。在本说明书实施例中,要求所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点,在这种场景下,任一区块链子网所对应的子树Merkle树的叶子结点由所述任一区块链子网的子网节点以及所述区块链主网中的主网节点所共同确定,具体而言,子树Merkle树的叶子结点一一对应于所述区块链主网所包含的主网节点,且各叶子结点需要按照预设顺序进行排列以构成子网Merkle树,所述预设顺序可包括各叶子结点对应主网节点的节点序号的顺序或所处节点设备的设备序号的顺序,而任一叶子结点的取值可为对应主网节点所处节点设备中子网节点的身份信息,或者用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点的标记信息,本说明书对此并不做任何限制。
如图5所示,图5是一示例性实施例提供的另一种子网Merkle树的结构示意图,假设图中所示子网Merkel树对应的区块链子网共包含4个子网节点,其所在的节点设备的设备序号分别为node1、node3、node5和node7,而区块链主网共包括8个主网节点,其所在的节点设备的设备序号分别为node1、node2、node3、node4、node5、node6、node7和node8,那么该子网Merkle树对应的8个叶子结点分别对应于node1~node8并且按照图示顺序进行排列,其具体的取值从左至右可分别为“existent”、“non-existent”、“existent”、“non-existent”、“existent”、“non-existent”、“existent”和“non-existent”,其中,“existent”用于表征对应节点设备中部署有该任一区块链子网中的子网节点,而“non-existent”用于表征对应节点设备中未部署有该任一区块链子网中的子网节点。在该实施例中,8个叶子结点通过三次哈希合并以最终得到根结点也即子网Merkle树的树根,从而生成一个完整的子网Merkle树,需要指出的是,该子网Merkle树的生成也是由主网节点基于自身维护的网络架构信息所生成的,通过将子树Merkle树的树根作为网络架构Merkle树的叶子结点,从而串联起两颗树,使得网络架构Merkle树的树根能够最终锚定区块链系统中所含的区块链子网、以及各区块链子网所含的节点成员。
可选的,所述方法还包括:在所述网络架构Merkle树的叶子结点为子网Merkel树的树根的情况下,将所述子网Merkel树的叶子结点写入所述新区块的区块体。通过本说明书实施例,可以使主网节点在所述网络架构Merkle树的叶子结点为子网Merkel树的树根的情况下,能基于区块体中记录的子网Merkle树的叶子结点还原出子网Merkle树,由于子网Merkel树蕴含有对应区块链子网的节点成员信息,这使得主网节点后续能够提供关于区块链子网中内部子网节点的存在性证明,从而向验证方提供更多种类型 的网络架构信息验证服务。
可选的,还包括:将所述网络架构Merkle树的分支结点写入所述新区块的区块体。如前所述,主网节点在生成对应于所述交易的新区块时,会将所述网络架构Merkle树的叶子结点写入所述新区块的区块体,而在本说明书实施例中,主网节点不仅会向区块体中写入网络架构Merkle树的叶子结点,也会写入网络架构Merkle树的分支节点,由此可以使主网节点后续需要还原出该区块对应的网络架构Merkle树时,无需从叶子结点开始进行逐级哈希合并以生成网络架构Merkle树,而是可以基于区块体中所记录的叶子结点和分支结点直接还原出网络架构Merkle树,尤其是后续主网节点需要向验证方提供用于验证网络架构信息的验证辅助信息时,可以大大减轻主网节点的计算负担,加快验证效率。类似的,在所述网络架构Merkle树的叶子结点为子网Merkel树的树根的情况下,将所述子网Merkel树的分支结点写入所述新区块的区块体,从而方便主网节点后续更加迅速地还原出子网Merkle树。
可选的,还包括:接收到针对所述网络架构信息中的目标信息所发起的SPV验证请求;从所述网络架构Merkle树中确定相应的验证辅助信息,并返回至所述SPV验证请求的发起方。在本说明书实施例中,SPV(Simplified Payment Verification,简单支付验证)指的是一种由轻节点(即仅维护有区块链中区块头的区块链节点,也称SPV节点)向全量节点(维护有包含区块头和区块体的完整区块链的区块链节点)请求验证链上数据存在性的技术,其实现过程主要是利用了Merkle树的性质,由于只有唯一一组按预定顺序排列的叶子结点才能生成得到一个唯一对应的树根,因此,可以利用请求重算Merkle树根并将其与参考树根进行比较的方式,来判断叶子结点的存在性和未被篡改性。在本说明书实施例中,生成新区块的主网节点作为一个全量节点,其维护有区块链主网对应的完整区块链,而在主网节点接收到针对所述网络架构信息中的目标信息所发起的SPV验证请求时,则会首先确定SPV验证请求所需验证的目标区块的区块高度,然后查找到对应区块高度的目标区块,并基于目标区块的区块体中记录的网络架构Merkle树的叶子结点还原出网络架构Merkle树,然后进一步查找目标信息在网络架构Merkle树中所处的路径,在所述目标信息包括待验证区块链子网在所述网络架构Merkle树中对应的叶子结点的取值的情况下,会根据该叶子结点的路径去选取用于快速重算出网络架构Merkle的树根的叶子结点和/或分支结点以作为验证辅助信息,并将其返回至所述SPV验证请求的发起方,那么发起方就可以通过验证辅助信息以及目标信息来重算出网络架构Merkle树的树根,并将其与自身维护的目标区块的区块头中的网络架构Merkle树的树根(即参考树根)进行比较,在比较一致的情况下,则可以认为待验证区块链子网存在于目前的区块链系统中。
可选的,所述SPV验证请求的发起方包括:所述区块链主网中的SPV主网节点;或者,所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。在本说明书实施例中,所述SPV验证请求的发起方通常需要维护有区块链主网对应区块链的区块头,例如,该发起方可以为区块链主网中的SPV主网节点,这种节点只会维护由区块头所构成的区块链,而不会保持完整的包含区块头和区块体的区块链,或者,该发起方也可以为所述SPV主网节点所处节点设备上部署的子网节点,由于该子网节点与SPV主网节点同属于一个节点设备,因此,虽然子网节点不会直接参与维护区块链主网的区块头,但也可以借助节点设备上的共享插件来与同一节点设备上的SPV主网节点共享部分信息,从而间接维护有区块链主网的区块头。以图1中subnet1中的nodeA1希望验证subnet2是否存在为例,由于nodeA与nodeA1部署于同一节点设备1,因此nodeA1可以通过节点设备1上部署的共享插件来获取nodeA所维护的区块链主网的区块头,因此,nodeA1可以向subnet0中的全量节点例如nodeB发起针对subnet2的SPV验证请求,nodeB在接收到SPV验证请求后,将还原出网络架构Merkle树并将确定得到的验证辅助信息返回至nodeA1,那么nodeA1在接收到验证辅助信息后就能够独自完成重算Merkle树根以及树根比较的过程,从而完成验证subnet2的存在性。
图6是一示例性实施例提供的一种验证区块链系统的网络架构信息的方法的流程图。 其中,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法包括如下步骤。
步骤602:向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识。
步骤604:接收所述全量主网节点从所述网络架构Merkle树中确定并返回的验证辅助信息。全量主网节点会根据该目标信息在网络架构Merkle树中的路径去选取用于快速重算出网络架构Merkle的树根的叶子结点和/或分支结点以作为验证辅助信息。
步骤606:基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。该步骤主要是利用目标信息与验证辅助信息重算网络架构Merkle树的树根,然后将计算得到的待验证树根与SPV主网节点所维护的主网区块的区块头上记录的网络架构Merkle树的树根(即参考树根)进行比对,在比对一致的情况下能够证明目标信息的存在性。
在本说明书实施例中,SPV验证请求中携带有所需请求的主网区块的区块高度,因此,全量主网节点可以基于该区块高度确定自身所维护的相应主网区块,并从它的区块体中获取网络架构Merkle树的叶子结点以生成网络架构Merkle树,因此SPV验证的发起方所获取的验证辅助信息是基于对应区块高度的主网区块所确定的,那么后续在利用验证辅助信息进行验证时,同样也需要从SPV主网节点获取该区块高度对应的主网区块的区块头,从而使得全量主网节点所提供的验证辅助信息与SPV主网节点所提供的参考树根出自于同一区块高度的主网区块,以确保SPV验证的正确性。
在一说明书实施例中,虽然SPV验证请求中携带有所需请求的主网区块的区块高度,但全量主网节点不会基于该区块高度对应区块的区块体以生成网络架构Merkle树,而是会按照自身维护的动态变化的网络架构信息生成网络架构Merkle树。由于区块上锚定的网络架构Merkle树的存在一定的滞后性(因为存在用于变更网络架构信息的交易已经被执行但还暂未被打包形成区块的现象),因此,主网全量节点所生成的网络架构Merkle树具有实时性,能够克服因上述滞后性所带来的SPV验证出错。
在本说明书实施例中,所述SPV验证请求的发起方除了可以向全量主网节点发起SPV验证请求,也可以向任何维护有区块链主网对应的完整区块链的网络节点发起SPV验证请求,因为本说明书所涉及的主网区块的区块体中包含有用于还原出网络架构Merkle树的叶子结点,因此只需要维护有区块链主网对应的主网区块的区块体,就能够向SPV验证请求的发起方提供有关区块链系统的网络架构信息的存在性证明。
如前所述,所述SPV验证请求的发起方包括:所述SPV主网节点,或者,所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。
如前所述,所述目标信息包括待验证区块链子网在所述网络架构Merkle树中对应的叶子结点的取值。
所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。在本说明书实施例中,所述目标信息可以包括:待验证区块链子网对应的待验证节点成员信息集合;或者,待验证区块链子网所含的待验证子网节点在所述子网Merkle树中对应的叶子结点的取值。在本说明书实施例中,全量主网节点不仅能够提供有关子网存在性的证明,还能够提供子网中节点成员的存在性证明。例如,在任一区块链子网对应的子网标识为所述任一区块链子网对应的子网Merkel树的树根的情况下,SPV验证请求的发起方可以向全量主网节点请求验证特定区块链子网中的特定子网节点的存在性,这种情况下,全量主网节点还需要维护有各个区块链子网对应的子网Merkle树,以将从特定区块链子网对应的子网Merkle树中所确定 的验证辅助信息以及从网络架构Merkle树中所确定的验证辅助信息一同返回所述发起方,以使所述发起方可以根据这些验证辅助信息重算出网络架构Merkle树的树根。
以下将通过一个具体的实施例来说明本说明书所提供的验证区块链系统的网络架构信息的方法。
假设本说明书实施例所涉及的区块链系统中包含共4个区块链子网,并且该区块链系统对应的网络架构Merkle树的结构如图3所示,其中,最左端的叶子结点对应的第一区块链子网对应的子网Merkle树的结构如图4所示,显然,第一区块链子网的节点成员包括node1、node3、node5和node7。
在上述区块链系统的网络架构下,假设验证方希望验证第一区块链子网中是否部署有node1,则可以向区块链主网中的全量主网节点发起针对第一区块链子网中node1是否存在的SPV验证请求,此时SPV验证请求中将包含第一区块链子网的子网标识以及node1的节点公钥。
全量主网节点在接收到SPV验证请求后,首先基于区块体中记录的网络架构Merkle树的叶子结点生成网络架构Merkle树,然后基于SPV验证请求中携带的第一区块链子网的子网标识确定验证方所需验证的子网为第一区块链子网,并在生成的网络架构Merkle树中确定待验证区块链子网对应的叶子结点的路径(该路径用于表征该叶子结点为网络架构Merkle树中最左端的叶子结点),从而在网络架构Merkle树中确定出该叶子结点对应的验证辅助信息为图3中所示的叶子结点A与分支结点B。
同时,由于SPV验证请求中还携带有node1的节点公钥,因此全量主网节点还需要进一步提供用于验证第一区块链子网中是否包含node1的验证辅助信息,具体而言,全量主网节点会基于区块体中记录的第一区块链子网对应的子网Merkle树的叶子结点生成第一区块链子网对应的子网Merkle树,然后根据node1的节点公钥确定待验证节点对应的叶子结点的路径(该路径用于表征该叶子结点为第一区块链子网的子网Merkle树中最左端的叶子结点),从而在子网Merkle树中确定出该叶子结点对应的验证辅助信息为图4中所示的叶子结点a与分支节点b。
由此,全量主网节点基于上述的SPV验证请求所确定的叶子结点A、分支结点B、叶子结点a与分支结点b对应的取值作为SPV验证请求对应的验证辅助信息返回至验证方。
验证方在接收到上述SPV验证请求对应的验证辅助信息后,将根据node1的节点公钥以及验证辅助信息进行重算网络架构Merkle树的树根的过程,具体而言,是将node1的节点公钥与叶子结点a进行哈希合并后得到的中间结点记为中间结点c,其值为c=hash(key1+a),其中“hash()”代表哈希运算,“key1”代表node1的公钥,“a”代表叶子结点a的取值,“+”代表对“被加数”的顺序敏感的合并算法;类似的,再将中间结点c与分支结点b进行哈希合并以得到子树Merkle树的待验证树根记为子树根结点,其值为m=hash(c+b),其中“b”为分支结点b的取值;在得到子树根结点后,再按照同样的方式以重算出网络架构Merkle树中的中间结点C,其值为C=hash(m+A);最终以确定出重算的网络架构Merkle树的树根的取值为N=hash(C+B)。
验证方在重算出网络架构Merkle树的树根后,将其与自身所维护的区块头中所记录的网络架构Merkle树的树根(参考树根)进行比较,如果二者相同,则能够证明node1的确存在于第一区块链子网中,如果二者不同,则不能证明node1的确存在于第一区块链子网中。
图7是一示例性实施例提供的一种设备的示意结构图。请参考图7,在硬件层面,该设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器710,当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现,比如由处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
如图8所示,图8是本说明书根据一示例性实施例提供的一种维护区块链系统的网 络架构信息的装置的框图,该装置可以应用于如图7所示的设备中,以实现本说明书的技术方案,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置应用于所述区块链主网中的主网节点,所述装置包括:架构变更单元801,用于接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;区块生成单元802,用于在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
可选的,所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。
可选的,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;所述节点成员信息集合包括一字符串,所述字符串的字符位一一对应于所述区块链主网中的主网节点,且字符位的取值用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。
可选的,所述子网Merkel树中的叶子结点一一对应于所述任一区块链子网所包含的子网节点。
可选的,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;所述子网Merkel树中的叶子结点一一对应于所述区块链主网中的主网节点,且所述子网Merkel树中的叶子结点用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。
可选的,所述装置还包括:结点写入单元803,用于在所述网络架构Merkle树的叶子结点为子网Merkel树的树根的情况下,将所述子网Merkel树的叶子结点写入所述新区块的区块体。
可选的,所述区块生成单元802具体用于:将所述网络架构Merkle树的树根写入所述新区块的区块头;或者,以所述网络架构Merkle树的树根作为所述新区块对应状态树的一个叶子结点,并将计算得到的状态根写入所述新区块的区块头。
可选的,还包括:SPV验证单元804,用于接收到针对所述网络架构信息中的目标信息所发起的SPV验证请求;以及,从所述网络架构Merkle树中确定相应的验证辅助信息,并返回至所述SPV验证请求的发起方。
可选的,所述SPV验证请求的发起方包括:所述区块链主网中的SPV主网节点;或者,所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。
可选的,所述交易包括下述至少之一:用于创建新的区块链子网的子网注册交易;用于删除已有区块链子网的子网退出交易;用于调整已有区块链子网的节点成员的子网节点调整交易。
可选的,所述装置还包括:节点启停单元805,用于生成所述交易对应的网络架构变更事件,所述网络架构变更事件用于指示所述主网节点所处的节点设备基于执行相应的节点启停操作,以使所述区块链系统的网络架构匹配于变更后的所述网络架构信息。
如图9所示,图9是本说明书根据一示例性实施例提供的一种验证区块链系统的网络架构信息的装置的框图,该装置可以应用于如图7所示的设备中,以实现本说明书的技术方案,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置包括:请求单元901,用于向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识;接收单元902,用于接收所述全量主网节 点从所述网络架构Merkle树中确定并返回的验证辅助信息;验证单元903,用于基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。
可选的,所述SPV验证请求的发起方包括:所述SPV主网节点,或者,所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。
可选的,所述目标信息包括待验证区块链子网在所述网络架构Merkle树中对应的叶子结点的取值。
可选的,所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。
可选的,所述目标信息包括:待验证区块链子网对应的待验证节点成员信息集合;或者,待验证区块链子网所含的待验证子网节点在所述子网Merkle树中对应的叶子结点的取值。相应的,本说明书还提供一种装置,所述装置包括有处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为实现上述全部方法实施例提供的实现维护或验证区块链系统的网络架构信息的方法的步骤。
相应的,本说明书还提供一种计算机可读存储介质,其上存储有可执行的指令;其中,该指令被处理器执行时,实现上述全部方法实施例提供的实现维护或验证区块链系统的网络架构信息的方法的步骤。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中, 程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (20)

  1. 一种维护区块链系统的网络架构信息的方法,其特征在于,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法应用于所述区块链主网中的主网节点,所述方法包括:
    接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;
    在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
  2. 根据权利要求1所述的方法,其特征在于,所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:
    所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。
  3. 根据权利要求2所述的方法,其特征在于,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;
    所述节点成员信息集合包括一字符串,所述字符串的字符位一一对应于所述区块链主网中的主网节点,且字符位的取值用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。
  4. 根据权利要求2所述的方法,其特征在于,所述子网Merkel树中的叶子结点一一对应于所述任一区块链子网所包含的子网节点。
  5. 根据权利要求2所述的方法,其特征在于,所述任一区块链子网中的子网节点所处的节点设备上部署有所述区块链主网中的主网节点;
    所述子网Merkel树中的叶子结点一一对应于所述区块链主网中的主网节点,且所述子网Merkel树中的叶子结点用于表征相应主网节点所处的节点设备上是否部署有所述任一区块链子网中的子网节点。
  6. 根据权利要求2所述的方法,其特征在于,所述方法还包括:
    在所述网络架构Merkle树的叶子结点为子网Merkel树的树根的情况下,将所述子网Merkel树的叶子结点写入所述新区块的区块体。
  7. 根据权利要求1所述的方法,其特征在于,所述将所述网络架构Merkle树的树根锚定在所述新区块的区块头,包括:
    将所述网络架构Merkle树的树根写入所述新区块的区块头;或者,
    以所述网络架构Merkle树的树根作为所述新区块对应状态树的一个叶子结点,并将计算得到的状态根写入所述新区块的区块头。
  8. 根据权利要求1所述的方法,其特征在于,还包括:
    接收到针对所述网络架构信息中的目标信息所发起的SPV验证请求;
    从所述网络架构Merkle树中确定相应的验证辅助信息,并返回至所述SPV验证请求的发起方。
  9. 根据权利要求8所述的方法,其特征在于,所述SPV验证请求的发起方包括:
    所述区块链主网中的SPV主网节点;或者,
    所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。
  10. 根据权利要求1所述的方法,其特征在于,所述交易包括下述至少之一:
    用于创建新的区块链子网的子网注册交易;
    用于删除已有区块链子网的子网退出交易;
    用于调整已有区块链子网的节点成员的子网节点调整交易。
  11. 根据权利要求1所述的方法,其特征在于,所述方法还包括:
    生成所述交易对应的网络架构变更事件,所述网络架构变更事件用于指示所述主网节点所处的节点设备基于执行相应的节点启停操作,以使所述区块链系统的网络架构匹 配于变更后的所述网络架构信息。
  12. 一种验证区块链系统的网络架构信息的方法,其特征在于,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述方法包括:
    向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识;
    接收所述全量主网节点从所述网络架构Merkle树中确定并返回的验证辅助信息;
    基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。
  13. 根据权利要求12所述的方法,其特征在于,所述SPV验证请求的发起方包括:
    所述SPV主网节点,或者,
    所述SPV主网节点所处节点设备上部署的子网节点,且所述子网节点共享所述SPV主网节点所维护的区块头。
  14. 根据权利要求12所述的方法,其特征在于,所述目标信息包括待验证区块链子网在所述网络架构Merkle树中对应的叶子结点的取值。
  15. 根据权利要求12所述的方法,其特征在于,所述网络架构信息还用于描述所述区块链子网所含的节点成员;任一区块链子网对应的子网标识包括:
    所述任一区块链子网对应的节点成员信息集合或子网Merkel树的树根;其中,所述节点成员信息集合与所述子网Merkle树的叶子结点分别用于表征所述任一区块链子网所包含的子网节点。
  16. 根据权利要求15所述的方法,其特征在于,所述目标信息包括:
    待验证区块链子网对应的待验证节点成员信息集合;或者,
    待验证区块链子网所含的待验证子网节点在所述子网Merkle树中对应的叶子结点的取值。
  17. 一种维护区块链系统的网络架构信息的装置,其特征在于,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置应用于所述区块链主网中的主网节点,所述装置包括:
    架构变更单元,用于接收到用于变更所述网络架构信息的交易;其中,在基于所述网络架构信息生成的网络架构Merkle树中,叶子结点为所述区块链系统中区块链子网对应的子网标识;
    区块生成单元,用于在生成对应于所述交易的新区块时,将所述网络架构Merkle树的树根锚定在所述新区块的区块头,以及将所述网络架构Merkle树的叶子结点写入所述新区块的区块体。
  18. 一种验证区块链系统的网络架构信息的装置,其特征在于,所述区块链系统包括区块链主网和所述区块链主网管理的区块链子网,所述网络架构信息用于描述所述区块链系统所含的区块链子网;所述装置包括:
    请求单元,用于向所述区块链主网中的全量主网节点发起针对所述网络架构信息中的目标信息的SPV验证请求,所述全量主网节点维护的主网区块中记录有基于所述网络架构信息生成的网络架构Merkle树,其中,区块头用于锚定所述网络架构Merkle树的树根、区块体记录有所述网络架构Merkle树的叶子结点,且所述网络架构Merkle树的叶子结点为所述区块链系统中区块链子网对应的子网标识;
    接收单元,用于接收所述全量主网节点从所述网络架构Merkle树中确定并返回的验证辅助信息;
    验证单元,用于基于所述验证辅助信息以及SPV主网节点所维护的所述主网区块的区块头,对所述目标信息进行SPV验证。
  19. 一种电子设备,其特征在于,包括:
    处理器;
    用于存储处理器可执行指令的存储器;
    其中,所述处理器通过运行所述可执行指令以实现如权利要求1-16中任一项所述的方法。
  20. 一种计算机可读存储介质,其上存储有计算机指令,其特征在于,该指令被处理器执行时实现如权利要求1-16中任一项所述方法的步骤。
PCT/CN2022/107800 2021-09-30 2022-07-26 维护区块链系统的网络架构信息 WO2023050986A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111167427.7 2021-09-30
CN202111167427.7A CN113609231B (zh) 2021-09-30 2021-09-30 一种维护区块链系统的网络架构信息的方法和装置

Publications (1)

Publication Number Publication Date
WO2023050986A1 true WO2023050986A1 (zh) 2023-04-06

Family

ID=78343322

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/107800 WO2023050986A1 (zh) 2021-09-30 2022-07-26 维护区块链系统的网络架构信息

Country Status (2)

Country Link
CN (1) CN113609231B (zh)
WO (1) WO2023050986A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113609231B (zh) * 2021-09-30 2022-01-04 支付宝(杭州)信息技术有限公司 一种维护区块链系统的网络架构信息的方法和装置
CN115567542B (zh) * 2022-12-01 2023-03-10 杭州蚂蚁酷爱科技有限公司 节点集合的维护方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109379382A (zh) * 2018-12-07 2019-02-22 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备
CN110741372A (zh) * 2017-06-07 2020-01-31 区块链控股有限公司 用于管理区块链网络上的交易的计算机实现的系统和方法
US20200133921A1 (en) * 2018-10-26 2020-04-30 Samsung Sds Co., Ltd. Method and apparatus for sharing information recorded on blockchain based on anchoring
US20200195441A1 (en) * 2018-12-13 2020-06-18 International Business Machines Corporation Compact state database system
CN113259458A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 一种启动/关闭区块链节点服务的方法和装置
CN113259459A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 区块链子网运行状态的控制方法和区块链系统
CN113609231A (zh) * 2021-09-30 2021-11-05 支付宝(杭州)信息技术有限公司 一种维护区块链系统的网络架构信息的方法和装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110741372A (zh) * 2017-06-07 2020-01-31 区块链控股有限公司 用于管理区块链网络上的交易的计算机实现的系统和方法
US20200133921A1 (en) * 2018-10-26 2020-04-30 Samsung Sds Co., Ltd. Method and apparatus for sharing information recorded on blockchain based on anchoring
CN109379382A (zh) * 2018-12-07 2019-02-22 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备
US20200195441A1 (en) * 2018-12-13 2020-06-18 International Business Machines Corporation Compact state database system
CN113259458A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 一种启动/关闭区块链节点服务的方法和装置
CN113259459A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 区块链子网运行状态的控制方法和区块链系统
CN113609231A (zh) * 2021-09-30 2021-11-05 支付宝(杭州)信息技术有限公司 一种维护区块链系统的网络架构信息的方法和装置

Also Published As

Publication number Publication date
CN113609231B (zh) 2022-01-04
CN113609231A (zh) 2021-11-05

Similar Documents

Publication Publication Date Title
CN113259455B (zh) 跨子网交互方法及装置
WO2023050986A1 (zh) 维护区块链系统的网络架构信息
CN113259460B (zh) 跨链交互方法及装置
CN113259456B (zh) 跨链交互方法及装置
CN113067897B (zh) 跨链交互方法及装置
CN113259453B (zh) 跨链交互方法及装置
CN113067895B (zh) 组建区块链子网的方法和区块链系统
WO2023050966A1 (zh) 验证区块链数据
WO2023124746A1 (zh) 跨子网交互的权限控制
CN113259120B (zh) 同步节点信息列表的方法
CN113259117B (zh) 同步节点信息列表的方法
CN113259457B (zh) 区块链子网的信息同步方法及装置
CN113259454B (zh) 跨链交互方法及装置
CN113259118B (zh) 同步节点信息列表的方法
CN113326290B (zh) 跨网查询控制方法
CN113259461B (zh) 跨链交互方法和区块链系统
CN114363162A (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN113259459B (zh) 区块链子网运行状态的控制方法和区块链系统
CN113259466B (zh) 区块链子网运行状态的控制方法和区块链系统
CN113259237B (zh) 区块链网络间的交易转发方法
CN113259463B (zh) 跨链交互方法和区块链系统
CN113067838B (zh) 跨链交互方法及装置
CN116743765A (zh) 区块链系统、跨链交互方法和装置
CN114363349A (zh) 区块链子网的启动方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22874383

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE