CN114866560A

CN114866560A - Migration method and device for block chain nodes

Info

Publication number: CN114866560A
Application number: CN202210474002.9A
Authority: CN
Inventors: 陶友贤
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2022-08-05
Anticipated expiration: 2042-04-29
Also published as: WO2023207077A1; CN114866560B

Abstract

One or more embodiments of the present specification provide a method and apparatus for migrating a blockchain node. The method comprises the following steps: a main network node deployed in first node equipment sends created block information of a block chain sub-network to the first node equipment by executing node migration transaction, so that the first node equipment sends the created block information to second node equipment, and a block chain main network to which the main network node belongs is used for managing the block chain sub-network; the second node equipment generates a creation block according to the creation block information, and starts a second subnet node by loading the creation block; adding a second subnet node into the block chain subnet, and loading the historical data of the first subnet node in the block chain subnet; and under the condition that the second subnet node finishes loading the historical data, the first subnet node exits the block chain subnet.

Description

Migration method and device for block chain nodes

Technical Field

The embodiment of the present specification belongs to the technical field of blockchain, and in particular, relates to a method and an apparatus for migrating blockchain nodes.

Background

The Blockchain (Blockchain) technology is built on a transmission network (such as a point-to-point network), and is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The nodes in the block chain network combine the data blocks into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not falsified and forged is ensured in a cryptographic mode.

Partial block chain link points in the block chain network can participate in building a block chain sub-network so as to meet the requirement of small-range interaction among the partial block chain link points. During the operation of such a blockchain sub-network, some sub-network nodes may have a migration requirement, i.e. a node device where a blockchain node needs to be replaced. Therefore, how to realize the controllable migration of the subnet nodes is an urgent problem to be solved.

Disclosure of Invention

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

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

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

a main network node deployed in first node equipment sends created block information of a block chain sub-network to the first node equipment by executing node migration transaction, so that the first node equipment sends the created block information to second node equipment, and a block chain main network to which the main network node belongs is used for managing the block chain sub-network;

the second node equipment generates a creation block according to the creation block information, and starts a second subnet node by loading the creation block;

adding a second subnet node into the block chain subnet, and loading the historical data of the first subnet node in the block chain subnet;

and under the condition that the second subnet node finishes loading the historical data, the first subnet node exits the block chain subnet.

According to a second aspect of one or more embodiments of the present specification, there is provided a block link point transfer device including:

an information disclosure unit, configured to disclose, by a master network node deployed in a first node device, created block information of a block chain subnet to the first node device by executing a node migration transaction, so that the first node device sends the created block information to a second node device, where a block chain master network to which the master network node belongs is used to manage the block chain subnet;

the node starting unit is used for generating a created block according to the created block information by the second node equipment and starting a second subnet node by loading the created block;

the node adding unit is used for adding the second subnet node into the block chain subnet and loading the historical data of the first subnet node in the block chain subnet;

and the node exit unit is used for exiting the block chain sub-network by the first sub-network node under the condition that the second sub-network node finishes loading the historical data.

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

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of the first aspects by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, there is provided a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to any one of the first aspect.

In the above embodiment, in a scenario where a blockchain master network manages a blockchain subnet, a master network node sends creation block information of the blockchain subnet to a first node device where the master network node is located by executing a node migration transaction, and the first node device sends the information to a second node device. And the second node equipment generates and loads an appearance creating block according to the information to start the second sub-network node, and the sub-network node loads the historical data of the first sub-network node after joining the block chain sub-network. And the first sub-network node exits the blockchain sub-network under the condition that the second sub-network node finishes loading.

Loading historical data of a first subnet node by a newly started second subnet node in the blockchain subnet, and exiting the blockchain subnet by the first subnet node after the loading is finished, wherein the first subnet node and the second subnet node in the blockchain subnet are respectively subnet nodes before and after migration; moreover, the historical data of the first subnet node is loaded after the second subnet node is started, which is beneficial to the second subnet node after migration to normally participate in the blockchain subnet. In addition, in the scheme, the block chain main network triggers the sub-network node migration in a mode of executing the block chain transaction, so that the effective control of the block chain main network on the node migration process of the block chain sub-network is realized. Therefore, the effective and controllable migration of the subnet nodes under the scene that the blockchain main network manages the blockchain subnets is realized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

Fig. 1 is a schematic diagram of a blockchain network according to an exemplary embodiment.

Fig. 2 is a flowchart of a migration method of a blockchain node according to an exemplary embodiment.

Fig. 3 is a schematic diagram of a migration process of a blockchain node according to an exemplary embodiment.

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

Fig. 5 is a block diagram of a migration apparatus of a blockchain node according to an exemplary embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

A person or organization, etc. may participate in the blockchain network as a member of the node, such as may participate in building the blockchain network or join the already-built blockchain network. Any person or organization may participate in only one blockchain network, or may participate in a plurality of blockchain networks.

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

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-network is established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-network establishing process greatly reduces consumed resources, required time consumption and the like, and has higher flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each block link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in establishing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to reveal the configuration information, and when the configuration information comprises identity information of a node member corresponding to a first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on an innovation block comprising the configuration information.

