WO2021184878A1

WO2021184878A1 - Node management method for block chain system, node, and computational device

Info

Publication number: WO2021184878A1
Application number: PCT/CN2020/139713
Authority: WO
Inventors: 林鹏
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-03-16
Filing date: 2020-12-26
Publication date: 2021-09-23
Also published as: CN111049696B; CN111049696A

Abstract

Embodiments of the present description provide a node management method for a block chain system, a node, and a computational device. The method comprises: a first node within a block chain system performs pre-voting interaction with each node in the block chain system, so as to determine whether the block chain system is in a main node election process; if the block chain system is not in a main node election process, the first node executes an operation that causes the deletion of a node to be deleted from within the block chain system; if the block chain system is in a main node election process, the first node determines not to execute an operation that causes the deletion of a node to be deleted from within the block chain system.

Description

Method, node and computing equipment for node management of blockchain system

Technical field

The embodiments of this specification relate to the field of blockchain technology, and more specifically, to a method, node, and computing device for node management of a blockchain system.

Background technique

Blockchain technology, also known as distributed ledger technology, is a kind of emerging that several computing devices (also called nodes in this article) participate in "bookkeeping" and jointly maintain a complete distributed database. technology. Due to the various characteristics of blockchain technology such as decentralization, openness, transparency, and non-tamperability, blockchain technology has been widely used in many fields.

Summary of the invention

In consideration of the above-mentioned problems, the embodiments of the present specification provide a method, a node, and a computing device for node management of a blockchain system.

On the one hand, the embodiments of the present specification provide a method for node management of a blockchain system, including: a first node in the blockchain system performs pre-voting interaction with each node in the blockchain system To determine whether the blockchain system is in the master node election process; in the case that the blockchain system is not in the master node election process, the first node executes to make the node to be deleted from the block The operation that is deleted in the chain system; in the case that the blockchain system is in the process of master node election, the first node determines not to perform the operation that causes the node to be deleted to be deleted from the blockchain system operate.

On the other hand, the embodiment of the present specification provides a method for node management of a blockchain system, including: the second node in the blockchain system and the first node in the blockchain system perform pre-processing. Voting interaction to assist the first node in determining whether the blockchain system is in the master node election process; if the first node requests the slave node when the blockchain system is not in the master node election process If the node to be deleted is deleted from the blockchain system, the second node performs an operation that causes the node to be deleted to be deleted from the blockchain system; wherein, if the blockchain system is at the master node During the election process, the node to be deleted cannot be deleted from the blockchain system.

On the other hand, the embodiment of this specification provides a node in a blockchain system, including: an interaction unit, configured to perform pre-voting interaction with each node in the blockchain system to determine the block Whether the chain system is in the master node election process; the execution unit is used to execute the task of deleting the node to be deleted from the blockchain system when the blockchain system is not in the master node election process Operation; In the case that the blockchain system is in the process of master node election, it is determined not to perform the operation that causes the node to be deleted to be deleted from the blockchain system.

On the other hand, the embodiment of the present specification provides a node in a blockchain system, including: an interaction unit for performing pre-voting interaction with the first node in the blockchain system to assist the first node A node determines whether the blockchain system is in the master node election process; the execution unit is configured to: if the first node is not in the master node election process in the blockchain system, request a slave If the node to be deleted is deleted from the blockchain system, an operation is performed to make the node to be deleted be deleted from the blockchain system; wherein, if the blockchain system is in the master node election process, the The node to be deleted cannot be deleted from the blockchain system.

It can be seen that in this technical solution, it is possible to perform operations that cause the node to be deleted to be deleted from the blockchain system when the blockchain system is not in the master node election process, and the blockchain system is at the master node In the case of the election process, it is determined not to perform the corresponding deletion operation. In this way, the block chain system can effectively avoid the confusion caused by the deletion of nodes in the master node election process, so as to ensure the stability and reliability of the blockchain system in the master node election process.

Description of the drawings

Through a more detailed description of the embodiments of this specification in conjunction with the accompanying drawings, the above and other objectives, features and advantages of the embodiments of this specification will become more apparent. Among them, in the embodiments of this specification, the same reference numerals Usually represent the same element.

Fig. 1A is a schematic flowchart of a method for node management of a blockchain system according to an embodiment.

Fig. 1B is a schematic flowchart of a method for node management of a blockchain system according to an embodiment.

Figure 2 is an interactive schematic diagram of a scenario for node management in a blockchain system.

Fig. 3A is a schematic block diagram of a node in a blockchain system according to an embodiment.

Fig. 3B is a schematic block diagram of a node in a blockchain system according to an embodiment.

Fig. 4A is a hardware structure diagram of a computing device for node management of a blockchain system according to an embodiment.

Fig. 4B is a hardware structure diagram of a computing device for node management of a blockchain system according to an embodiment.

Detailed ways

The subject described herein will now be discussed with reference to various embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and implement the subject matter described herein, and is not to limit the scope of protection, applicability, or examples set forth in the claims. The function and arrangement of the discussed elements can be changed without departing from the scope of protection of the claims. Various embodiments may omit, replace, or add various processes or components as needed.

A blockchain system based on blockchain technology can include multiple nodes. Among these multiple nodes, one node can be elected as the master node, and the other nodes can be the slave nodes. The master node can be responsible for initiating transaction consensus, and can be responsible for creating the latest block for the blockchain based on the transaction data passed by the consensus.

