CN111049696A - Method, node and computing device for node management of blockchain system - Google Patents
Method, node and computing device for node management of blockchain system Download PDFInfo
- Publication number
- CN111049696A CN111049696A CN202010181765.5A CN202010181765A CN111049696A CN 111049696 A CN111049696 A CN 111049696A CN 202010181765 A CN202010181765 A CN 202010181765A CN 111049696 A CN111049696 A CN 111049696A
- Authority
- CN
- China
- Prior art keywords
- node
- blockchain system
- deleted
- transaction
- vote
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 173
- 230000008569 process Effects 0.000 claims abstract description 126
- 230000003993 interaction Effects 0.000 claims abstract description 50
- 238000012790 confirmation Methods 0.000 claims description 71
- 238000004891 communication Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 14
- 238000012217 deletion Methods 0.000 description 12
- 230000037430 deletion Effects 0.000 description 12
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Embodiments of the present specification provide methods, nodes and computing devices for node management for blockchain systems. The method comprises the following steps: carrying out pre-vote interaction on a first node in the blockchain system and each node in the blockchain system to determine whether the blockchain system is in the process of electing the main node; under the condition that the blockchain system is not in the process of electing the main node, the first node executes the operation of deleting the node to be deleted from the blockchain system; in the case where the blockchain system is in the process of master node election, the first node determines not to perform an operation of causing the node to be deleted from the blockchain system.
Description
Technical Field
Embodiments of the present description relate to the field of blockchain technology, and more particularly, to a method, node, and computing device for node management of a blockchain system.
Background
The blockchain technique, also referred to as a distributed ledger technique, is an emerging technology for a number of computing devices (also referred to herein as nodes) to participate together in "accounting" and to maintain a complete distributed database. Due to the characteristics of decentralization, transparency and non-tampering, the blockchain technology has been widely applied in many fields.
Disclosure of Invention
In view of the above-identified problems of the prior art, embodiments of the present specification provide a method, node, and computing device for node management of a blockchain system.
In one aspect, an embodiment of the present specification provides a method for node management of a blockchain system, including: carrying out pre-vote interaction on a first node in a blockchain system and each node in the blockchain system to determine whether the blockchain system is in a main node election process; in the case that the blockchain system is not in the process of master node election, the first node executes an operation of deleting the node to be deleted from the blockchain system; in a case where the blockchain system is in the process of master node election, the first node determines not to perform an operation of causing the node to be deleted from the blockchain system.
In another aspect, an embodiment of the present specification provides a method for node management of a blockchain system, including: a second node in the blockchain system performs pre-vote interaction with a first node in the blockchain system to assist the first node in determining whether the blockchain system is in a master node election process; if the first node requests to delete a node to be deleted from the blockchain system without the blockchain system being in the process of master node election, the second node performs an operation of causing the node to be deleted from the blockchain system; and if the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
In another aspect, an embodiment of the present specification provides a node in a blockchain system, including: the interaction unit is used for carrying out pre-vote interaction with each node in the blockchain system so as to determine whether the blockchain system is in the process of electing the main node; an execution unit to: executing an operation of causing a node to be deleted from the blockchain system in the case that the blockchain system is not in the process of master node election; determining not to perform an operation of causing the node to be deleted from the blockchain system if the blockchain system is in the process of master node election.
In another aspect, an embodiment of the present specification provides a node in a blockchain system, including: the interaction unit is used for carrying out pre-vote interaction with a first node in the blockchain system so as to assist the first node in determining whether the blockchain system is in the process of main node election; an execution unit to: if the first node requests to delete a node to be deleted from the blockchain system under the condition that the blockchain system is not in the process of main node election, performing an operation of enabling the node to be deleted from the blockchain system; and if the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
Therefore, in the technical scheme, the operation of deleting the node to be deleted from the blockchain system can be executed under the condition that the blockchain system is not in the process of electing the main node, and the corresponding deleting operation is determined not to be executed under the condition that the blockchain system is in the process of electing the main node. Therefore, the problem of confusion and the like caused by node deletion in the main node election process of the block chain system can be effectively avoided, and the stability and the reliability of the block chain system in the main node election process are ensured.
Drawings
The foregoing and other objects, features and advantages of the embodiments of the present specification will become more apparent from the following more particular description of the embodiments of the present specification, as illustrated in the accompanying drawings in which like reference characters generally represent like elements throughout.
Fig. 1A is a schematic flow chart diagram of a method for node management of a blockchain system according to one embodiment.
Fig. 1B is a schematic flow chart diagram of a method for node management of a blockchain system according to one embodiment.
FIG. 2 is an interaction diagram of one scenario for node management in a blockchain system.
Fig. 3A is a schematic block diagram of a node in a blockchain system according to one embodiment.
Fig. 3B is a schematic block diagram of a node in a blockchain system in accordance with one embodiment.
Fig. 4A is a hardware block diagram of a computing device for node management of a blockchain system according to one embodiment.
Fig. 4B is a hardware block diagram of a computing device for node management of a blockchain system, according to one embodiment.
Detailed Description
The subject matter described herein will now be discussed with reference to various embodiments. It should be understood that these examples are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the claims. Various embodiments may omit, replace, or add various procedures or components as desired.
A blockchain system formed based on blockchain techniques may include a plurality of nodes. Among the plurality of nodes, one node may be elected as a master node, and the other nodes may be slave nodes. The master node may be responsible for initiating a transaction consensus and may be responsible for creating the latest tile for the blockchain based on the transaction data passed by the consensus.
The master node may be dynamically generated according to different situations. For example, before the blockchain system performs the consensus process, the master node may be first elected from each node. For another example, when the master node and the slave node cannot communicate due to network delay, master node failure, or the like, a new master node may be reselected. As another example, when most nodes consider the master node as a rogue node (e.g., sending spurious data or erroneous data, etc.), a new master node may be reselected.
The mechanism for electing the master node may be different based on the consensus algorithm employed by the blockchain system. For example, in the present specification, the block chain system may employ various applicable consensus algorithms such as RAFT algorithm, PBFT (physical Byzantine fault tolerance) algorithm, and the like.
No matter what kind of consensus algorithm is based, the master node election process needs a certain time to complete. During this process, if other operations are performed simultaneously, bandwidth may be occupied, time-outs may occur, etc., which may affect the stability of the entire blockchain system. For example, if a node is removed from the blockchain system during the election of the master node, and the node may still participate in the consensus process, this may cause the message mechanism of the blockchain system to be confused, thereby seriously affecting the reliability and stability of the whole blockchain system.
In view of this, in this specification, a first node in the blockchain system may perform pre-vote interactions with various nodes to determine whether the blockchain system is in the process of master node election. In the case where the blockchain system is not in the process of master node election, the first node may perform an operation that causes the node to be deleted from the blockchain system. In the case where the blockchain system is in the process of master node election, the first node may determine not to perform an operation of causing the node to be deleted from the blockchain system.
Therefore, in the technical scheme, the operation of deleting the node to be deleted from the blockchain system can be executed under the condition that the blockchain system is not in the process of electing the main node, and the corresponding deleting operation is determined not to be executed under the condition that the blockchain system is in the process of electing the main node. Therefore, the problem of confusion and the like caused by node deletion in the main node election process of the block chain system can be effectively avoided, and the stability and the reliability of the block chain system in the main node election process are ensured.
In this specification, the blockchain system may include a public chain system, a private chain system, or a federation chain system.
For example, in one scenario, the blockchain system may be a federation chain system consisting of servers of third party payment platforms, domestic bank servers, overseas bank servers, and a number of user nodes as members. An operator of the federation chain can rely on the federation chain to deploy online services such as federation chain-based cross-border transfers, asset transfers, and the like online.
However, in consideration of the node scale of the public link system, the private link system, and the deployment of the federation link system, the technical solution of the present specification will produce better effects in the federation link system or the private link system, but the technical solution of the present specification is also applicable to the public link system.
The technical solutions in the present specification will be described below with reference to specific embodiments.
Fig. 1A is a schematic flow chart diagram of a method for node management of a blockchain system according to one embodiment.
As shown in fig. 1A, in step 102A, a first node in the blockchain system may perform a pre-vote interaction with various nodes in the blockchain system to determine whether the blockchain system is in the process of a master node election.
In step 104A, in the case that the blockchain system is not in the process of master node election, the first node may perform an operation that causes the node to be deleted from the blockchain system.
In step 106A, in the case that the blockchain system is in the process of master node election, the first node may determine not to perform an operation that causes the node to be deleted from the blockchain system.
Therefore, in the technical scheme, the operation of deleting the node to be deleted from the blockchain system can be executed under the condition that the blockchain system is not in the process of electing the main node, and the corresponding deleting operation is determined not to be executed under the condition that the blockchain system is in the process of electing the main node. Therefore, the problems of confusion and the like caused by node deletion in the main node election process of the block chain system can be effectively avoided, and the stability and the reliability of the block chain system in the main node election process are ensured.
In this specification, a node to be deleted may be any node in the blockchain system. The node may be deleted from the blockchain system for various reasons. For example, if the node needs to exit the blockchain system for its own reasons (e.g., resource limitations, management issues, etc.), the node may be deleted from the blockchain system. As another example, if the node fails to communicate with other nodes due to some failure, the node may be removed from the blockchain system. As another example, if the node is a rogue node (e.g., sending a false message or error message), the node may be deleted from the blockchain system.
For example, the delete node operation may be initiated by the node to be deleted itself. At this time, the 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 delete node operation may also be initiated by a node in the blockchain system other than the node to be deleted. For example, most nodes in a blockchain system may agree offline to the need to delete a node. For example, most nodes consider a node to be faulty or a rogue node, and therefore need to be deleted. The agreed upon node may then translate the consensus that the node needs to be deleted offline into an online contract for the blockchain system. This process may be accomplished using a public key and a private key. In this case, the first node may be a different node 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 (pre-vote) message to the various nodes. The pre-vote message may include information identifying the node to be deleted.
For example, the first node may broadcast a pre-vote message to the various nodes. For another example, the first node may send a pre-vote message to a neighboring node, and then the neighboring node may forward the pre-vote message to other nodes, so that each node in the blockchain system receives the pre-vote message through a forwarding mechanism. The first node may also send the pre-vote message by using other suitable communication methods, which are not limited in this specification.
The first node may then receive a pre-vote confirmation (pre-vote-ack) message sent by the respective node for the pre-vote message. For example, the first node may receive M pre-vote confirmation messages sent by M nodes. M is a positive integer.
In one case, the first node may receive a pre-vote confirmation message sent by all other nodes in the blockchain system. At this time, M is equal to the total number of nodes in the blockchain system minus 1.
In another case, the first node may not receive the pre-vote confirmation messages sent by all other nodes for various reasons (e.g., network delay, node failure, etc.). At this time, M may be smaller than the value obtained by subtracting 1 from the total number of nodes in the blockchain system.
The pre-vote confirmation message may indicate a consensus status of the node that sent the pre-vote confirmation message. For example, the consensus state may include a master node election state, a synchronization state, a normal processing state, an initialization state, and so on.
In this way, the first node can determine whether the blockchain system is in the process of election by the master node based on the received M pre-vote confirmation messages.
Therefore, in the embodiment, through interaction of the pre-vote message and the pre-vote confirmation message, whether the blockchain system is electing the main node or not can be efficiently determined, so that the first node is assisted to judge whether the operation of deleting the node can be executed or not, and the influence on the stability of the blockchain system in the election process of the main node can be avoided.
In one embodiment, the pre-vote message may include an identification of the node to be deleted and a network address. For example, the format of the pre-vote message may be as follows: pre-vote < i, address >, wherein i represents the identifier 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, an Internet Protocol (IP) port, and the like.
In one embodiment, the pre-vote confirmation message may include consensus status information, an identification of the node that sent the pre-vote confirmation message, and a current master node identification. For example, the format of the pre-vote confirmation message may be as follows: pre-volume-ack < consensus _ status, leader _ id, j >, wherein the consensus _ status may represent a consensus state of the corresponding node, j may represent an identity of the corresponding node, and leader _ id may represent a host node identity.
In one embodiment, the node to be deleted may be the current master node. Then, the M pre-vote 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.
For example, after receiving the pre-vote message of the first node, the other nodes find that the node to be deleted is the current master node. In this way, other nodes may initiate a master node election process by reaching consensus, thereby electing a node different from the node to be deleted as the new master node. After the new master node is generated, the nodes may return a pre-vote confirmation message for the pre-vote message. Therefore, the problems of stability and reliability caused by mistaken deletion of the main node can be effectively solved.
In one embodiment, the first node may determine that the blockchain system is in the process of master node election if most of the pre-vote confirmation messages indicate master node election status. Most of the pre-vote confirmation messages herein may be at least a quorum of pre-vote confirmation messages. It should be understood, then, that M above can be greater than the legal number. In some scenarios, the quorum may be referred to as a quorum number. In this context, it is assumed that the legal number is K. The quorum K may be associated with a 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 a maximum of f failed nodes in the N nodes, the quorum may be f + 1. In the PBFT algorithm, the quorum may be 2f +1, assuming that there are at most f problem nodes and f failed nodes from the N nodes.
Thus, if at least K of the M pre-vote confirmation messages indicate the election state of the master node, the first node may determine that the blockchain system is in the process of the election of the master node; and if at least K of the M pre-vote confirmation messages all indicate another consensus state different from the master node election state, the first node may determine that the blockchain system is not in the master node election process.
It can be seen that by basing the pre-vote confirmation message, it can be efficiently determined whether the blockchain system is conducting a master node election.
Then, in one embodiment, in step 104A, the first node may send a transaction request to the respective nodes without the blockchain system being in the process of master node election. The transaction request may be for requesting execution of a transaction to delete a node to be deleted.
Each node in the blockchain system performs the transaction after reaching a consensus to perform the transaction, such 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 agree to execute a transaction, those nodes will execute the transaction. For example, each node may update configuration information for the node to be deleted, for example, delete information of the node to be deleted in the configuration information, so that the node to be deleted is deleted from the blockchain system.
In one embodiment, in step 106A, in the case that the blockchain system is in the process of master node election, the first node may determine not to send a transaction request to each node for requesting execution of a transaction to delete the node to be deleted. Therefore, the stability of the block chain system in the master node election process can be prevented from being influenced.
Further, it will be appreciated that if the first node still sends a transaction request for deletion of a node to be deleted after determining that the blockchain system is conducting a master node election. At this point, the transaction request will not pass consensus and thus will not be executed. That is, each node in the blockchain system will not execute the transaction in reaching the consensus, thereby avoiding affecting the stability of the blockchain system during the master node election process.
In one 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 illustrated in fig. 1A is performed by the node to be deleted.
The node to be deleted (also the first node here) sends another transaction request to the respective nodes during or after the pre-vote interaction is made (e.g., after the node to be deleted sends the pre-vote message). The another transaction request is for requesting execution of another transaction that is different from the transaction that deleted the deletion node. At this point, each node may refuse to execute the other transaction after reaching a consensus that the other transaction is not to be executed.
Since the node to be deleted performs pre-vote interaction with each node, the node to be deleted may be deleted, and other transaction requests initiated by the node to be deleted will not be accepted by the nodes in the blockchain system except the transaction request for deleting the node to be deleted. That is, if the node to be deleted initiates a pre-vote interaction with other nodes, the blockchain system will accept only the transaction request of the node to be deleted to delete itself, and not other types of transaction requests. In this way, the stability and reliability of the blockchain system can be further ensured when a certain node is deleted.
Fig. 1B is a schematic flow chart diagram of a method for node management of a blockchain system according to one embodiment. The method of fig. 1B may be performed by any normal node in the blockchain system. For ease of description, this node will be referred to herein as the second node. For example, the second node may be a non-byzantine node.
As shown in fig. 1B, in step 102B, a second node in the blockchain system may perform a pre-vote interaction with a first node in the blockchain system to assist the first node in determining whether the blockchain system is in the process of master node election.
In step 104B, if the first node requests deletion of a node to be deleted from the blockchain system in a case where the blockchain system is not in the process of master node election, the second node performs an operation such that the node to be deleted is deleted from the blockchain system.
If the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
Therefore, in the technical scheme, the node to be deleted is deleted from the blockchain system under the condition that the blockchain system is not in the process of selecting the main node, and the node to be deleted is not deleted under the condition that the blockchain system is in the process of selecting the main node, so that the problems of confusion and the like caused by node deletion in the process of selecting the main node of the blockchain system can be effectively avoided, and the stability and the reliability of the blockchain system in the process of selecting the main node are ensured.
In one embodiment, in step 102B, the second node may receive a pre-vote message from the first node. The pre-vote message may include information identifying the node to be deleted.
The second node may send a pre-vote confirmation message for the pre-vote message to the first node. The pre-vote confirmation message may indicate a consensus status of the second node.
In one embodiment, the pre-vote message may include an identification of the node to be deleted and a network address.
In one embodiment, the pre-vote confirmation message may include consensus status information, identification of the second node, and the current master node identification.
The pre-vote message and the pre-vote confirmation message have been described in detail above in the embodiment of fig. 1A, and will not be described herein again.
In one embodiment, the node to be deleted may be the current master node. In this way, the second node may wait to elect a new master node that is different from the node to be deleted. After generating the new master node, the second node may send a pre-vote confirmation message to the first node. For example, the second node finds that the node to be deleted is the current master node after receiving the pre-voting message. The second node may then agree with other nodes to perform a master node election, resulting in a new master node. Thereafter, the second node may send a pre-vote confirmation message. Therefore, the problems of stability and reliability caused by mistaken deletion of the main node can be effectively avoided.
In one embodiment, in step 104B, the second node receives a transaction request sent by the first node if the blockchain system is not in the process of master node election. The transaction request may be for performing a transaction to delete a node to be deleted.
The second node may execute the transaction after reaching consensus for executing the transaction with other nodes such 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 the nodes agree to perform the transaction. The quorum of nodes may include the second node itself. The second node may then perform the transaction, such as updating configuration information for the node to be deleted, causing the node to be deleted from the blockchain system.
Furthermore, it is understood that the second node may receive a transaction request sent by the first node when the blockchain system is in the process of the master node election, for example, the transaction request is used for requesting to execute a transaction for deleting the node to be deleted. At this point, the second node agrees with other nodes not to perform the transaction, e.g., at least a quorum of the nodes agree. Thus, the nodes refuse to execute the transaction. Therefore, nodes can be prevented from being deleted in the process of electing the main node, and the stability and reliability of the block chain system can be ensured.
In one 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 further transaction request may be for requesting execution of a further transaction, the further transaction being different from the transaction for deleting the node to be deleted.
At this point, the second node will agree with other nodes not to perform the further transaction, thereby denying performance of the further transaction. That is, if the node to be deleted initiates a pre-vote interaction with other nodes, the blockchain system will accept only the transaction request of the node to be deleted to delete itself, and not other types of transaction requests. In this way, the stability and reliability of the blockchain system can be further ensured when a certain node is deleted.
For ease of understanding, the following description will be made in conjunction with specific examples. It should be understood that the following examples are intended only to help those skilled in the art better understand the technical solutions in the present specification, and are not intended to limit the scope thereof.
FIG. 2 is an interaction diagram of one scenario for node management in a blockchain system.
In fig. 2, it is assumed that the blockchain system includes nodes R0, R1, R2, and R3, where the node to be deleted is R0. Additionally, further assume that the to-be-deleted node R0 itself decides to exit the blockchain system, whereby the to-be-deleted node R0 may initiate a pre-vote interaction.
As shown in fig. 2, the node to be deleted R0 may send a pre-vote message to the 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 >.
The nodes R1, R2, and R3 may return a pre-vote-ack message to the node to be deleted after receiving the pre-vote message. For example, the pre-vote-ack message may have the following format: pre-volume-ack < preferences _ status, leader _ id, j >.
In one case, as described above, if nodes R1, R2, and R3 find that node R0 to be deleted is the current master node after receiving the pre-vote message, a consensus may be reached to conduct the master node election process, whereby election results in a new master node. Thereafter, nodes R1, R2, and R3 may send pre-vote-ack messages. This stage is shown, for example, in fig. 2.
If the node to be deleted is not the current master node, the nodes R1, R2, and R3 may return the pre-vote-ack message directly after receiving the pre-vote message.
For node R1, the consensus _ status may represent the consensus status of node R1, the leader _ id may represent the current master node identity, and j may represent the identity of node R1.
For node R2, the consensus _ status may represent the consensus status of node R2, the leader _ id may represent the current master node identity, and j may represent the identity of node R2.
For node R3, the consensus _ status may represent the consensus status of node R3, the leader _ id may represent the current master node identity, and j may represent the identity 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 2 or 3 of the 3 pre-vote-ack messages all indicate a master node election state, that is, nodes R1, R2, and R3 are electing a master node, then node to be deleted R0 may determine that the blockchain system is in a master node election state. At this time, the node to be deleted R0 may not send a transaction request for requesting execution of a transaction of the delete node R0. Thus, nodes will not be deleted from the blockchain system when the blockchain system is in the master node election state.
As another example, if 2 or 3 of the 3 pre-vote-ack messages all indicate another consensus state other than the master node election state, that is, nodes R1, R2, and R3 are not at the election master node, then the to-be-deleted node R0 may determine that the blockchain system is not at the master node election state.
At this time, as shown in fig. 2, the node to be deleted R0 may send a transaction request for requesting execution of a transaction to delete the node R0 to the nodes R1, R2 and R3.
Next, the nodes R1, R2, and R3 may all execute the transaction after reaching consensus to execute the transaction, e.g., update configuration information for node R0. Thereby causing node R0 to be removed from the blockchain system.
It should be understood that in the example of fig. 2, only three phases of pre-voting, pre-vote confirmation, and transaction request are depicted for simplicity of illustration, and other phases are not shown, but this is not meant to imply that other related phases are not included. For example, if the blockchain system is not in the process of master node election, after this phase of transaction request, there are a consensus phase for performing transactions and a phase for performing transactions, etc.
It should be understood that, in the technical solution of the present specification, the transaction of deleting the node to be deleted may be initiated by a node different from the node to be deleted. For example, assume that the node to be deleted is R1. The nodes R0, R2, and R3 may achieve consensus to delete node R1 offline, and then convert to an online contract for blockchain system through public and private keys. Node R0 may send a pre-vote message, which at this point may include the identity and network address of node R1. Other nodes may return pre-vote confirmation messages. The specific process is similar to the process of fig. 2, and is not described here again.
Therefore, in the technical scheme, the operation of deleting the node to be deleted from the blockchain system can be executed under the condition that the blockchain system is not in the process of electing the main node, and the corresponding deleting operation is determined not to be executed under the condition that the blockchain system is in the process of electing the main node. Therefore, the problems of confusion and the like caused by node deletion in the main node election process of the block chain system can be effectively avoided, and the stability and the reliability of the block chain system in the main node election process are ensured.
Fig. 3A is a schematic block diagram of a node in a blockchain system according to one embodiment.
As shown in fig. 3A, node 300A may include an interaction unit 302A and an execution unit 304A.
Interaction unit 302A may perform pre-vote interactions with various nodes in the blockchain system 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 process of master node election, the execution unit 304A may perform an operation that causes the node to be deleted from the blockchain system. In a case where the blockchain system is in the process of master node election, the execution unit 304A may determine not to perform an operation of causing the node to be deleted from the blockchain system.
Therefore, in the technical scheme, the operation of deleting the node to be deleted from the blockchain system can be executed under the condition that the blockchain system is not in the process of electing the main node, and the corresponding deleting operation is determined not to be executed under the condition that the blockchain system is in the process of electing the main node. Therefore, the problems of confusion and the like caused by node deletion in the main node election process of the block chain system can be effectively avoided, and the stability and the reliability of the block chain system in the main node election process are ensured.
In one embodiment, the interaction unit 302A may send a pre-vote message to each node, where the pre-vote message includes information identifying the node to be deleted. The interaction unit 302A may receive M pre-vote confirmation messages transmitted by M nodes of the respective nodes for the pre-vote messages, where each pre-vote confirmation message indicates a consensus state of the node transmitting the pre-vote confirmation message, and M is a positive integer. The interaction unit 302A may determine whether the blockchain system is in the process of election by the master node based on the M pre-vote confirmation messages.
In another embodiment, the node to be deleted may be the current master node. The M pre-vote 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-vote confirmation messages of the M pre-vote confirmation messages indicate the master node election status, the interaction unit 302A may determine that the blockchain system is in the master node election process, where K is a legal number determined based on the consensus algorithm used by the blockchain system.
If at least K of the M pre-vote confirmation messages all indicate another consensus state different from the master node election state, the interaction unit 302A may determine that the blockchain system is not in the master node election process.
In another embodiment, the pre-vote message may include an identification of the node to be deleted and a network address.
In another embodiment, each pre-vote confirmation message may include consensus status information, an identification of the node that sent the pre-vote confirmation message, and a current master node identification.
In another embodiment, in a case that the blockchain system is not in the process of electing the master node, the executing unit 304A may send a transaction request to each node, where the transaction request is used for requesting to execute a transaction for deleting the node to be deleted.
And executing the transaction after the nodes achieve the consensus of executing the transaction, so that the node to be deleted is deleted from the blockchain system.
In another embodiment, in a case that the blockchain system is in the process of electing the master node, the executing unit 304A may determine not to send a transaction request to each node, where the transaction request is used for requesting to execute a transaction for deleting a 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-vote interaction, where the another transaction request is for requesting execution of another transaction, which is different from the transaction for deleting the node to be deleted. Wherein each node refuses to execute another transaction after reaching a consensus that another transaction is not to be executed.
In another embodiment, the blockchain system may comprise a federation chain system.
The units of the apparatus 300A may perform corresponding steps in the method embodiments of fig. 1A and fig. 2, and therefore, for brevity of description, specific operations and functions of the units of the apparatus 300A are not described herein again.
The apparatus 300A may be implemented by hardware, software, or a combination of hardware and software. For example, when implemented in software, the apparatus 300A may be formed by a processor of a device that reads corresponding executable instructions from a memory (e.g., a non-volatile memory) into the memory for execution.
Fig. 3B is a schematic block diagram of a node in a blockchain system in accordance with one embodiment.
As shown in fig. 3B, the node 300B of fig. 3B may include an interaction unit 302B and an execution unit 304B.
Interaction unit 302B may perform a pre-vote interaction with a first node in the blockchain system to assist the first node in determining whether the blockchain system is in the process of election by the master node.
If the first node requests to delete a node to be deleted from the blockchain system in a case where the blockchain system is not in the process of the master node election, the execution unit 304B may perform an operation of causing the node to be deleted from the blockchain system; if the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
Therefore, in the technical scheme, the node to be deleted is deleted from the blockchain system under the condition that the blockchain system is not in the process of selecting the main node, and the node to be deleted is not deleted under the condition that the blockchain system is in the process of selecting the main node, so that the problems of confusion and the like caused by node deletion in the process of selecting the main node of the blockchain system can be effectively avoided, and the stability and the reliability of the blockchain system in the process of selecting the main node are ensured.
In one embodiment, the interaction unit 302B may receive a pre-vote message from the first node, wherein the pre-vote message includes information identifying the node to be deleted. The interaction unit 304B may send a pre-vote confirmation message for the pre-vote message to the first node, wherein the pre-vote 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 interacting 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-vote message may include an identification of the node to be deleted and a network address.
In another embodiment, the pre-vote confirmation message may include consensus status information, identification of node 300B, and the current master node identification.
In another embodiment, the execution unit 304B may receive a transaction request sent by the first node in a case that the blockchain system is not in the process of the master node election, wherein the transaction request is used for requesting to execute a transaction for deleting 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, such 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 another transaction request is used to request to execute another transaction, and the another 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 with each node in the blockchain system that another transaction is not to be executed.
In another embodiment, the blockchain system may comprise a federation chain system.
The units of the apparatus 300B may perform corresponding steps in the method embodiments of fig. 1B and fig. 2, and therefore, for brevity of description, specific operations and functions of the units of the apparatus 300B are not described herein again.
The apparatus 300B may be implemented by hardware, software, or a combination of hardware and software. For example, when implemented in software, the apparatus 300B may be formed by a processor of a device that reads corresponding executable instructions from a memory (e.g., a non-volatile memory) into the memory for execution.
Fig. 4A is a hardware block diagram of a computing device for node management of a blockchain system according to one embodiment. As shown in fig. 4A, computing device 400A may include at least one processor 402A, storage 404A, memory 406A, and communication interface 408A, and the at least one processor 402A, storage 404A, memory 406A, and communication interface 408A are connected together via a bus 410A. The at least one processor 402A executes at least one executable instruction (i.e., the elements described above as being implemented in software) stored or encoded in the memory 404A.
In one embodiment, executable instructions stored in the memory 404A, when executed by the at least one processor 402A, cause the computing device to implement the various processes described above in connection with fig. 1A and 2.
Fig. 4B is a hardware block diagram of a computing device for node management of a blockchain system, according to one embodiment. As shown in fig. 4B, computing device 400B may include at least one processor 402B, storage 404B, memory 406B, and communication interface 408B, and the at least one processor 402B, storage 404B, memory 406B, and communication interface 408B are connected together via a bus 410B. The at least one processor 402B executes at least one executable instruction (i.e., an element implemented in software as described above) 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, cause the computing device to implement the various processes described above in connection with fig. 1B and 2.
Embodiments of the present specification also provide a machine-readable storage medium. The machine-readable storage medium may store executable instructions that, when executed by a machine, cause the machine to perform particular processes of the method embodiments described above with reference to fig. 1A and 2 with respect to the first node.
Embodiments of the present specification also provide a machine-readable storage medium. The machine-readable storage medium may store executable instructions that, when executed by a machine, cause the machine to perform particular processes of the method embodiments described above with reference to fig. 1B and 2 with respect to the second node.
For example, a machine-readable storage medium may include, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Static Random Access Memory (SRAM), a hard disk, flash Memory, and so forth.
It should be understood that the embodiments in this specification are described in a progressive manner, and that the same or similar parts in the various embodiments may be mutually referred to, and each embodiment is described with emphasis instead of others. For example, as for the embodiments of the apparatus, the computing device and the machine-readable storage medium, since they are substantially similar to the method embodiments, the description is simple, and the relevant points can be referred to the partial description of the method embodiments.
Specific embodiments of this specification have been described above. 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.
It will be understood that various modifications to the embodiments described herein will be readily apparent to those skilled in the art, and that the generic principles defined herein may be applied to other variations without departing from the scope of the claims.
Claims (38)
1. A method for node management for a blockchain system, comprising:
carrying out pre-vote interaction on a first node in a blockchain system and each node in the blockchain system to determine whether the blockchain system is in a main node election process;
in the case that the blockchain system is not in the process of master node election, the first node executes an operation of deleting the node to be deleted from the blockchain system;
in a case where the blockchain system is in the process of master node election, the first node determines not to perform an operation of causing the node to be deleted from the blockchain system.
2. The method of claim 1, wherein a first node in the blockchain system performs a pre-vote interaction with each node in the blockchain system, comprising:
the first node sends a pre-voting message to each node, wherein the pre-voting message comprises information for identifying the node to be deleted;
the first node receives M pre-voting confirmation messages sent by M nodes in each node aiming at the pre-voting messages, wherein each pre-voting confirmation message indicates the consensus state of the node sending the pre-voting confirmation message, and M is a positive integer;
the first node determines whether the blockchain system is in a master node election process based on the M pre-vote confirmation messages.
3. The method of claim 2, wherein the node to be deleted is a current master node;
the M pre-vote 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.
4. The method of claim 2 or 3, wherein the first node determining whether the blockchain system is in the process of master node election based on the M pre-vote confirmation messages comprises:
if at least K pre-vote confirmation messages in the M pre-vote confirmation messages indicate a master node election state, the first node determines that the blockchain system is in a master node election process, wherein K is a legal number determined based on a consensus algorithm used by the blockchain system;
the first node determines that the blockchain system is not in the process of election by the master node if at least K of the M pre-vote confirmation messages indicate another consensus state different from the state of election by the master node.
5. A method according to claim 2 or 3, wherein the pre-poll message includes an identity and a network address of the node to be deleted.
6. A method according to claim 2 or 3, wherein each pre-vote confirmation message comprises consensus status information, identity and current master node identity of the node sending the pre-vote confirmation message.
7. The method of any of claims 1-3, wherein, in the event that the blockchain system is not in the process of master node election, the first node performs operations that cause the node to be deleted from the blockchain system, comprising:
under the condition that the blockchain system is not in the process of electing a main node, the first node sends transaction requests to all the nodes, wherein the transaction requests are used for requesting to execute a transaction for deleting the nodes to be deleted;
wherein the transaction is executed after the nodes reach the consensus of executing the transaction, so that the node to be deleted is deleted from the blockchain system.
8. The method of any of claims 1-3, wherein the first node determining not to perform operations that cause the node to be deleted from the blockchain system while the blockchain system is in the process of master node election comprises:
and under the condition that the blockchain system is in the process of electing a main node, the first node determines not to send transaction requests to all the nodes, wherein the transaction requests are used for requesting to execute the transaction of deleting the nodes to be deleted.
9. The method according to any one of claims 1 to 3, wherein the first node is the node to be deleted;
the method further comprises the following steps:
the first node sends another transaction request to each node during or after the pre-voting interaction, wherein the another transaction request is used for requesting to execute another transaction, and the another transaction is different from the transaction for deleting the node to be deleted;
wherein the respective nodes refuse to execute the further transaction after reaching a consensus that the further transaction is not to be executed.
10. The method of any one of claims 1 to 3, wherein the blockchain system comprises a federation chain system.
11. A method for node management for a blockchain system, comprising:
a second node in the blockchain system performs pre-vote interaction with a first node in the blockchain system to assist the first node in determining whether the blockchain system is in a master node election process;
if the first node requests to delete a node to be deleted from the blockchain system without the blockchain system being in the process of master node election, the second node performs an operation of causing the node to be deleted from the blockchain system; and if the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
12. The method of claim 11, wherein the pre-ticketing interaction of the second node in the blockchain system with the first node in the blockchain system comprises:
the second node receiving a pre-vote message from the first node, wherein the pre-vote message comprises information identifying the node to be deleted;
the second node sends a pre-vote confirmation message for the pre-vote message to the first node, wherein the pre-vote confirmation message indicates a consensus status of the second node.
13. The method of claim 12, wherein the node to be deleted is a current master node;
the second node sending a pre-vote confirmation message for the pre-vote message to the first node, comprising:
and after the block chain system elects a new main node different from the node to be deleted through a main node election process, the second node sends the pre-voting confirmation message to the first node.
14. The method of claim 12 or 13, wherein the pre-poll message comprises an identity and a network address of the node to be deleted.
15. The method of claim 12 or 13, wherein the pre-vote confirmation message comprises consensus status information, identity and current master node identity of the second node.
16. The method of any of claims 11 to 13, wherein the second node performs operations that cause the node to be deleted from the blockchain system, comprising:
the second node receives a transaction request sent by the first node under the condition that the blockchain system is not in the process of electing the main node, wherein the transaction request is used for requesting to execute a transaction for deleting the node to be deleted;
the second node performs the transaction after reaching consensus for performing the transaction with each node in the blockchain system, such that the node to be deleted is deleted from the blockchain system.
17. The method according to any one of claims 11 to 13, wherein the first node is the node to be deleted;
the method further comprises the following steps:
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 for requesting to execute another transaction, and the another transaction is different from the transaction for deleting the node to be deleted;
the second node refuses to execute the other transaction after reaching a consensus with each node in the blockchain system that the other transaction is not executed.
18. The method of any of claims 11 to 13, wherein the blockchain system comprises a federation chain system.
19. A node in a blockchain system, comprising:
the interaction unit is used for carrying out pre-vote interaction with each node in the blockchain system so as to determine whether the blockchain system is in the process of electing the main node;
an execution unit to:
executing an operation of causing a node to be deleted from the blockchain system in the case that the blockchain system is not in the process of master node election;
determining not to perform an operation of causing the node to be deleted from the blockchain system if the blockchain system is in the process of master node election.
20. The node according to claim 19, wherein the interaction unit is specifically configured to:
sending a pre-voting message to each node, wherein the pre-voting message comprises information for identifying the node to be deleted;
receiving M pre-voting confirmation messages sent by M nodes in each node aiming at the pre-voting messages, wherein each pre-voting confirmation message indicates the consensus state of the node sending the pre-voting confirmation message, and M is a positive integer;
determining whether the blockchain system is in a master node election process based on the M pre-vote confirmation messages.
21. The node of claim 20, wherein the node to be deleted is a current master node;
the M pre-vote 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.
22. The node according to claim 20 or 21, wherein the interaction unit is specifically configured to:
if at least K pre-vote confirmation messages in the M pre-vote confirmation messages indicate a master node election state, determining that the blockchain system is in a master node election process, wherein K is a legal number determined based on a consensus algorithm used by the blockchain system;
determining that the blockchain system is not in the primary node election process if at least K of the M pre-vote confirmation messages indicate another consensus state different from the primary node election state.
23. The node of claim 20 or 21, wherein the pre-poll message comprises an identity and a network address of the node to be deleted.
24. A node as claimed in claim 20 or 21, wherein each pre-vote confirmation message comprises consensus status information, identity and current master node identity of the node sending the pre-vote confirmation message.
25. The node according to any one of claims 19 to 21, wherein the execution unit is specifically configured to:
under the condition that the blockchain system is not in the process of electing the main node, sending a transaction request to each node, wherein the transaction request is used for requesting to execute a transaction for deleting the node to be deleted;
wherein the transaction is executed after the nodes reach the consensus of executing the transaction, so that the node to be deleted is deleted from the blockchain system.
26. The node according to any one of claims 19 to 21, wherein the execution unit is specifically configured to:
and under the condition that the blockchain system is in the process of electing the main node, determining not to send a transaction request to each node, wherein the transaction request is used for requesting to execute a transaction for deleting the node to be deleted.
27. The node of any of claims 19-21, wherein the node is the node to be deleted;
the execution unit is further to:
during or after the pre-vote interaction is carried out, sending another transaction request to each node, wherein the another transaction request is used for requesting to execute another transaction, and the another transaction is different from the transaction for deleting the node to be deleted;
wherein the respective nodes refuse to execute the further transaction after reaching a consensus that the further transaction is not to be executed.
28. The node of any of claims 19 to 21, wherein the blockchain system comprises a federation chain system.
29. A node in a blockchain system, comprising:
the interaction unit is used for carrying out pre-vote interaction with a first node in the blockchain system so as to assist the first node in determining whether the blockchain system is in the process of main node election;
an execution unit to: if the first node requests to delete a node to be deleted from the blockchain system under the condition that the blockchain system is not in the process of main node election, performing an operation of enabling the node to be deleted from the blockchain system; and if the blockchain system is in the process of electing the master node, the node to be deleted cannot be deleted from the blockchain system.
30. The node according to claim 29, wherein the interaction unit is specifically configured to:
receiving a pre-vote message from the first node, wherein the pre-vote message comprises information identifying the node to be deleted;
sending a pre-vote confirmation message for the pre-vote message to the first node, wherein the pre-vote confirmation message indicates a consensus status of the nodes.
31. The node of claim 30, wherein the node to be deleted is a current master node;
the interaction unit is specifically configured to:
and after the block chain system elects a new main node different from the node to be deleted through a main node election process, sending the pre-voting confirmation message to the first node.
32. The node of claim 30 or 31, wherein the pre-poll message comprises an identity and a network address of the node to be deleted.
33. A node as claimed in claim 30 or 31, wherein the pre-vote confirmation message comprises consensus status information, identity and current master node identity for the node.
34. 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 under the condition that the blockchain system is not in the process of electing a main node, wherein the transaction request is used for requesting to execute a transaction for deleting the node to be deleted;
performing the transaction after reaching consensus for performing the transaction with each node in the blockchain system such that the node to be deleted is deleted from the blockchain system.
35. The node of any of claims 29 to 31, wherein the first node is the node to be deleted;
the execution unit is further to:
receiving another transaction request sent by the first node during or after the pre-voting interaction, wherein the another transaction request is used for requesting to execute another transaction, and the another transaction is different from the transaction for deleting the node to be deleted;
refusing to execute the other transaction after reaching a consensus with each node in the blockchain system that the other transaction is not executed.
36. The node of any of claims 29 to 31, wherein the blockchain system comprises a federation chain system.
37. A computing device, comprising:
at least one processor;
a memory in communication with the at least one processor having stored thereon executable instructions that, when executed by the at least one processor, cause the at least one processor to implement the method of any one of claims 1-10.
38. A computing device, comprising:
at least one processor;
a memory in communication with the at least one processor having stored thereon executable instructions that, when executed by the at least one processor, cause the at least one processor to implement the method of any of claims 11-18.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010181765.5A CN111049696B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
| PCT/CN2020/139713 WO2021184878A1 (en) | 2020-03-16 | 2020-12-26 | Node management method for block chain system, node, and computational device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010181765.5A CN111049696B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111049696A true CN111049696A (en) | 2020-04-21 |
| CN111049696B CN111049696B (en) | 2020-06-12 |
Family
ID=70231082
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010181765.5A Active CN111049696B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111049696B (en) |
| WO (1) | WO2021184878A1 (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112087521A (en) * | 2020-09-17 | 2020-12-15 | 广州智云尚大数据科技有限公司 | Block chain link point authority control method based on big data and block chain system |
| CN112671761A (en) * | 2020-12-22 | 2021-04-16 | 网易（杭州）网络有限公司 | Node processing method and device for block chain, node equipment and storage medium |
| WO2021184878A1 (en) * | 2020-03-16 | 2021-09-23 | 支付宝(杭州)信息技术有限公司 | Node management method for block chain system, node, and computational device |
| CN113645074A (en) * | 2021-08-11 | 2021-11-12 | 永旗(北京)科技有限公司 | Consensus method based on block chain |
| CN114448769A (en) * | 2022-04-02 | 2022-05-06 | 支付宝(杭州)信息技术有限公司 | Node election voting method and device based on consensus system |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113630257B (en) * | 2021-10-09 | 2022-01-04 | 支付宝(杭州)信息技术有限公司 | Consensus method, block chain system and consensus node |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106331046A (en) * | 2015-07-02 | 2017-01-11 | 中兴通讯股份有限公司 | Cluster main node voting method and device |
| US20190020471A1 (en) * | 2016-12-23 | 2019-01-17 | Joseph Santilli | Methods and systems for crowdsourcing an outcome to an issue |
| CN110300167A (en) * | 2019-06-28 | 2019-10-01 | 京东数字科技控股有限公司 | Business information processing method, equipment and readable storage medium storing program for executing based on block chain |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109427012B (en) * | 2017-08-22 | 2021-06-01 | 汇链丰(北京)科技有限公司 | Transaction and verification method based on block chain |
| CN108134706B (en) * | 2018-01-02 | 2020-08-18 | 中国工商银行股份有限公司 | Block chain multi-activity high-availability system, computer equipment and method |
| US11063746B2 (en) * | 2018-04-19 | 2021-07-13 | Electronics And Telecommunications Research Institute | Method for selecting consensus node using nonce and method and apparatus for generating blockchain using the same |
| CN111049696B (en) * | 2020-03-16 | 2020-06-12 | 支付宝(杭州)信息技术有限公司 | Method, node and computing device for node management of blockchain system |
-
2020
- 2020-03-16 CN CN202010181765.5A patent/CN111049696B/en active Active
- 2020-12-26 WO PCT/CN2020/139713 patent/WO2021184878A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106331046A (en) * | 2015-07-02 | 2017-01-11 | 中兴通讯股份有限公司 | Cluster main node voting method and device |
| US20190020471A1 (en) * | 2016-12-23 | 2019-01-17 | Joseph Santilli | Methods and systems for crowdsourcing an outcome to an issue |
| CN110300167A (en) * | 2019-06-28 | 2019-10-01 | 京东数字科技控股有限公司 | Business information processing method, equipment and readable storage medium storing program for executing based on block chain |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021184878A1 (en) * | 2020-03-16 | 2021-09-23 | 支付宝(杭州)信息技术有限公司 | Node management method for block chain system, node, and computational device |
| CN112087521A (en) * | 2020-09-17 | 2020-12-15 | 广州智云尚大数据科技有限公司 | Block chain link point authority control method based on big data and block chain system |
| CN112087521B (en) * | 2020-09-17 | 2021-12-17 | 山东诺蓝信息科技有限公司 | Block chain link point authority control method based on big data and block chain system |
| CN112671761A (en) * | 2020-12-22 | 2021-04-16 | 网易（杭州）网络有限公司 | Node processing method and device for block chain, node equipment and storage medium |
| CN112671761B (en) * | 2020-12-22 | 2022-08-05 | 网易（杭州）网络有限公司 | Node processing method and device for block chain, node equipment and storage medium |
| CN113645074A (en) * | 2021-08-11 | 2021-11-12 | 永旗(北京)科技有限公司 | Consensus method based on block chain |
| CN114448769A (en) * | 2022-04-02 | 2022-05-06 | 支付宝(杭州)信息技术有限公司 | Node election voting method and device based on consensus system |
| CN114448769B (en) * | 2022-04-02 | 2022-07-01 | 支付宝(杭州)信息技术有限公司 | Node election voting method and device based on consensus system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111049696B (en) | 2020-06-12 |
| WO2021184878A1 (en) | 2021-09-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111049696B (en) | Method, node and computing device for node management of blockchain system | |
| CN111046110B (en) | Method, node and computing device for node management of blockchain system | |
| CN111782275B (en) | Transaction processing method and device based on blockchain and electronic equipment | |
| CN108805702B (en) | Transaction buffering/accelerating method based on block chain and block chain transaction processing system | |
| JP2022508247A (en) | High-performance distributed recording system with reliability-based consensus | |
| CN110263035A (en) | Data storage, querying method and device and electronic equipment based on block chain | |
| CN110602108B (en) | Data communication method, device, equipment and storage medium based on block chain network | |
| CN110474797A (en) | API operation system, the method and device of active-standby switch | |
| CN113438219B (en) | Playback transaction identification method and device based on blockchain all-in-one machine | |
| CN110597918A (en) | Account management method and device and computer readable storage medium | |
| CN111163173B (en) | Cluster configuration method and device, server and readable storage medium | |
| CN112422341B (en) | Fault detection method of block chain network and related equipment | |
| CN110971702A (en) | Service calling method and device, computer equipment and storage medium | |
| CN106571968B (en) | Service switching method and system | |
| JP2022523217A (en) | Topology Driven Byzantine Fault Tolerant Consensus Protocol with Voting Aggregation | |
| CN113781202A (en) | Data processing method, data processing device, computer equipment and storage medium | |
| CN112636987B (en) | Cross-chain gateway determination method and system for block chain and terminal equipment | |
| CN110908801B (en) | Data processing method and device based on block chain, computer equipment and storage medium | |
| CN113377702A (en) | Method and device for starting two-node cluster, electronic equipment and storage medium | |
| CN116414628A (en) | Transaction request processing method and device in new and old system switching process | |
| CN115145715A (en) | Distributed transaction processing method, system and related equipment | |
| US20080259789A1 (en) | Method and apparatus for re-establishing anonymous data transfers | |
| CN114338669B (en) | Block chain-based data transmission method, device, equipment and storage medium | |
| CN116991623B (en) | Block chain node exception recovery method and device, electronic equipment and storage medium | |
| CN111626735B (en) | Data interaction system, method and module |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240923 Address after: Room 803, 8th floor, 618 waima Road, Huangpu District, Shanghai 200001 Patentee after: Ant blockchain Technology (Shanghai) Co.,Ltd. Country or region after: China Address before: 310000 801-11 section B, 8th floor, 556 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province Patentee before: Alipay (Hangzhou) Information Technology Co.,Ltd. Country or region before: China |