Taking fig. 1 as an example, the blockchain master network is main 0, and the blockchain nodes included in the network are nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet may be initiated by nodeA to mainnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain sub-network, nodeA-nodeD need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain sub-network to mainnet 0; if nodeE is an administrator but allows a normal user to initiate a transaction to build a blockchain subnet, nodeA-nodeE can each initiate the above transaction to build a blockchain subnet to mainnet 0. Of course, the blockchain link points initiating the transaction for building the blockchain subnet do not necessarily participate in the built blockchain subnet, whether by an administrator or by a general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to mainnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

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

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, which is not limited by this specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members. The public and private key pair described above may be used in the process of signature verification. For example, in a signed consensus algorithm, such as nodeA1 in subnet1, signing a message with its own private key, the signed message is broadcast in subnet1, and nodeB1, nodeC1, and nodeD1 can verify that the received message is signed with the public key of nodeA1 to confirm that the received message is indeed from nodeA1 and has not been tampered with.

The configuration information may be used to indicate a node membership corresponding to any master network node in the blockchain master network. When building the blockchain subnet, the main network node does not directly participate in building the blockchain subnet to become a node member thereof, but the node device for deploying the main network node needs to generate a subnet node and the subnet node becomes a node member in the blockchain subnet. As can be seen, the master network node and the subnet nodes correspond to the same block chain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the master network node belongs to a block chain master network and the subnet nodes belong to a block chain subnet, so that the block chain member can participate in the transaction of the block chain master network and the block chain subnet respectively. Moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the main network node and the blocks generated by the sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node equipment, so that mutual isolation between the storages used by the main network node and the sub-network node is realized, data generated by the blockchain sub-network can only be synchronized between the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated on the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the small-range transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

In addition, the master network node and the sub-network nodes are logically divided block chain link points, and from the perspective of physical devices, it is equivalent to that node devices where the two nodes are located participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the main network node and the sub-network node may adopt the same public key, they should be regarded as different blockchain nodes. For example, in fig. 1, nodeA in main 0 corresponds to the main network node, and the node device (i.e., node device 1) deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to the sub-network node. It can be seen that, because the identity systems are independent of each other, whether the public key adopted by the sub-network node is different from that of the main network node or not does not affect the implementation of the solution of this specification.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and all the blockchain members may 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 may still be isolated from each other. For example, one type of service can be implemented on the blockchain main network, and another type of service can be implemented on the blockchain sub-network, so that service data generated by the two types of services can be isolated from each other.

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

One of the advantages of building a block chain subnet by a block chain master network is that since the master network node is already deployed on the node device generating the subnet node, a block chain platform code used by the master network node can be multiplexed on the subnet node, so that repeated deployment of the block chain platform code is avoided, and the building efficiency of the block chain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the subnet node may multiplex the attribute configuration adopted on the main network node; if the configuration information includes the attribute configuration for the blockchain platform code, the subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the subnet node is not limited by the attribute configuration of the main network node and is independent of the main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

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

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

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

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

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

Event：

[topic][data]

......

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

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

It can be seen that the execution result of the Subnet contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the AddSubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeb to nodeb can determine to listen to an event related to execution of the AddSubnet () method, that is, a networking event, by listening to topic included in each event in the generated receipt, in the case where topic including the keyword subnet is listened to. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

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

{subnet1；

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

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

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

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

}

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

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

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the main network node may monitor the generated receipt, and obtain, by the node device deploying the main network node, configuration information or a creation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the main network node belongs to the node member. Or the master network node may monitor the generated receipt, and trigger the node device deploying the master network node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the master network node itself belongs to the node member.

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

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

As described above, the master node and the subnet node deployed in the same node device do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information generated in advance for nodeA 1-nodeD 1, and be distinguished from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

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

The node device realizes the deployment of a blockchain node on the node device by creating an instance of running blockchain platform codes in a process. For the main network node, a first instance is created in the above process by the node device, and is formed by the first instance running blockchain platform code. Similarly, for the subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. For example, the node device may first create a first instance in a process to form a master network node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second instance can be created in the process, the second instance is different from the first instance, and the second instance forms a subnet node in the blockchain subnet. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the subnet node can be reduced, and the deployment efficiency can be improved; of course, the second instance may also be in a different process on the node device than the first instance, and this specification does not limit this; for example, the node device may create a first instance in a first process to form a master network node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second process different from the first process may be started, and a second instance different from the first instance may be created in the second process, so that the second instance forms a subnet node in the blockchain subnet. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on the node device, blocks generated by each block link point deployed on the node device may be stored in different storages (e.g., databases) on the node device, and the storages used by each block link point deployed on any node device are isolated from each other.