The master node can be dynamically generated according to different situations. For example, before the blockchain system performs consensus processing, the master node can be elected from each node first. For another example, when the master node and the slave node cannot communicate due to network delays, failure of the master node, etc., a new master node can be re-elected. For another example, when most nodes think that the master node is a malicious node (for example, sending fake data or wrong data, etc.), a new master node can be re-elected.

Based on the consensus algorithm adopted by the blockchain system, the mechanism for electing the master node can be different. For example, in this specification, the blockchain system can adopt various applicable consensus algorithms such as the RAFT algorithm and the Practical Byzantine Fault Tolerance (PBFT) algorithm.

No matter what consensus algorithm is based on, the master node election process takes a certain amount of time to complete. During this process, if other operations are performed at the same time, bandwidth may be occupied and timeout may be caused, which may affect the stability of the entire blockchain system. For example, if a node is deleted from the blockchain system during the election of the master node, and the node may still participate in consensus processing, this may cause confusion in the message mechanism of the blockchain system, which will seriously affect the entire blockchain The reliability and stability of the system.

In view of this, in this specification, the first node in the blockchain system can interact with each node in pre-voting to determine whether the blockchain system is in the process of master node election. In the case that the blockchain system is not in the master node election process, the first node may perform an operation that causes the node to be deleted to be deleted from the blockchain system. In the case where the blockchain system is in the master node election process, the first node may determine not to perform an operation that causes the node to be deleted to be deleted from the blockchain system.

In this specification, the blockchain system can include a public chain system, a private chain system, or a consortium chain system.

For example, in a scenario, the blockchain system can be a consortium chain system composed of a third-party payment platform server, a domestic bank server, an overseas bank server, and several user nodes as members. The operator of the alliance chain can rely on the alliance chain to deploy online services such as cross-border transfers and asset transfers based on the alliance chain.

However, considering the scale of nodes deployed in the public chain system, private chain system, and consortium chain system, the technical solution in this specification will produce better results in the consortium chain system or private chain system, but the technical solution in this specification is also applicable to Public chain system.

The technical solutions in this specification will be described below in conjunction with specific embodiments.

As shown in FIG. 1A, in step 102A, the first node in the blockchain system can perform pre-voting interaction with each node in the blockchain system to determine whether the blockchain system is in the master node election process.

In step 104A, in the case that the blockchain system is not in the master node election process, the first node may perform an operation that causes the node to be deleted to be deleted from the blockchain system.

In step 106A, when the blockchain system is in the master node election process, the first node may determine not to perform an operation that causes the node to be deleted to be deleted from the blockchain system.

It can be seen that in this technical solution, it is possible to perform operations that cause the node to be deleted to be deleted from the blockchain system when the blockchain system is not in the master node election process, and the blockchain system is at the master node In the case of the election process, it is determined not to perform the corresponding deletion operation. In this way, it is possible to effectively avoid problems such as confusion caused by the deletion of nodes in the master node election process of the blockchain system, thereby ensuring the stability and reliability of the blockchain system in the master node election process.

In this specification, the node to be deleted can be any node in the blockchain system. The node can be deleted from the blockchain system for various reasons. For example, if the node needs to exit the blockchain system for its own reasons (for example, resource restrictions, management issues, etc.), the node can be deleted from the blockchain system. For another example, if the node cannot communicate with other nodes due to a certain failure, the node can be deleted from the blockchain system. For another example, if the node is a malicious node (for example, sending a fake message or an error message), the node can be deleted from the blockchain system.

For example, the operation of deleting a node may be initiated by the node to be deleted. At this time, the aforementioned first node may be a node to be deleted, that is, the first node and the node to be deleted refer to the same node.

In addition, the node deletion operation can also be initiated by nodes other than the node to be deleted in the blockchain system. For example, most nodes in the blockchain system can reach an agreement on the need to delete a node offline. For example, most nodes think that a certain node is faulty or a malicious node, so the node needs to be deleted. Then, the agreed nodes can convert the offline agreement on the need to delete the node into an online contract of the blockchain system. This process can be done using public and private keys. In this case, the first node may be a node different from the node to be deleted. For example, the first node may be a non-Byzantine node.

In one embodiment, in step 102A, the first node may send a pre-vote message to each node. The pre-voting message may include information for identifying the node to be deleted.

For example, the first node may broadcast a pre-voting message to each node. For another example, the first node can send a pre-voting message to neighboring nodes, and then the neighboring nodes can forward the pre-voting message to other nodes, so that each node in the blockchain system receives the pre-voting message through the forwarding mechanism . The first node may also use other applicable communication methods to send the pre-voting message, which is not limited in this specification.

Then, the first node may receive a pre-vote-ack message sent by each node for the pre-vote message. For example, the first node may receive M pre-voting confirmation messages sent by M nodes. M is a positive integer.

In one case, the first node may receive the pre-voting confirmation message sent by all other nodes in the blockchain system. At this time, M is equal to the value obtained by subtracting 1 from the total number of nodes in the blockchain system.

In another case, the first node may not receive the pre-voting confirmation messages sent by all other nodes due to various reasons (for example, network delay, node failure, etc.). At this time, M can be less than the value obtained by subtracting 1 from the total number of nodes in the blockchain system.