Through the method, the block chain sub-network managed by the block chain main network can be created on the block chain main network. Taking fig. 1 as an example, regarding main net0 including nodeA-nodeE, subnet1 may be created on the basis of main net0, where subnet1 includes nodeA 1-nodeD 1, and any subnet node in subnet1 and its corresponding main network node in main net0 are deployed in the same node device, for example, nodeA and nodeA1 are deployed in node device 1, nodeB and nodeB1 are deployed in node device 2, nodeC and nodeC1 are deployed in node device 3, and nodeD1 are deployed in node device 4. Similarly, subnet2 and even more blockchain subnets can be created on mainnet0, where subnet2 contains nodeA2, nodeB2 and nodeE2, and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, and nodeE2 are deployed on the same node device, respectively. And, it is also possible to use subnet1, subnet2, etc. as a blockchain main network, and further create a next-level blockchain subnet based on this, for example, create a blockchain subnet1.1 based on subnet1, which is similar to the creation of subnet1 or subnet2, and only replace the blockchain with the blockchain subnet1, which is not described herein again. As shown in the figure, the node device 1 is deployed with a main network node nodeb a and sub-network nodes nodeb1 and nodeb 2; the node device 2 is provided with a main network node nodeB and sub-network nodes nodeB1 and nodeB 2; a main network node nodeb and a sub-network node nodeb1 are deployed in the node device 3, and a main network node nodeb and a sub-network node nodeb1 are deployed in the node device 4; the node device 5 is deployed with a main network node e and a sub-network node e 2.

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

The chain-crossing interaction can be realized between any two blockchain networks in the blockchain main network and the blockchain sub-network which are established in the mode. Taking nodeC belonging to main 0 and nodeC1 belonging to subnet1 as examples, as can be seen from fig. 1, both are deployed in node device 3, nodeC and nodeC1 are specifically block link point instances (hereinafter referred to as block link nodes) formed by block chain platform codes run by node device 3 in a locally deployed virtual machine, nodeC as related data of the block link nodes in the running process is stored in a main network database corresponding to nodeC, and nodeC1 as related data of another block link node in the running process is stored in a sub-network database corresponding to nodeC1, where the main network database and the sub-network database both belong to a storage space of node device 3. In addition, a blockchain consensus code may be deployed in the node device 3, and by running the consensus code, the node device 3 may locally form a consensus component instance; and the node device can also be deployed with P2P component code managed in a plug-in form, and by running the P2P component code, the node device can locally form a P2P component instance, namely a P2P plug-in. The P2P plug-in deployed in any node device may be shared by different blockchain nodes on the node device, for example, the nodeb and nodeb1 in node device 3 may call the same P2P plug-in running on node device 3 to share its functions and data. The node device 3 may also be deployed with a blockchain service code, and by running the blockchain service code, the node device 3 may locally form a service instance, where at least one service instance, such as a storage instance for implementing a data read/write function, a computation instance for implementing a computation function such as privacy computation, and an encryption instance for implementing a data encryption function, may be implemented in the node device 3, and details are not repeated.

In the embodiment of the present specification, the master node and the sub-network node on the same node device share a blockchain communication plug running on the node device, such as the aforementioned P2P plug. The network connection link implemented when forming main 0 may be specifically established by nodeC and nodeE respectively using P2P plug-ins on node device 3 and node device 5. Since the P2P plugin on the node device can be shared by each blockchain node on the node device, the nodeb1 in the subnet1 can call the P2P plugin running locally on the node device 3, and establish a network connection with the P2P plugin running on the node device 5 to which the nodeb2 belongs by means of the network connection between the node device 3 and the node device 5 based on the P2P plugin, which is implemented when forming the main 0, thereby sending a cross-chain message to the node device 5, and further implementing network communication with the nodeb 2. By the method, a new network connection link does not need to be established between the source block chain network and the target block chain network, and network communication between the source node in the source block chain network and the target node in the target block chain network can be realized through the network connection link established in advance by the bottom block chain main network.

The block chain sub-network created in the above manner can be managed by the block chain main network. In order to realize controllable migration of subnet nodes in a blockchain subnet under a scenario in which a blockchain master network manages blockchain subnets, the present specification provides a migration method of blockchain nodes, where a master network node controls migration of subnet nodes by executing a transaction. The present solution is described in detail below with reference to the accompanying drawings.

Fig. 2 is a flowchart of a migration method of a blockchain node according to an embodiment of the present disclosure. As can be seen in FIG. 2, the method includes steps 202-208.

Step 202, a master network node deployed in a first node device sends created block information of a block chain sub-network to the first node device by executing a node migration transaction, so that the first node device sends the created block information to a second node device, and a block chain master network to which the master network node belongs is used for managing the block chain sub-network.

As described above, the present solution is used to migrate a first subnet node in a blockchain subnet to a second subnet node, specifically, the second subnet node is started in a second node device, and the started subnet node loads history data of the first subnet node. It should be noted that, in the embodiment described in this specification, any master network node in the blockchain master network and any subnet node in the blockchain subnet are not deployed in the second node device for deploying the second subnet node. For example, no blockchain node may be deployed in the second subnet node, or blockchain link points that are not associated with the blockchain main network and the blockchain subnet in the present solution may also be deployed, and this is not limited by the embodiments of this specification.

Any one of the master network nodes in the blockchain master network is deployed in the first node device, and the first subnet node to be migrated may be deployed in the first node device, or may be deployed in other node devices besides the first node device and the second node device. As shown in fig. 1, in a case that the first subnet node is a subnet node nodeb2 in subnet2, the first node device may be a node device 1, and at this time, a master network node nodeb and a first subnet node nodeb2 are deployed in the node device; or, the first node device may also be the node device 3, and at this time, the master network node nodeb is deployed in the node device, but the subnet node in the subst 2 is not deployed.

In one embodiment, the node migration transaction may be initiated by a variety of blockchain participants. For example, the transaction may be initiated by an administrator of the blockchain master network or blockchain subnet. It can be understood that an administrator of a blockchain subnet typically knows the various subnet nodes included in the blockchain subnet; since the blockchain subnet is managed by the blockchain master network, an administrator of the blockchain master network can also know each subnet node included in the blockchain subnet. Therefore, based on the above information, the administrators of the blockchain master network and the blockchain sub-network can both initiate the node migration transaction through any master network node in the blockchain master network, so as to implement the migration management of the first sub-network node. For another example, a node member corresponding to any one of the subnet nodes in the block chain master network may initiate the node migration transaction through the corresponding master network node, and certainly, based on the management relationship between the block chain master network and the block chain slave network, a node member corresponding to any one of the master network nodes in the block chain master network may initiate the node migration transaction through the corresponding master network node. Still taking the first subnet node as subnet node nodeA2 in subnet2 shown in FIG. 1 as an example, the node member corresponding to nodeA2 may initiate a node migration transaction for nodeA2 to main 0 through nodeA, and the node members corresponding to nodeB2 and nodeE2 may also initiate the transaction through nodeB and nodeE, respectively; or, the node member corresponding to nodeA may initiate a node migration transaction for nodeA2 to mainnet0 through nodeA, and the node members corresponding to nodeB to E may also initiate the transaction through nodeB to E, which is not described in detail. By the method, an administrator or related node members with transaction initiation authority can initiate the node migration transaction, so that the migration control requirements of various forms can be met.

After the node migration transaction is initiated, each master network node in the blockchain master network may acquire and execute the transaction, respectively. The transaction may include an execution time of the transaction, such as starting to trigger execution after the first time, completing execution in a time period between the second time and the third time, triggering execution before the fourth time or ending execution (otherwise terminating execution), and the like. Based on the execution time, the master network node deployed in the first node device may execute the node migration transaction at the corresponding time node, so as to implement accurate control on the node migration process. It can be understood that, when there are multiple subnet nodes in the blockchain subnet that need to be migrated, the execution time may be a transaction execution time for each subnet node, so as to implement management and control on the migration time of each subnet node, and facilitate implementation of progressive migration of each subnet node, so as to ensure availability of the blockchain subnet in the migration process as much as possible.

In one embodiment, the creation block information of the blockchain sub-network may be recorded in the system contract of the blockchain main network, in view of the fact that the blockchain sub-network is managed by the blockchain main network. Based on this, the main network node may call the system contract to obtain the created block information in the process of executing the node migration transaction, and output the obtained created block information to the first node device.

In another embodiment, the master network node may expose the founder block information of the blockchain subnet to that first node device through an event mechanism. For example, the primary network node may perform a node migration transaction to generate a node migration event containing the founder block information, which event is allowed to be heard by the first node device. Thus, the first node device may listen for the node migration event and extract the founding block information from the event that is listened to. In fact, through this way, asynchronous transfer of the created block information can be realized between the main network node and the first node device, thereby contributing to improving the overall processing efficiency of the first node device on the block chain transaction.

The node migration event may be recorded in a receipt generated by executing the node migration transaction, and the receipt may further record a network address of the second node device. Based on this, the first node device may obtain the network address of the second node device from the receipt, and send the created block information extracted from the node migration event to the second node device according to the network address. It is understood that the network address may be acquired by the initiator of the node migration transaction in a downlink manner and recorded in the transaction, so that the first node device establishes a network connection with the second node device through the network address, and then sends the founding block information to the first node device based on the network connection. Of course, the initiator of the node migration transaction may also execute the network address of the second node device to the first node device in other manners, which is not limited in this embodiment of the specification.

In the embodiments described in the specification, the creation block information of the blockchain subnet may include a network identifier of the subnet, identity information of an administrator of the subnet, identity information of each creator of the subnet (e.g., an initial node member participating in creating the subnet), attribute configuration of a blockchain platform code for the subnet, and the like. The attribute configuration of the platform code may include information such as a code version number, whether consensus is required, a consensus algorithm type, and/or a block size, which is not described in detail.

And 202, the second node equipment generates a creation block according to the creation block information, and starts a second subnet node by loading the creation block.

In the case of acquiring the created block information sent by the first node device, the second node device may generate a created block according to the information. It can be understood that, because the creation block information is the creation block information of the block chain subnet, the created creation block is the creation block of the block chain subnet, and the block chain node started by loading the creation block also belongs to the block chain subnet, that is, the second subnet node is the block chain node belonging to the block chain subnet. In addition, the creation block generated by the first node device (i.e., the creation block for starting the second subnet node) is not substantially different from the maintained creation blocks of other subnet nodes in the blockchain subnet, and in fact, the creation blocks of each subnet node joining the blockchain subnet are the same. The specific process of generating the created block by the second node device according to the created block information may refer to the description in the related art, and details are not described here.