The pre-voting confirmation message may indicate the consensus state of the node that sent the pre-voting confirmation message. For example, the consensus state may include the master node election state, synchronization state, normal processing state, initialization state, and so on.

In this way, the first node can determine whether the blockchain system is in the master node election process based on the received M pre-voting confirmation messages.

It can be seen that in this embodiment, through the interaction of the pre-voting message and the pre-voting confirmation message, it is possible to efficiently determine whether the blockchain system is in the process of master node election, thereby assisting the first node to determine whether the operation of deleting the node can be performed. This can avoid affecting the stability of the blockchain system in the master node election process.

In one embodiment, the pre-voting message may include the identification and network address of the node to be deleted. For example, the format of the pre-voting message may be as follows: pre-vote<i,address>, where i represents the identification of the node to be deleted, and address represents the network address of the node to be deleted. For example, the network address may include a domain name, Internet Protocol (IP) port, and so on.

In an embodiment, the pre-voting confirmation message may include the consensus state information, identification, and the current master node identification of the node that sent the pre-voting confirmation message. For example, the format of the pre-vote confirmation message may be as follows: pre-vote-ack<consensus_status, leader_id, j>, where consensus_status may indicate the consensus status of the corresponding node, j may indicate the identity of the corresponding node, and leader_id may indicate the identity of the master node.

In one embodiment, the node to be deleted may be the current master node. Then, the foregoing M pre-voting confirmation messages may be sent by M nodes after the blockchain system elects a new master node different from the node to be deleted through the master node election process.

For example, after receiving the pre-voting message of the first node, other nodes find that the node to be deleted is the current master node. In this way, other nodes can initiate the master node election process by reaching a consensus, thereby electing a node different from the node to be deleted as the new master node. After generating new master nodes, these nodes can return a pre-voting confirmation message for the pre-voting message. As a result, it is possible to effectively avoid stability and reliability problems caused by accidentally deleting the master node.

In one embodiment, if most of the pre-voting confirmation messages indicate the master node election status, the first node can determine that the blockchain system is in the master node election process. The majority of pre-voting confirmation messages here can be at least a quorum of pre-voting confirmation messages. Then, it should be understood that the above-mentioned M may be greater than the legal number. In some scenarios, the quorum can be referred to as the quorum quantity. In this article, assume that the quorum is K. The quorum K can be associated with the consensus algorithm used by the blockchain system. For example, in the RAFT algorithm, assuming that there are N nodes in the blockchain system, and there are at most f faulty nodes in the N nodes, the quorum can be f+1. In the PBFT algorithm, assuming that there are at most f problem nodes and f fault nodes in N nodes, the quorum can be 2f+1.

In this way, if at least K of the M pre-voting confirmation messages all indicate the master node election status, the first node can determine that the blockchain system is in the master node election process; and if the M pre-voting confirmation messages The at least K pre-voting confirmation messages in all indicate another consensus state different from the master node election state, and the first node can determine that the blockchain system is not in the master node election process.

It can be seen that by confirming the message based on the pre-voting, it is possible to efficiently determine whether the blockchain system is undergoing a master node election.

Then, in one embodiment, in step 104A, in the case that the blockchain system is not in the master node election process, the first node may send a transaction request to each node. The transaction request can be used to request the execution of a transaction to delete the node to be deleted.

Each node in the blockchain system executes the transaction after reaching a consensus to execute the transaction, so that the node to be deleted is deleted from the blockchain system. For example, after at least a quorum of nodes in the blockchain system reach a consensus to execute a transaction, these nodes will execute the transaction. For example, each node can update configuration information for the node to be deleted, for example, delete the information of the node to be deleted in the configuration information, etc., so that the node to be deleted is deleted from the blockchain system.

In one embodiment, in step 106A, when the blockchain system is in the master node election process, the first node may determine not to send a transaction request for requesting execution of a transaction to delete a node to be deleted to each node. In this way, it is possible to avoid affecting the stability of the blockchain system during the master node election process.

In addition, it can be understood that if the first node still sends a transaction request for deleting the node to be deleted after determining that the blockchain system is electing the master node. At this time, the transaction request will not pass the consensus and therefore will not be executed. In other words, each node in the blockchain system will not execute the transaction when reaching a consensus, so as to avoid affecting the stability of the blockchain system in the master node election process.

In an embodiment, the first node may be a node to be deleted, that is, the first node and the node to be deleted are the same node. At this time, the method shown in FIG. 1A is executed by the node to be deleted.

The node to be deleted (here also the first node) sends another transaction request to each node during or after the pre-voting interaction (for example, after the node to be deleted sends the pre-voting message). The other transaction request is used to request execution of another transaction, which is different from the transaction for deleting the deleted node. At this time, each node may refuse to execute the other transaction after reaching a consensus not to execute the other transaction.

Since the node to be deleted performs pre-voting interaction with each node, the node to be deleted may be deleted, so in addition to the transaction request for deleting the node to be deleted, other transaction requests initiated by the node to be deleted will not be discriminated Nodes in the blockchain system accept. In other words, if the node to be deleted initiates a pre-voting interaction with other nodes, the blockchain system will only accept the transaction request of the node to be deleted to delete itself, and will not accept other types of transaction requests. In this way, the stability and reliability of the blockchain system when a certain node is deleted can be further ensured.