The second node device may load the second subnet node by creating an instance. For example, the second node device may locally pull a process and create an instance in the process to launch the second subnet node by the instance by loading the founder block. In addition, the second node device may assign a corresponding subnet database to the instance, so that the record loads the created blocks into the subnet database. The second node device may specify the subnet database by setting a path or a directory, and a storage space corresponding to the subnet database may be local to the second node device, and of course, may also be in other devices that the second node device allows to access, which is not described again.

As shown in fig. 1, after the completion of the startup as the second sub-network node, a sub-network node nodeF2 exists in the node device 6 as the second node device, but the node has not joined the blockchain network, so that no connection has been established between nodeF2 and nodeA2, nodeB2, and nodeE 2. It should be noted that the node device 6 may be different from new devices of the node devices 1 to 5, or may also be the node device 3 or the node device 4. Taking the node device 6 and the node device 3 as the same node device as an example, at this time, the master node nodeb in main 0 is deployed in the node device, but because a subnet node corresponding to nodeb does not exist in subnet2, a subnet node nodeb f2 belonging to subnet2 may still be deployed in the node device according to the scheme described in this specification.

Step 206, the second subnet node joins the blockchain subnet, and loads the history data of the first subnet node in the blockchain subnet.

After the start is completed, the second subnet node is also only an isolated blockchain node, and the second subnet node can become a member of the blockchain subnet only by adding the blockchain subnet, and can realize interaction with other subnet nodes.

In an embodiment, the creation block information may include identity information and a network address of other subnet nodes in the blockchain subnet, and the identity information and the network address may be collected and recorded in a offline manner by an initiator of a node migration transaction, and may also be maintained in a system contract of a blockchain main network, which is not limited in this specification. Furthermore, the second subnet node may establish a network connection with other subnet nodes according to the identity information and the network address. The second subnet node and any other node device may implement network connection through the P2P component, for example, the second node device and any other node device may be respectively deployed with corresponding P2P components, and the second subnet node may call the P2P component in the second node device to establish network connection with the P2P component in any other node device. After the network connection between the second subnet node and other subnet nodes is completed, the second subnet node and other subnet nodes can realize network communication, and at this time, the second subnet node participates in the block chain subnet and becomes a subnet node in the subnet.

Further, the second subnet node may acquire node information of each subnet node in the blockchain subnet from other subnet nodes, so as to create and maintain a node list for each subnet node in the blockchain subnet locally. As described above, the creature block information corresponds to the initial node member participating in creating the blockchain subnet, and therefore the identity information and the network address may be only the identity information and the network address of the initial node member, and therefore the second subnet node can establish a network connection with the initial node member only according to the information. For this reason, if the node list includes a late joining node member in addition to the initial node member, the second subnet node may also establish a network connection with the late joining node member. It can be understood that, with respect to the initial node member in the blockchain subnet, the second subnet node also belongs to the late joining node member, and details are not described again.

Referring to fig. 1 and fig. 3, taking the first subnet node as subnet node a2 in subnet2 and the second subnet node as node f2 as examples, after the node f2 started by the node device 6 joins the blockchain subnet, it forms subnet2 with the original nodes nodeA2, nodeB2 and nodeD 2.

The second subnet node after the completion of the starting needs to load the historical data of the first subnet node so as to participate in the operation of the blockchain subnet based on the part of the historical data after the migration. The history data is blockchain data generated by the first subnet node during the operation (such as transaction consensus, transaction execution, smart contract deployment and execution, and the like) of the blockchain subnet, and may include, for example, a history block, a history transaction, a transaction receipt, status data, and the like, which is not limited in this embodiment of the present specification.

As already mentioned, the second node device may assign a corresponding subnet database to the second subnet node, based on which the second subnet node may load the history data of the first subnet node into this subnet database. It will be appreciated that the subnet database described above corresponds to the second subnet node, so the second node device has access to the database, such as to read data from or write data to the database. Moreover, the subnet database may be isolated from other databases in the second node device to prevent the blockchain data of the second subnet node from being acquired by other interested parties, so as to implement the authority management on the portion of blockchain data. For example, if other blockchain nodes are also deployed in the second node device, the database of the blockchain node may be isolated from the subnet database of the second subnet node, so as to prevent the blockchain node and the second subnet node from accessing the blockchain data of the other node, which is beneficial to ensuring the privacy of the blockchain data of each node.

However, since the history data can be obtained in various ways, the way in which the second subnet node loads the data is different accordingly. For example, the second subnet node may synchronize the history data from the first subnet node in the blockchain subnet after joining the blockchain subnet is complete. Of course, considering that the blockchain data respectively maintained by each blockchain link point in the same blockchain network may be the same, the second subnet node may also synchronize the history data from other subnet nodes in the blockchain subnet. The second subnetwork node may also synchronize the data from a plurality of subnetwork nodes simultaneously in order to obtain the history data as soon as possible. In the case where the history data includes first history data maintained only by the first subnet node and second history data respectively maintained by each subnet node in the blockchain subnet, the second subnet node may synchronize the first history data from the first subnet node and synchronize the second history data from at least one other subnet node at the same time, so as to acquire the entire history data as soon as possible and reduce the time consumption of the history data migration process.