Fig. 1B is a schematic flowchart of a method for node management of a blockchain system according to an embodiment. The method in Figure 1B can be executed by any normal node in the blockchain system. For ease of description, this node is referred to as the second node here. For example, the second node may be a non-Byzantine node.

As shown in Figure 1B, in step 102B, the second node in the blockchain system can perform pre-voting interaction with the first node in the blockchain system to assist the first node in determining whether the blockchain system is the master node During the election process.

In step 104B, if the first node requests to delete the node to be deleted from the blockchain system when the blockchain system is not in the master node election process, the second node executes to make the node to be deleted from the blockchain system The operation that was deleted in.

Among them, if the blockchain system is in the process of master node election, the node to be deleted cannot be deleted from the blockchain system.

It can be seen that in this technical solution, the node to be deleted is deleted from the blockchain system when the blockchain system is not in the master node election process, while the blockchain system is in the master node election process. The nodes to be deleted will not be deleted. In this way, it can effectively avoid the confusion and other problems caused by the deletion of nodes in the master node election process of the blockchain system, thereby ensuring the stability of the blockchain system in the master node election process. And reliability.

In one embodiment, in step 102B, the second node may receive a pre-voting message from the first node. The pre-voting message may include information for identifying the node to be deleted.

The second node may send a pre-voting confirmation message for the pre-voting message to the first node. The pre-voting confirmation message may indicate the consensus status of the second node.

In one embodiment, the pre-voting message may include the identification and network address of the node to be deleted.

In one embodiment, the pre-voting confirmation message may include the consensus status information, identification, and current master node identification of the second node.

The pre-voting message and the pre-voting confirmation message have been described in detail in the embodiment of FIG. 1A above, and will not be repeated here.

In one embodiment, the node to be deleted may be the current master node. In this way, the second node can wait to elect a new master node different from the node to be deleted. After the new master node is generated, the second node may send a pre-voting confirmation message to the first node. For example, after receiving the pre-voting message, the second node finds that the node to be deleted is the current master node. Then, the second node can reach a consensus with other nodes for master node election, thereby electing a new master node. After that, the second node can send a pre-voting confirmation message. As a result, it is possible to effectively avoid stability and reliability problems caused by accidentally deleting the master node.

In one embodiment, in step 104B, the second node receives the transaction request sent by the first node when the blockchain system is not in the master node election process. The transaction request can be used to execute a transaction to delete the node to be deleted.

The second node can execute the transaction after reaching a consensus with other nodes to execute the transaction, so that the node to be deleted is deleted from the blockchain system. For example, the second node may determine that at least a quorum of nodes reach a consensus to execute the transaction. The quorum of nodes may include the second node itself. Then, the second node may execute the transaction, such as updating configuration information for the node to be deleted, so that the node to be deleted is deleted from the blockchain system.

In addition, it is understandable that the second node may receive a transaction request sent by the first node when the blockchain system is in the master node election process. For example, the transaction request is used to request the execution of a transaction to delete the node to be deleted. At this time, the second node and other nodes reach a consensus not to execute the transaction, for example, at least a quorum of nodes reach the consensus. In this way, these nodes will refuse to execute the transaction. Thus, it is possible to avoid deleting nodes during the master node election process, thereby ensuring the stability and reliability of the blockchain system.

In an embodiment, the first node may be a node to be deleted. The second node may receive another transaction request sent by the first node during or after the pre-voting interaction. For example, the second node receives another transaction request sent by the first node after sending the pre-voting message. The another transaction request may be used to request the execution of another transaction, which is different from the transaction for deleting the node to be deleted.

At this time, the second node will reach a consensus with other nodes not to execute the other transaction, and thus refuse to execute the other transaction. In other words, if the node to be deleted initiates a pre-voting interaction with other nodes, the blockchain system will only accept the transaction request of the node to be deleted to delete itself, and will not accept other types of transaction requests. In this way, the stability and reliability of the blockchain system when a certain node is deleted can be further ensured.

In order to facilitate understanding, the following description will be combined with specific examples. It should be understood that the following examples are only intended to help those skilled in the art to better understand the technical solutions in this specification, and are not intended to limit their scope.

In Figure 2, it is assumed that the blockchain system includes nodes R0, R1, R2, and R3, and the node to be deleted is R0. In addition, it is further assumed that the node R0 to be deleted decides to withdraw from the blockchain system. Therefore, the node R0 to be deleted can initiate a pre-voting interaction.

As shown in Figure 2, the node R0 to be deleted can send pre-vote messages to nodes R1, R2, and R3. For example, the pre-vote message may have the following format: pre-vote<identification of R0, network address of R0>.

After the nodes R1, R2, and R3 receive the pre-vote message, they can return the pre-vote-ack message to the node to be deleted. For example, the pre-vote-ack message may have the following format: pre-vote-ack<consensus_status, leader_id, j>.

In one case, as described above, if nodes R1, R2, and R3, after receiving the pre-vote message, find that the node R0 to be deleted is the current master node, a consensus can be reached to conduct the master node election process, thereby electing new Master node. After that, nodes R1, R2, and R3 can send pre-vote-ack messages. For example, this stage is shown in FIG. 2.

If the node to be deleted is not the current master node, the nodes R1, R2, and R3 can directly return the pre-vote-ack message after receiving the pre-vote message.

For node R1, consensus_status can represent the consensus status of node R1, leader_id can represent the current master node ID, and j can represent the ID of node R1.