In addition, considering that the data volume of the historical data may be larger, that is, the historical data to be migrated is more, in order to further improve the efficiency of data migration, the second node device may also obtain the historical data in a link-down manner, so as to be loaded by the started second subnet node. For example, the administrator of the second node device may load a storage device storing the history data into the second node device, and the second subnet node may load the history data from the storage device, for example, a storage directory of the history data in the storage device may be added to the accessible directory of the subnet database, that is, a storage space where the history data is located is a part of the storage space of the subnet database, and thereafter, the second subnet node may access the history data through the storage directory. It is understood that the process of accessing the history data by the second subnet node through the storage directory is the process of accessing the subnet database. Or, the second subnet node may also copy the history data recorded in the storage device to a storage space corresponding to the subnet database, and then may access the copied history data in the storage space. The storage device may include a hardware device such as a disk, a solid state disk, and a U disk, which are unloaded from the first node device, and certainly, in a case that the history data is also maintained by other subnet nodes, the hardware device may also be unloaded from other node devices (for example, a node device closer to the second node device) of the subnet node where the blockchain subnet is deployed, and this is not limited in the embodiment of the present specification. By the method, the manager of the second node device can rapidly transfer the historical data to be transferred to the second node device in a hardware unloading and loading mode so as to load the historical data on the second subnet node. Under the conditions that the bandwidth of the second node device is limited, the data size of the historical data is too large, the first node device is close to the second node device, and the like, the method can effectively improve the migration efficiency of the historical data.

It can be understood that, since the foregoing second subnet node consumes a certain time during startup and loading of the history data, during which the subnet node in the blockchain subnet in the normal operation state may generate the latest data different from the history data, in order to ensure that the second subnet node can smoothly participate in the operation of the blockchain subnet, the second subnet node may also synchronize the latest data different from the history data from other subnet nodes in the blockchain subnet after joining the blockchain subnet, and load the synchronized latest data. Certainly, a logical dependency relationship may exist between the latest data and the history data, so that the latest data may be synchronized and loaded after the history data is loaded, so as to ensure that the dependency relationship between the blockchain data locally loaded by the second subnet node remains unchanged, and further ensure that the blockchain subnet operates normally as much as possible.

And step 208, under the condition that the second subnet node finishes loading the history data, the first subnet node exits the block chain subnet.

After the second subnet node finishes loading the historical data, the second subnet node can normally participate in the operation of the blockchain subnet by accessing the historical data, such as participation in transaction consensus, transaction execution, intelligent contract deployment and execution and the like. At this time, in order to realize the migration of the first subnet node, the first subnet node also needs to exit the blockchain subnet, and after the first subnet node exits the blockchain subnet, the second subnet node can functionally replace the first subnet node to participate in the operation of the blockchain subnet.

Wherein the first subnet node may exit the blockchain subnet in a variety of ways. For example, the node migration event generated by the master node performing the node migration transaction may be used to indicate the subnet node to be exited, that is, to indicate which subnet node in the blockchain subnet is the first subnet node to be migrated, in addition to revealing the founder block information. For example, the identity information of the first subnet node may be recorded in the event, so that the first subnet node may wait for the newly started second subnet node to complete loading the history data when monitoring the node migration event and determining that the identity information of the first subnet node is recorded therein, and exit the blockchain subnet when determining that loading is complete. The second subnet node may send a notification message to the first subnet node after the second subnet node finishes loading the history data, so as to notify that the second subnet node finishes loading the history data. In order to ensure that the notification message is received by the first subnet node as much as possible, the second subnet node may broadcast the notification message in the blockchain subnet, so that each subnet node determines whether it should respond to the notification message; alternatively, to reduce the occupation of the notification message on the on-line communication resources of the blockchain subnet, the second subnet node may also specifically send the notification message to the second subnet node, and this is not limited in this embodiment of the specification. By the method, the second sub-network node can be started and the first sub-network node can be quitted in sequence only by initiating a node migration transaction in the block chain main network, so that the node migration process is simplified, and the migration efficiency is improved.

For another example, the initiator of the node migration transaction may initiate a node exit transaction for the first subnet node in the blockchain subnet when it is determined that the loading of the history data by the second subnet node is completed; alternatively, the transaction may be initiated by the second subnet node upon determining that loading the history data is complete. Further, each subnet node in the blockchain subnet may respectively obtain and execute the node exit transaction, so that the first subnet node exits the blockchain subnet. By the method, the initiator of the transaction can automatically control when the node is initiated to exit the transaction so as to control the node of the first sub-network to exit the blockchain sub-network at a proper time and avoid influencing the normal operation of the sub-network.

Specifically, the first subnet node may disconnect the communication connection with other subnet nodes in the block chain subnet, and after the communication connection is disconnected, the first subnet node and each other subnet node in the block chain subnet cannot perform the on-chain communication any more, and the node cannot participate in the operation of the subnet any more.