For node R2, consensus_status can represent the consensus status of node R2, leader_id can represent the current master node ID, and j can represent the ID of node R2.

For node R3, consensus_status can represent the consensus status of node R3, leader_id can represent the current master node ID, and j can represent the ID of node R3.

After receiving 3 pre-vote-ack messages, the node to be deleted determines whether the blockchain system is in the process of master node election.

For example, if two or three of the three pre-vote-ack messages indicate the master node election status, that is, nodes R1, R2, and R3 are electing master nodes, the node R0 to be deleted can determine the zone The blockchain system is in the state of election of the master node. At this time, the node R0 to be deleted may not send a transaction request for requesting execution of the transaction of deleting the node R0. In this way, when the blockchain system is in the master node election state, the node will not be deleted from the blockchain system.

For another example, if two or three of the three pre-vote-ack messages indicate another consensus state in addition to the master node election state, that is, nodes R1, R2, and R3 are not electing the master node. Node, the node R0 to be deleted can determine that the blockchain system is not in the master node election state.

At this time, as shown in Fig. 2, the node R0 to be deleted can send a transaction request to the nodes R1, R2, and R3, and the transaction request is used to request the execution of a transaction to delete the node R0.

Next, the nodes R1, R2, and R3 can all execute the transaction after reaching a consensus to execute the transaction, for example, update configuration information for the node R0. As a result, the node R0 is deleted from the blockchain system.

It should be understood that in the example of Figure 2, in order to simplify the illustration, only three stages of pre-voting, pre-voting confirmation, and transaction request are depicted, and other stages are not shown, but this does not mean that other related stages are not included. stage. For example, if the blockchain system is not in the process of master node election, after the transaction request stage, there is a consensus stage for executing the transaction, a stage for executing the transaction, and so on.

It should be understood that in the technical solution of this specification, a node different from the node to be deleted may initiate the transaction of deleting the node to be deleted. For example, suppose the node to be deleted is R1. Nodes R0, R2, and R3 can reach a consensus to delete node R1 offline, and then convert them into an online contract of the blockchain system through the public key and private key. The node R0 may send a pre-voting message. At this time, the pre-voting message may include the identification and network address of the node R1. Other nodes can return a pre-voting confirmation message. The specific process is similar to the process in FIG. 2 described above, and will not be repeated here.

As shown in FIG. 3A, the node 300A may include an interaction unit 302A and an execution unit 304A.

The interaction unit 302A can perform pre-voting interaction with each node in the blockchain system to determine whether the blockchain system is in the master node election process. In the case that the blockchain system is not in the process of master node election, the execution unit 304A may perform an operation that causes the node to be deleted to be deleted from the blockchain system. In the case that the blockchain system is in the process of master node election, the execution unit 304A may determine not to perform an operation that causes the node to be deleted to be deleted from the blockchain system.

In an embodiment, the interaction unit 302A may send a pre-voting message to each node, where the pre-voting message includes information for identifying the node to be deleted. The interaction unit 302A can receive M pre-voting confirmation messages sent by M nodes in each node for the pre-voting message, where each pre-voting confirmation message indicates the consensus state of the node that sent the pre-voting confirmation message, and M is a positive integer . The interaction unit 302A may determine whether the blockchain system is in the master node election process based on the M pre-voting confirmation messages.

In another embodiment, the node to be deleted may be the current master node. The M pre-voting confirmation messages may be sent by the M nodes after the blockchain system elects a new master node different from the node to be deleted through the master node election process.

In another embodiment, if at least K pre-voting confirmation messages in the M pre-voting confirmation messages all indicate the master node election status, the interaction unit 302A can determine that the blockchain system is in the master node election process, where K It is a quorum determined based on the consensus algorithm used by the blockchain system.

If at least K of the M pre-voting confirmation messages all indicate another consensus state different from the master node election state, the interaction unit 302A can determine that the blockchain system is not in the master node election process.

In another embodiment, the pre-voting message may include the identification and network address of the node to be deleted.

In another embodiment, each pre-voting confirmation message may include consensus state information, identification, and current master node identification of the node that sent the pre-voting confirmation message.

In another embodiment, when the blockchain system is not in the master node election process, the execution unit 304A may send a transaction request to each node, where the transaction request is used to request execution of a transaction to delete the node to be deleted.

Among them, each node executes the transaction after reaching a consensus to execute the transaction, so that the node to be deleted is deleted from the blockchain system.

In another embodiment, when the blockchain system is in the master node election process, the execution unit 304A may determine not to send a transaction request to each node, where the transaction request is used to request execution of a transaction to delete the node to be deleted.

In another embodiment, the node may be a node to be deleted.

The execution unit 304A may also send another transaction request to each node during or after the pre-voting interaction, where the other transaction request is used to request the execution of another transaction, and the other transaction is different from the transaction for deleting the node to be deleted. Among them, each node refuses to execute another transaction after reaching a consensus not to execute another transaction.

In another embodiment, the blockchain system may include a consortium chain system.

Each unit of the device 300A can execute the corresponding steps in the method embodiment of FIG. 1A and FIG.

The foregoing apparatus 300A may be implemented by hardware, software, or a combination of software and hardware. For example, when the device 300A is implemented by software, it can be formed by reading the corresponding executable instructions in the memory (such as non-volatile memory) into the memory by the processor of the device where it is located and running it.

As shown in FIG. 3B, the node 300B in FIG. 3B may include an interaction unit 302B and an execution unit 304B.

The interaction unit 302B may perform pre-voting interaction with the first node in the blockchain system to assist the first node in determining whether the blockchain system is in the master node election process.

If the first node requests to delete the node to be deleted from the blockchain system when the blockchain system is not in the master node election process, the execution unit 304B can execute the process of causing the node to be deleted to be deleted from the blockchain system Operation; Among them, if the blockchain system is in the process of master node election, the node to be deleted cannot be deleted from the blockchain system.

In an embodiment, the interaction unit 302B may receive a pre-voting message from the first node, where the pre-voting message includes information for identifying the node to be deleted. The interaction unit 304B may send a pre-voting confirmation message for the pre-voting message to the first node, where the pre-voting confirmation message indicates the consensus status of the node 300B.

In another embodiment, the node to be deleted may be the current master node. The interaction unit 302B may send a pre-voting confirmation message to the first node after the blockchain system elects a new master node different from the node to be deleted through the master node election process.

In another embodiment, the pre-voting confirmation message may include the consensus status information, identification, and current master node identification of the node 300B.

In another embodiment, the execution unit 304B may receive a transaction request sent by the first node when the blockchain system is not in the master node election process, where the transaction request is used to request execution of a transaction to delete the node to be deleted. The execution unit 304B may execute the transaction after reaching a consensus to execute the transaction with each node in the blockchain system, so that the node to be deleted is deleted from the blockchain system.

In another embodiment, the first node may be a node to be deleted.

The execution unit 304B may also receive another transaction request sent by the first node during or after the pre-voting interaction, where the other transaction request is used to request execution of another transaction, and the other transaction is different from the transaction for deleting the node to be deleted. The execution unit 304B may refuse to execute another transaction after reaching a consensus not to execute another transaction with each node in the blockchain system.

Each unit of the device 300B can execute the corresponding steps in the method embodiment of FIG. 1B and FIG.

The above-mentioned apparatus 300B may be implemented by hardware, software, or a combination of software and hardware. For example, when the device 300B is implemented by software, it can be formed by reading the corresponding executable instructions in the memory (such as non-volatile memory) into the memory by the processor of the device where it is located and running it.

Fig. 4A is a hardware structure diagram of a computing device for node management of a blockchain system according to an embodiment. As shown in FIG. 4A, the computing device 400A may include at least one processor 402A, memory 404A, memory 406A, and communication interface 408A, and at least one processor 402A, memory 404A, memory 406A, and communication interface 408A are connected together via a bus 410A. At least one processor 402A executes at least one executable instruction (that is, the above-mentioned element implemented in the form of software) stored or encoded in the memory 404A.

In one embodiment, the executable instructions stored in the memory 404A, when executed by the at least one processor 402A, enable the computing device to implement the various processes described above in conjunction with FIGS. 1A and 2.

The computing device 400A can be implemented in any suitable form in the art, for example, it includes, but is not limited to, a desktop computer, a laptop computer, a smart phone, a tablet computer, a consumer electronic device, a wearable smart device, and so on.

Fig. 4B is a hardware structure diagram of a computing device for node management of a blockchain system according to an embodiment. As shown in FIG. 4B, the computing device 400B may include at least one processor 402B, memory 404B, memory 406B, and communication interface 408B, and at least one processor 402B, memory 404B, memory 406B, and communication interface 408B are connected together via a bus 410B. At least one processor 402B executes at least one executable instruction (that is, the above-mentioned element implemented in the form of software) stored or encoded in the memory 404B.

In one embodiment, the executable instructions stored in the memory 404B, when executed by the at least one processor 402B, enable the computing device to implement the various processes described above in conjunction with FIGS. 1B and 2.

The computing device 400B can be implemented in any suitable form in the art, for example, it includes but is not limited to a desktop computer, a laptop computer, a smart phone, a tablet computer, a consumer electronic device, a wearable smart device, and so on.

The embodiments of this specification also provide a machine-readable storage medium. The machine-readable storage medium may store executable instructions, and the executable instructions, when executed by the machine, enable the machine to implement the specific process of the method embodiment of the first node described above with reference to FIGS. 1A and 2.

The embodiments of this specification also provide a machine-readable storage medium. The machine-readable storage medium may store executable instructions, and the executable instructions, when executed by the machine, enable the machine to implement the specific process of the method embodiment for the second node described above with reference to FIGS. 1B and 2.

For example, the machine-readable storage medium may include, but is not limited to, random access memory (Random Access Memory, RAM), read-only memory (Read-Only Memory, ROM), and electrically erasable programmable read-only memory (Electrically-Erasable Programmable). Read-Only Memory, EEPROM), Static Random Access Memory (SRAM), hard disk, flash memory, etc.

It should be understood that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on descriptions that are similar to other embodiments. the difference. For example, for the above-mentioned embodiments about the device, the embodiment about the computing device, and the embodiment about the machine-readable storage medium, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant details can be found in the method implementation. Part of the example can be explained.

The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

It should be understood that various modifications to the embodiments in this specification will be obvious to those of ordinary skill in the art, and the definitions defined herein can be changed without departing from the scope of protection of the claims. The general principles apply to other variants.

Claims

A method for node management of a blockchain system includes:

The first node in the blockchain system performs pre-voting interaction with each node in the blockchain system to determine whether the blockchain system is in the master node election process;