In addition, the first subnet node may also delete the communication address of the other subnet node from the communication list of the blockchain network maintained by the first subnet node, and correspondingly, the communication address of the first subnet node is deleted from the communication list of the blockchain network maintained by the first subnet node when the network connection between the first subnet node and the other subnet node is disconnected. It can be understood that the function of the communication list of the blockchain subnet is to enable the subnet node to communicate with other nodes according to the communication addresses of other nodes belonging to one subnet recorded in the communication list, so as to implement transaction forwarding, consensus, and the like. Deleting the communication address of the first subnet node from the communication list by each subnet node in the block chain subnet, which may result in that the first subnet node can no longer communicate with other nodes in the same subnet, and also functionally excluding the first subnet node from the subnet.

In addition, since the blockchain sub-network is managed by the blockchain main network, each main network node in the blockchain main network establishes a management relationship with respect to each sub-network node in the blockchain sub-network, and thus, each main network node in the blockchain main network can release the management relationship with respect to the first sub-network node in response to completion of the first sub-network node exiting the blockchain sub-network. Wherein, the establishment of the management relationship to a certain node can be understood as the registration of the authority of the node participating in the corresponding subnet; and canceling the management relation of the node can be understood as canceling the authority of the node participating in the corresponding sub-network. Wherein each master network node in the blockchain master network can contact the management relationship for the first subnet node by performing a transaction. The initiator of the transaction may be the first subnet node itself, or may be a member client corresponding to the blockchain system (i.e., a client used by a member corresponding to the first subnet node), which is not limited in this embodiment of the specification.

It should be noted that, the migration scheme of the blockchain node in the embodiment of the present disclosure is described only for one subnet node (i.e., the first subnet node) in the blockchain subnet. In fact, there may be a plurality of subnet nodes to be migrated in the blockchain subnet, and any one of the subnet nodes may be processed by the foregoing scheme to migrate the subnet node to a new subnet node in the blockchain subnet. Moreover, the node migration transaction may also indicate the start time information of each second subnet node and the push-out time information of the first subnet node, and for example, a time when each second subnet node joins the blockchain subnet and a time when each first subnet node exits the blockchain subnet may be specified in time sequence, so that in the process of executing the transaction, migration of each first subnet node may be sequentially realized in a workflow manner, and automation control of the migration process of the plurality of first subnet nodes is realized. It can be understood that, because the first sub-network node exits the blockchain sub-network after the second sub-network node finishes loading the history data (i.e. the second sub-network node can participate in the operation of the blockchain sub-network), even if there are multiple sub-network nodes exiting simultaneously or in a short time, it can be ensured that there are a sufficient number of sub-network nodes participating in the operation of the blockchain sub-network, thereby facilitating the implementation of progressive migration of each sub-network node.

Referring to fig. 1, the node change situation of the blockchain subnet is still described by taking the first subnet node as the subnet node nodeA2 in the subnet and the second subnet node as nodeF2 as examples. Before nodeF2 joins subnet2 is completed, subnet2 contains 3 subnet nodes, namely nodeA2, nodeB2 and nodeD2, which is the initial state of the blockchain subnet before nodeA2 migration. When nodeF2 joins subnet2 and nodeF2 has not exited the blockchain subnet, subnet2 includes 4 subnet nodes, that is, nodeA2, nodeB2, nodeD2 and nodeF2, at this time, each subnet node can participate in the operation of the blockchain subnet, and at this time, it is an intermediate state of the migration process of nodeA 2. Further, after nodeA2 exits the blockchain subnet, subnet2 includes 3 subnet nodes, that is, nodeB2, nodeD2 and nodeF2, which is the completion state after nodeA2 migration. It can be seen that through the migration process of the blockchain node, nodeA2 in the blockchain subnet is replaced by nodeF2, that is, the migration of nodeA2 is realized, and the migrated nodeF2 can participate in the operation of the blockchain subnet based on the history data of nodeA2 loaded by itself.

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

Fig. 5 is a block diagram of a migration apparatus of a blockchain node according to an exemplary embodiment, which may be applied to the device shown in fig. 4 to implement the technical solution of the present specification. The device includes:

an information disclosure unit 501, configured to enable a master network node deployed in a first node device to disclose created block information of a block chain subnet to the first node device by performing a node migration transaction, so that the first node device sends the created block information to a second node device, where a block chain master network to which the master network node belongs is used to manage the block chain subnet;

a node starting unit 502, configured to generate a creature block according to the creature block information by the second node device, and start a second subnet node by loading the creature block;

a node adding unit 503, configured to add the second subnet node to the blockchain subnet, and load historical data of the first subnet node in the blockchain subnet;

a node exit unit 504, configured to, when the second subnet node finishes loading the history data, exit the blockchain subnet from the first subnet node.

Optionally, the information exporting unit 501 is further configured to:

the master network node performs a node migration transaction to generate a node migration event containing the genesis block information of the blockchain subnet, the node migration event being allowed to be heard by the first node device.

Optionally, the node migration event is recorded in a receipt of the node migration transaction, and the information exporting unit 501 is further configured to:

and the first node equipment acquires the network address of the second node equipment from the receipt, and sends the creating block information to the second node equipment according to the network address.