In the case that the blockchain system is not in the master node election process, the first node performs an operation that causes the node to be deleted to be deleted from the blockchain system;

In the case that the blockchain system is in the master node election process, the first node determines not to perform an operation that causes the node to be deleted to be deleted from the blockchain system.
The method according to claim 1, wherein the pre-voting interaction between the first node in the blockchain system and each node in the blockchain system comprises:

Sending, by the first node, a pre-voting message to each node, where the pre-voting message includes information for identifying the node to be deleted;

The first node receives M pre-voting confirmation messages sent by the M nodes of the respective nodes for the pre-voting message, wherein each pre-voting confirmation message indicates the consensus state of the node that sent the pre-voting confirmation message , M is a positive integer;

The first node determines whether the blockchain system is in the master node election process based on the M pre-voting confirmation messages.
The method according to claim 2, wherein the node to be deleted is the current master node;

The M pre-voting confirmation messages are sent by the M nodes after the blockchain system elects a new master node different from the node to be deleted through a master node election process.
The method according to claim 2 or 3, wherein the first node determines whether the blockchain system is in the master node election process based on the M pre-voting confirmation messages, comprising:

If at least K of the M pre-voting confirmation messages all indicate the master node election status, the first node determines that the blockchain system is in the master node election process, where K is based on The quorum determined by the consensus algorithm used by the blockchain system;

If at least K of the M pre-voting confirmation messages all indicate another consensus state different from the master node election state, the first node determines that the blockchain system is not in the master node election In the process.
The method according to claim 2 or 3, wherein the pre-voting message includes the identification and network address of the node to be deleted.
The method according to claim 2 or 3, wherein each pre-voting confirmation message includes consensus state information, identification, and current master node identification of the node that sent the pre-voting confirmation message.
The method according to any one of claims 1 to 3, wherein, in the case that the blockchain system is not in the master node election process, the first node executes to make the node to be deleted from the The deleted operations in the blockchain system include:

In the case that the blockchain system is not in the master node election process, the first node sends a transaction request to each node, wherein the transaction request is used to request execution of a transaction to delete the node to be deleted ；

Wherein, each node executes the transaction after reaching a consensus to execute the transaction, so that the node to be deleted is deleted from the blockchain system.
The method according to any one of claims 1 to 3, wherein when the blockchain system is in the master node election process, the first node determines not to execute so that the node to be deleted will be The operations that are deleted in the blockchain system include:

In the case that the blockchain system is in the master node election process, the first node determines not to send a transaction request to each node, wherein the transaction request is used to request the execution of the deletion of the node to be deleted trade.
The method according to any one of claims 1 to 3, wherein the first node is the node to be deleted;

The method also includes:

During or after the pre-voting interaction, the first node sends another transaction request to each node, wherein the another transaction request is used to request the execution of another transaction, and the other transaction corresponds to deleting the The transaction of the node to be deleted is different;

Wherein, the respective nodes refuse to execute the another transaction after reaching a consensus not to execute the another transaction.
The method according to any one of claims 1 to 3, wherein the blockchain system includes a consortium chain system.
A method for node management of a blockchain system includes:

The second node in the blockchain system performs pre-voting interaction with the first node in the blockchain system to assist the first node in determining whether the blockchain system is in the master node election process;

If the first node requests to delete the node to be deleted from the blockchain system when the blockchain system is not in the master node election process, then the second node executes to make the node to be deleted The operation of being deleted from the blockchain system; wherein, if the blockchain system is in the master node election process, the node to be deleted cannot be deleted from the blockchain system.
The method according to claim 11, wherein the pre-voting interaction between the second node in the blockchain system and the first node in the blockchain system comprises:

The second node receives a pre-voting message from the first node, where the pre-voting message includes information for identifying the node to be deleted;

The second node sends a pre-voting confirmation message for the pre-voting message to the first node, wherein the pre-voting confirmation message indicates the consensus state of the second node.
The method according to claim 12, wherein the node to be deleted is the current master node;

The sending by the second node to the first node a pre-voting confirmation message for the pre-voting message includes:

The second node sends the pre-voting confirmation message to the first node after the blockchain system elects a new master node different from the node to be deleted through a master node election process.
The method according to claim 12 or 13, wherein the pre-voting message includes the identification and network address of the node to be deleted.
The method according to claim 12 or 13, wherein the pre-voting confirmation message includes the consensus state information, identification and the current master node identification of the second node.
The method according to any one of claims 11 to 13, wherein the operation performed by the second node to cause the node to be deleted to be deleted from the blockchain system includes:

The second node receives the transaction request sent by the first node when the blockchain system is not in the master node election process, wherein the transaction request is used to request the execution of deleting the node to be deleted trade;

The second node executes the transaction after reaching a consensus to execute the transaction with each node in the blockchain system, so that the node to be deleted is deleted from the blockchain system.
The method according to any one of claims 11 to 13, wherein the first node is the node to be deleted;

The method also includes:

The second node receives another transaction request sent by the first node during or after the pre-voting interaction, wherein the another transaction request is used to request execution of another transaction, and the other transaction The transaction of the node to be deleted is different;

The second node refuses to execute the another transaction after reaching a consensus with each node in the blockchain system not to execute the another transaction.
The method according to any one of claims 11 to 13, wherein the blockchain system includes a consortium chain system.
A node in a blockchain system, including:

The interaction unit is used for pre-voting interaction with each node in the blockchain system to determine whether the blockchain system is in the master node election process;

Execution unit for:

In the case that the blockchain system is not in the master node election process, perform an operation that causes the node to be deleted to be deleted from the blockchain system;

In the case that the blockchain system is in the master node election process, it is determined not to perform an operation that causes the node to be deleted to be deleted from the blockchain system.
The node according to claim 19, wherein the interaction unit is specifically configured to:

Sending a pre-voting message to each node, where the pre-voting message includes information for identifying the node to be deleted;

Receive M pre-voting confirmation messages sent by M nodes in the respective nodes for the pre-voting message, where each pre-voting confirmation message indicates the consensus state of the node that sent the pre-voting confirmation message, and M is a positive integer ；

Based on the M pre-voting confirmation messages, it is determined whether the blockchain system is in the master node election process.
The node according to claim 20, wherein the node to be deleted is the current master node;

The M pre-voting confirmation messages are sent by the M nodes after the blockchain system elects a new master node different from the node to be deleted through a master node election process.
The node according to claim 20 or 21, wherein the interaction unit is specifically configured to:

If at least K of the M pre-voting confirmation messages all indicate the master node election status, it is determined that the blockchain system is in the master node election process, where K is based on the blockchain A quorum determined by the consensus algorithm used by the system;

If at least K of the M pre-voting confirmation messages all indicate another consensus state different from the master node election state, it is determined that the blockchain system is not in the master node election process.
The node according to claim 20 or 21, wherein the pre-voting message includes the identification and network address of the node to be deleted.
The node according to claim 20 or 21, wherein each pre-voting confirmation message includes consensus state information, identification, and current master node identification of the node that sent the pre-voting confirmation message.
The node according to any one of claims 19 to 21, wherein the execution unit is specifically configured to:

In the case that the blockchain system is not in the master node election process, sending a transaction request to each node, where the transaction request is used to request execution of a transaction to delete the node to be deleted;

Wherein, each node executes the transaction after reaching a consensus to execute the transaction, so that the node to be deleted is deleted from the blockchain system.
The node according to any one of claims 19 to 21, wherein the execution unit is specifically configured to:

In the case that the blockchain system is in the master node election process, it is determined not to send a transaction request to each node, wherein the transaction request is used to request execution of a transaction to delete the node to be deleted.
The node according to any one of claims 19 to 21, wherein the node is the node to be deleted;

The execution unit is also used for:

During or after the pre-voting interaction, another transaction request is sent to each node, wherein the another transaction request is used to request the execution of another transaction, and the other transaction is the same as the transaction for deleting the node to be deleted different;

Wherein, the respective nodes refuse to execute the another transaction after reaching a consensus not to execute the another transaction.
The node according to any one of claims 19 to 21, wherein the blockchain system includes a consortium chain system.
A node in a blockchain system, including:

The interaction unit is configured to perform pre-voting interaction with the first node in the blockchain system to assist the first node in determining whether the blockchain system is in the master node election process;

The execution unit is configured to: if the first node requests the deletion of the node to be deleted from the blockchain system when the blockchain system is not in the master node election process, execute so that the to-be-deleted node The operation of deleting a node from the blockchain system; wherein, if the blockchain system is in the master node election process, the node to be deleted cannot be deleted from the blockchain system.
The node according to claim 29, wherein the interaction unit is specifically configured to:

Receiving a pre-voting message from the first node, where the pre-voting message includes information for identifying the node to be deleted;

Sending a pre-voting confirmation message for the pre-voting message to the first node, wherein the pre-voting confirmation message indicates the consensus state of the node.
The node according to claim 30, wherein the node to be deleted is the current master node;

The interaction unit is specifically used for:

After the blockchain system elects a new master node different from the node to be deleted through a master node election process, the blockchain system sends the pre-voting confirmation message to the first node.
The node according to claim 30 or 31, wherein the pre-voting message includes the identification and network address of the node to be deleted.
The node according to claim 30 or 31, wherein the pre-voting confirmation message includes consensus state information, identification, and current master node identification of the node.
The node according to any one of claims 29 to 31, wherein the execution unit is specifically configured to:

Receiving a transaction request sent by the first node when the blockchain system is not in the master node election process, where the transaction request is used to request execution of a transaction to delete the node to be deleted;

The transaction is executed after reaching a consensus to execute the transaction with each node in the blockchain system, so that the node to be deleted is deleted from the blockchain system.
The node according to any one of claims 29 to 31, wherein the first node is the node to be deleted;

The execution unit is also used for:

Receive another transaction request sent by the first node during or after the pre-voting interaction, wherein the another transaction request is used to request the execution of another transaction, and the other transaction is related to the deletion of the node to be deleted The transaction is different;

After reaching a consensus not to execute the other transaction with each node in the blockchain system, refuse to execute the other transaction.
The node according to any one of claims 29 to 31, wherein the blockchain system includes a consortium chain system.
A computing device including:

At least one processor;

The memory in communication with the at least one processor has executable instructions stored thereon, and when the executable instructions are executed by the at least one processor, the at least one processor realizes the Any of the methods.
A computing device including:

At least one processor;

The memory in communication with the at least one processor has executable instructions stored thereon, and when the executable instructions are executed by the at least one processor, the at least one processor realizes the Any of the methods.