Optionally, the creature block information is recorded in the system contract of the block chain master network, and the information exporting unit 501 is further configured to:

and the main network node calls the system contract to acquire the created block information in the process of executing the node migration transaction, and the acquired created block information is transmitted to first node equipment.

Optionally, the creation block information includes identity information and a network address of other subnet nodes in the block chain subnet, and the node joining unit 503 is further configured to:

and the second subnet node establishes network connection with other subnet nodes according to the identity information and the network address.

Alternatively to this, the first and second parts may,

a database specifying unit 505 is further included, configured to specify a subnet database for the second subnet node by the second node device;

the node joining unit 503 is further configured to: and the second subnet node loads the historical data into the subnet database.

Optionally, the method further includes:

a link-down obtaining unit 506, configured to obtain the history data by the second node device in a link-down manner; and/or the presence of a gas in the gas,

and an on-chain obtaining unit 507, configured to synchronize the history data from other subnet nodes in the blockchain subnet after the second subnet node joins the blockchain subnet.

Optionally, the method further includes:

and a latest data synchronization unit 508, configured to synchronize, from other subnet nodes in the blockchain subnet, latest data different from the historical data after the second subnet node joins the blockchain subnet, and load the synchronized latest data.

Optionally, the node exit unit 504 is further configured to:

the first sub-network node exits the block chain sub-network in response to the identity information of the first sub-network node recorded in a node migration event, wherein the node migration event is generated by the main network node executing the node migration transaction; alternatively, the first and second electrodes may be,

and each subnet node in the block chain subnet executes node exit transaction respectively so as to enable the first subnet node to exit the block chain subnet.

Optionally, the node exit unit 504 is further configured to:

the first sub-network node disconnects the communication connection with other sub-network nodes in the block chain sub-network.

Optionally, the method further includes:

a first deleting unit 509, configured to delete, by the first subnet node, the communication address of the other subnet node from the communication list of the block chain subnet maintained by the first subnet node; and/or the presence of a gas in the gas,

a second deleting unit 510, configured to delete, by the other subnet node, the communication address of the first subnet node from the communication list of the blockchain subnet maintained by the other subnet node when the network connection between the other subnet node and the first subnet node is disconnected.

Optionally, the method further includes:

and the relationship releasing unit 511 is configured to, in response to that the first subnet node finishes exiting the blockchain subnet, release the management relationship on the first subnet node by each master network node in the blockchain master network.

Optionally, the first subnet node is deployed in the first node device.

Optionally, the node migration transaction is initiated by one of:

the system comprises an administrator of the block chain main network, an administrator of the block chain sub-network, a node member corresponding to any main network node in the block chain main network, and a node member corresponding to any sub-network node in the block chain sub-network in the block chain main network.

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

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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

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

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

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

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

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

Claims

1. A migration method of a blockchain node comprises the following steps:

2. The method of claim 1, the primary network node divulging the foundational block information of the blockchain subnet to the first node device by performing a node migration transaction, comprising:

3. The method of claim 2, the node migration event recorded in a receipt of the node migration transaction, the first node device sending the chunking information to a second node device, comprising:

4. The method of claim 1, wherein the founder chunk information is recorded in a system contract of the blockchain master, and the master node divulges the founder chunk information of blockchain subnets to the first node device by performing a node migration transaction, comprising:

5. The method of claim 1, the founder block information including identity information and network addresses of other subnet nodes in the blockchain subnet, the second subnet node joining the blockchain subnet, comprising:

and the second subnet node establishes network connection with the other subnet nodes according to the identity information and the network address.

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

further comprising: the second node device designates a subnet database for the second subnet node;

the second subnet node loads the history data, including: and the second subnet node loads the historical data into the subnet database.

7. The method of claim 1, wherein the historical data stored in the subnet database is obtained by:

the second node equipment acquires the historical data in a link-down mode; and/or the presence of a gas in the gas,

and after the second subnet node is added into the block chain subnet, synchronizing the historical data from other subnet nodes in the block chain subnet.

8. The method of claim 1, further comprising:

and after the second subnet node is added into the blockchain subnet, synchronizing the latest data different from the historical data from other subnet nodes in the blockchain subnet, and loading the synchronized latest data.

9. The method of claim 1, the first subnet node exiting the blockchain subnet, comprising:

10. The method of claim 1, the first subnet node exiting the blockchain subnet, comprising:

and the first sub-network node disconnects the communication connection with other sub-network nodes in the block chain sub-network.

11. The method of claim 10, further comprising:

the first subnet node deletes the communication addresses of other subnet nodes from the communication list of the block chain subnet maintained by the first subnet node; and/or the presence of a gas in the gas,

and deleting the communication address of the first subnet node from the communication list of the block chain subnet maintained by the other subnet node under the condition that the network connection between the other subnet node and the first subnet node is disconnected.

12. The method of claim 1, further comprising:

and in response to the completion of the first subnet node exiting the blockchain subnet, each main network node in the blockchain main network releases the management relationship on the first subnet node.

13. The method of claim 1, the first subnet node being deployed in the first node device.

14. The method of claim 1, the node migration transaction initiated by one of:

15. A block link point transfer device comprising:

16. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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