CN112015811A - 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
- CN112015811A CN112015811A CN202010778955.5A CN202010778955A CN112015811A CN 112015811 A CN112015811 A CN 112015811A CN 202010778955 A CN202010778955 A CN 202010778955A CN 112015811 A CN112015811 A CN 112015811A
- Authority
- CN
- China
- Prior art keywords
- node
- blockchain system
- added
- join
- transaction
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 155
- 230000008569 process Effects 0.000 claims abstract description 111
- 230000003993 interaction Effects 0.000 claims abstract description 26
- 238000012790 confirmation Methods 0.000 claims description 90
- 230000003213 activating effect Effects 0.000 claims description 14
- 238000004891 communication Methods 0.000 claims description 10
- 238000012545 processing Methods 0.000 claims description 9
- 230000002452 interceptive effect Effects 0.000 claims 2
- 238000010586 diagram Methods 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007246 mechanism 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
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (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 between the node to be added and the 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 block chain system is not in the process of electing the main node, adding a node to be added into the block chain system; and under the condition that the blockchain system is in the process of electing the main node, determining that the node to be added cannot be added into the blockchain system.
Description
This patent application is application number: 202010181033.6, filing date: the invention discloses a divisional application of Chinese patent application named 'method, device and equipment for managing nodes of a block chain system' on 16/3 in 2020.
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: and the node to be added sends the pre-voting message to the nodes in the block chain system. Wherein the pre-voting message comprises information for identifying the node to join. And the node to be added receives a pre-vote confirmation message sent by the node in the block chain system aiming at the pre-vote message. Wherein each pre-vote confirmation message indicates a consensus status of the node that sent the pre-vote confirmation message. And the node to be added determines whether the block chain system is currently in the process of election of the main node or not based on the received pre-voting confirmation message. And the node to be added determines whether to add the block chain system currently according to the determination result.
In another aspect, an embodiment of the present specification provides a method for node management of a blockchain system, including: a first node in the block chain system receives a pre-vote message sent by a node to be joined. Wherein the pre-voting message comprises information for identifying the node to join. And the first node sends a pre-vote confirmation message aiming at the pre-vote message to the node to be joined. Wherein the pre-vote confirmation message indicates a consensus status of the first node. To assist the joining node in determining whether the blockchain system is in the process of master node election. And if the node to be added requests to be added to the block chain system, the first node performs corresponding processing according to the consensus state.
In another aspect, embodiments of the present specification provide a node, where the node is a node to be joined to a blockchain system. The node comprises an interaction unit which sends the pre-voting message to the nodes in the block chain system. Wherein the pre-voting message comprises information for identifying the node to join. And receiving a pre-vote confirmation message sent by the node in the blockchain system aiming at the pre-vote message. Wherein each pre-vote confirmation message indicates a consensus status of the node that sent the pre-vote confirmation message. Determining whether the blockchain system is currently in a master node election process based on the received pre-vote confirmation message. The node also comprises a determining unit which determines whether to join the block chain system currently according to the determination result of the interaction unit.
In another aspect, embodiments of the present specification provide a node, where the node is a member in the blockchain system, and the node includes an interaction unit that receives a pre-vote message sent by a node to be joined. Wherein the pre-voting message comprises information for identifying the node to join. And sending a pre-vote confirmation message aiming at the pre-vote message to the node to be joined. Wherein the pre-vote confirmation message indicates a consensus status of the first node. To assist the joining node in determining whether the blockchain system is in the process of master node election. The node also comprises an execution unit, and if the node to be added requests to be added to the block chain system, corresponding processing is carried out according to the consensus state.
In another aspect, embodiments of the present specification provide 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 send a pre-vote message to a node in a blockchain system. Wherein the pre-voting message comprises information for identifying the node to join. Receiving a pre-vote confirmation message sent by a node in the blockchain system for the pre-vote message. Wherein each pre-vote confirmation message indicates a consensus status of the node that sent the pre-vote confirmation message. Determining whether the blockchain system is currently in a master node election process based on the received pre-vote confirmation message. And determining whether to join the block chain system currently according to the determination result.
In another aspect, embodiments of the present specification provide 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 receive a pre-vote message sent by a node to be joined. Wherein the pre-voting message comprises information for identifying the node to join. And sending a pre-vote confirmation message aiming at the pre-vote message to the node to be added. Wherein the pre-vote confirmation message indicates a consensus status of the first node. To assist the joining node in determining whether the blockchain system is in the process of master node election. And if the node to be added requests to be added to the block chain system, performing corresponding processing according to the consensus state.
Therefore, in the technical scheme, the node to be added can be normally added into the blockchain system under the condition that the blockchain system is not in the main node election process, and cannot be added into the blockchain system under the condition that the blockchain system is in the main node election process, so that the stability and reliability of the blockchain system in the main node election process can be effectively 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 according to one embodiment.
Fig. 3B is a schematic block diagram of a node according to 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 (Practical 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 new node is added to the blockchain system during the master node election process and the new node needs to perform data synchronization and other operations, a large amount of bandwidth of the system is occupied, which may cause the master node election process to be overtime, prolonged, and the like, and each node may not return to a normal state in time to process transactions, thereby seriously affecting the stability of the whole blockchain system.
In view of this, in the technical solution of the present specification, the node to be added may determine whether the blockchain system is in the process of electing the master node by performing pre-vote interaction with each node in the blockchain system. In the case where the blockchain system is in the process of master node election, the node to be joined will not be allowed to join the blockchain system. And under the condition that the blockchain system is not in the process of electing the master node, the node to be added can be normally added into the blockchain system. It is to be understood that a node to be joined may refer to a node that desires to join the blockchain system.
Therefore, in the technical scheme, the node to be added can be normally added into the blockchain system under the condition that the blockchain system is not in the main node election process, and cannot be added into the blockchain system under the condition that the blockchain system is in the main node election process, so that the stability and reliability of the blockchain system in the main node election process can be effectively 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. The method of fig. 1A may be performed by a node-to-join desiring to join a blockchain system.
As shown in fig. 1A, in step 102A, the node to be joined performs pre-vote interaction with nodes in the blockchain system, and determines whether the blockchain system is in the process of electing the master node.
In step 104A, in the case that the blockchain system is not in the process of master node election, the joining node joins the blockchain system.
In step 106A, when the blockchain system is in the process of electing the master node, the node to be joined determines that the blockchain system cannot be joined.
Therefore, in the technical scheme, the node to be added can be normally added into the blockchain system under the condition that the blockchain system is not in the main node election process, and cannot be added into the blockchain system under the condition that the blockchain system is in the main node election process, so that the stability and reliability of the blockchain system in the main node election process can be effectively ensured.
In one embodiment, it is assumed that the blockchain system may include N nodes, where N is a positive integer greater than 1. In step 102A, the joining node may send a pre-vote (pre-vote) message to the N nodes. The pre-vote message may include information identifying the node to join.
Here, the node to be joined may send the pre-vote message to the N nodes in various communication manners. For example, a joining node may broadcast a pre-vote message to N nodes. For another example, the joining node may send a pre-vote message to the neighboring node, and the neighboring node may forward the pre-vote message to other nodes, so that the N nodes receive the pre-vote message. This is not a limitation in the present specification.
The joining node may then receive a pre-vote confirmation (pre-vote-ack) message sent by each node for the pre-vote message. For example, the joining node may receive M pre-vote confirmation messages sent by M nodes, where M is a positive integer.
In one case, the joining node may receive N pre-vote messages sent by all N nodes, where M and N are equal.
In another case, the joining node may not receive the pre-vote confirmation messages sent by all N nodes for various reasons (e.g., network delay, node failure, etc.), such as receiving only M pre-vote confirmation messages sent by M nodes. At this time, M is smaller than N.
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.
Thus, the node to be joined can determine whether the blockchain system is in the process of main node election 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 can be efficiently determined, so that the node to be added is assisted to judge whether the blockchain system can be added, and the influence on the stability of the blockchain system can be avoided.
In one embodiment, the pre-vote message may include an identification of the node to join 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 mark of the node to be added, and address represents the network address of the node to be added. 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, if most of the pre-vote confirmation messages indicate the master node election status, the joining node may determine that the blockchain system is in the process of master node election. Most of the pre-vote confirmation messages herein may be at least a quorum of pre-vote confirmation messages. 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, the quorum may be f +1, assuming that there are at most f failed nodes out of the N nodes. 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 pre-vote confirmation messages in the M pre-vote confirmation messages indicate the election state of the main node, the node to be added can determine that the block chain system is in the election process of the main node; and if at least K of the M pre-vote confirmation messages indicate another consensus state different from the master node election state, the node to be joined 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 joining node may send a transaction request to the nodes in the blockchain system without the blockchain system being in the process of master node election. For example, assuming that the blockchain system may include N nodes, the joining node may send transaction requests to the N nodes through various communication means. The transaction request may be for requesting execution of a transaction that activates the node to be joined.
The transaction is executed after the nodes in the blockchain system agree to execute the transaction, thereby enabling the joining node to join the blockchain system. For example, after at least a quorum of nodes in the blockchain system agree to perform a transaction, those nodes will perform the transaction. For example, each node may update configuration information for the node to be joined, for example, add the node to be joined information in the configuration information, so that the node to be joined joins 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 joining node may determine not to send a transaction request to a node in the blockchain system, the transaction request requesting execution of a transaction that activates the joining node.
For example, the node to be joined may not send a transaction request to activate itself when it is determined that the blockchain system is in the process of election by the master node, thereby avoiding the influence on the stability of the blockchain system due to joining 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 joining node may still send a transaction request requesting execution of a transaction that activates the joining node. For example, although the joining node determines that the blockchain system is in the process of master node election, it may still send a transaction request for some reason (e.g., malicious or otherwise). In this case, the node in the blockchain system will agree on not to perform the transaction for the transaction request, and thus not perform the transaction, so that the joining node cannot join the blockchain system. Therefore, the stability of the block chain system in the process of selecting the master node can be effectively ensured.
Therefore, according to the technical scheme in the specification, the node to be added is not added to the blockchain system when the blockchain system is electing the master node from multiple aspects, so that the stability of the blockchain system is ensured or improved.
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 convenience of description, a node performing the method of fig. 1B is referred to as a first node. For example, the first node may be a non-byzantine node.
As shown in fig. 1B, in step 102B, the first node performs pre-vote interaction with the node to be joined to assist the node to be joined in determining whether the blockchain system is in the process of master node election.
In step 104B, if the joining-to-node requests to join the blockchain system without the blockchain system being in the process of master node election, the first node may perform an operation of causing the joining-to-node to join the blockchain system.
In step 106B, if the node to be joined requests to join the blockchain system while the blockchain system is in the process of master node election, the first node may refuse the node to be joined to join the blockchain system.
Therefore, in the technical scheme, the node to be added is enabled to be normally added into the blockchain system under the condition that the blockchain system is not in the process of electing the master node, and the node to be added is refused to be added into the blockchain system under the condition that the blockchain system is in the process of electing the master node, so that the stability and the reliability of the blockchain system in the process of electing the master node can be effectively ensured.
In one embodiment, in step 102B, the first node may receive a pre-vote message from the joining node. The pre-vote message may include information identifying the node to join.
The first node may send a pre-vote confirmation message to the joining node. The pre-vote confirmation message may indicate a consensus status of the first node.
In one embodiment, the pre-vote message may include an identification of the node to join and a network address.
In one embodiment, the pre-vote confirmation message may include consensus status information, an identification of the first node, and a 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, in step 104B, the first node may receive a transaction request sent by the joining node without the blockchain system being in the master node election process, and the transaction request may be used to request execution of a transaction that activates the joining node.
In this way, after reaching a consensus to perform the transaction with each node in the blockchain system, the first node may perform the transaction such that the joining node joins the blockchain system. For example, the first node determines that at least a quorum of nodes, which may include the first node itself, have reached consensus to execute the transaction. The first node may then perform the transaction, such as updating configuration information for the joining node, thereby causing the joining node to join the blockchain system.
In one embodiment, in step 106B, the first node may receive a transaction request sent by the joining node with the blockchain system in the process of election by the master node, and the transaction request may be used to request execution of a transaction that activates the joining node.
Since the blockchain system is conducting master node elections, the first node will have consensus with each node in the blockchain system that the transaction is not being performed. For example, the first node determines that at least a quorum of nodes, which may include the first node itself, have reached a consensus that the transaction is not to be performed. In this way, the first node will refuse to execute the transaction, thereby making the joining node unable to join the blockchain system. Therefore, the stability and reliability of the block chain system in the process of selecting the main node can be ensured or improved.
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 R1, R2, and R3, and the node to be joined is R0.
As shown in fig. 2, the node to join R0 may send a pre-vote message 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 >.
The nodes R1, R2, and R3 may return a pre-vote-ack message to the joining node 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 >.
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.
The node to join R0 may determine whether the blockchain system is in the process of master node election after receiving 3 pre-vote-ack messages.
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 the to-be-joined node R0 may determine that the blockchain system is in a master node election state. At this time, the joining-node R0 may not transmit a transaction request for requesting execution of a transaction activating the node R0. Thus, when the blockchain system is in the master node election state, the node to be added will not be added to the blockchain system.
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, the to-be-joined node R0 may determine that the blockchain system is not in the master node election state.
At this time, as shown in fig. 2, the node to join R0 may transmit a transaction request for requesting execution of a transaction activating 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 join 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.
Therefore, in the technical scheme, the node to be added is normally added into the blockchain system under the condition that the blockchain system is not in the process of selecting the main node, and the blockchain system is not added under the condition that the blockchain system is in the process of selecting the main node, so that the stability and reliability of the blockchain system in the process of selecting the main node can be effectively ensured.
Fig. 3A is a schematic block diagram of a node according to one embodiment. Node 300A of fig. 3A may be a joining node that is to join the blockchain system.
The node 300A may include an interaction unit 302A, a joining unit 304A, and a determination unit 306A.
Interaction unit 302A may perform pre-vote interactions with nodes in the blockchain system to determine whether the blockchain system is in the process of master node election. The joining unit 304A may join the blockchain system in the event that the blockchain system is not in the process of master node election. The determining unit 306A may be configured to determine that the blockchain system cannot be added in the case that the blockchain system is in the process of the master node election.
Therefore, in the technical scheme, the node to be added can be normally added into the blockchain system under the condition that the blockchain system is not in the main node election process, and cannot be added into the blockchain system under the condition that the blockchain system is in the main node election process, so that the stability and reliability of the blockchain system in the main node election process can be effectively ensured.
In one embodiment, the blockchain system may include N nodes, N being a positive integer greater than 1.
The interaction unit 302A may send a pre-vote message to the N nodes, where the pre-vote message includes information identifying the node to join. The interaction unit 302A may receive M pre-vote confirmation messages transmitted by M nodes of the N nodes for the pre-vote confirmation messages, where each pre-vote confirmation message indicates a consensus status 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, 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 join 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 master node election, the joining unit 304A may send a transaction request to a node in the blockchain system, wherein the transaction request is used for requesting execution of a transaction that activates the node to be joined. The nodes in the blockchain system execute the transaction after reaching the consensus of executing the transaction, so that the node to be added is added into the blockchain system.
In another embodiment, in a case that the blockchain system is in the process of master node election, the determining unit 306A may determine not to send a transaction request to a node in the blockchain system, wherein the transaction request is used for requesting execution of a transaction that activates a node to be joined.
In another embodiment, in a case that the blockchain system is in the process of master node election, the determining unit 306A may send a transaction request to a node in the blockchain system, wherein the transaction request is used for requesting execution of a transaction that activates a node to be joined. The nodes in the blockchain system do not execute the transaction after reaching the consensus that the transaction is not executed, so that the node to be added is determined not to be capable of adding into the blockchain system.
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 according to one embodiment. Node 300B of fig. 3B may be a member node in a blockchain system.
The node 300B may comprise an interaction unit 302B and an execution unit 304B.
The interaction unit 302B may perform pre-vote interaction with the node to be joined to assist the node to be joined in determining whether the blockchain system is in the process of electing the master node. If the node to be joined requests to join the blockchain system without the blockchain system being in the process of the master node election, the execution unit 304B may perform an operation of causing the node to be joined to join the blockchain system. If the node to be joined requests to join the blockchain system while the blockchain system is in the process of master node election, the execution unit 304B may refuse the node to be joined to join the blockchain system.
Therefore, in the technical scheme, the node to be added is enabled to be normally added into the blockchain system under the condition that the blockchain system is not in the process of electing the master node, and the node to be added is refused to be added into the blockchain system under the condition that the blockchain system is in the process of electing the master node, so that the stability and the reliability of the blockchain system in the process of electing the master node can be effectively ensured.
In one embodiment, the interaction unit 302B may receive a pre-vote message from the node to be joined, wherein the pre-vote message includes information identifying the node to be joined.
The interaction unit 302B may send a pre-vote confirmation message for the pre-vote message to the joining node, wherein the pre-vote confirmation message indicates the consensus status of the node 300B.
In another embodiment, the pre-vote message may include an identification of the node to join 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 joining node when the blockchain system is not in the master node election process, wherein the transaction request is used for requesting to execute a transaction for activating the joining node.
The execution unit 304B may execute the transaction after reaching a consensus of executing the transaction with each node in the blockchain system, such that the node to be joined joins the blockchain system.
In another embodiment, the execution unit 304B may receive a transaction request sent by the node to be joined while the blockchain system is in the master node election process, wherein the transaction request is used for requesting to execute a transaction for activating the node to be joined. The execution unit 304B may refuse to execute the transaction after reaching a consensus that no transaction is executed with each node in the blockchain system, such that the node to be joined cannot join the blockchain system.
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 a node to join.
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 first node in the blockchain system.
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 (36)
1. A method for node management for a blockchain system, comprising:
the node to be joined sends a pre-voting message to a node in a block chain system, wherein the pre-voting message comprises information for identifying the node to be joined;
the node to be added receives pre-vote confirmation messages sent by the nodes in the block chain system aiming at the pre-vote messages, wherein each pre-vote confirmation message indicates the consensus state of the node sending the pre-vote confirmation message;
the node to be added determines whether the block chain system is currently in the process of electing the main node or not based on the received pre-voting confirmation message;
and the node to be added determines whether to add the block chain system currently according to the determination result.
2. The method of claim 1, wherein the node to be added determines whether to join the blockchain system currently according to the determination result, and the determining comprises:
under the condition that the blockchain system is not in the process of electing the main node, the node to be added is added into the blockchain system;
and under the condition that the blockchain system is in the process of electing the main node, the node to be added is determined to be incapable of adding the blockchain system.
3. The method of claim 1, the blockchain system comprising N nodes, N being a positive integer greater than 1;
the node to be added sends a pre-voting message to the nodes in the block chain system, and the method comprises the following steps:
the node to be added sends a pre-voting message to the N nodes;
the node to be added in the node receiving block chain receives a pre-vote confirmation message sent by the node aiming at the pre-vote message, and the pre-vote confirmation message comprises the following steps:
and the node to be added receives M pre-vote confirmation messages sent by M nodes in the N nodes aiming at the pre-vote messages, wherein M is a positive integer.
4. The method of claim 3, wherein the node to join determines whether the blockchain system is currently in a master node election process based on the received pre-vote confirmation message, comprising:
if at least K pre-vote confirmation messages in the M pre-vote confirmation messages indicate a master node election state, the node to be added determines that the blockchain system is in the master node election process, wherein K is a legal number determined based on a consensus algorithm used by the blockchain system;
and if at least K pre-vote confirmation messages in the M pre-vote confirmation messages indicate another consensus state different from the election state of the main node, the node to be added determines that the block chain system is not in the election process of the main node.
5. The method of claim 1, wherein the pre-vote message comprises an identification of the node to join and a network address.
6. The method of claim 1, wherein each pre-vote confirmation message comprises consensus status information, identification, and current master node identification of the node sending the pre-vote confirmation message.
7. The method of claim 2, wherein in the event that the blockchain system is not in the process of master node election, the joining node joining the blockchain system comprises:
under the condition that the blockchain system is not in the process of electing a main node, the to-be-joined node sends a transaction request to a node in the blockchain system, wherein the transaction request is used for requesting to execute a transaction for activating the to-be-joined node;
wherein a node in the blockchain system executes the transaction after reaching a consensus to execute the transaction, such that the node to join joins the blockchain system.
8. The method of claim 2, wherein in a case where the blockchain system is in the process of master node election, the determining that the node to join cannot join the blockchain system comprises:
under the condition that the blockchain system is in a master node election process, the node to be joined does not send a transaction request to nodes in the blockchain system, wherein the transaction request is used for requesting execution of a transaction for activating the node to be joined.
9. The method of claim 2, wherein in a case where the blockchain system is in the process of master node election, the determining that the node to join cannot join the blockchain system comprises:
under the condition that the blockchain system is in a master node election process, the to-be-added node sends a transaction request to a node in the blockchain system, wherein the transaction request is used for requesting execution of a transaction for activating the to-be-added node;
wherein a node in the blockchain system does not execute the transaction after reaching a consensus that the transaction is not executed, such that the node to join determines that the blockchain system cannot be joined.
10. The method of any of claims 1-9, wherein the blockchain system comprises a federation chain system.
11. A method for node management for a blockchain system, comprising:
a first node in a block chain system receives a pre-voting message sent by a node to be joined, wherein the pre-voting message comprises information for identifying the node to be joined;
the first node sends a pre-voting confirmation message aiming at the pre-voting message to the node to be added, wherein the pre-voting confirmation message indicates a consensus state of the first node so as to assist the node to be added in determining whether the blockchain system is in a main node election process;
and if the node to be added requests to be added to the block chain system, the first node performs corresponding processing according to the consensus state.
12. The method of claim 11, wherein if the node to be joined requests to join the blockchain system, the first node performs corresponding processing according to the consensus status, comprising:
if the node to be added requests to join the blockchain system under the condition that the blockchain system is not in the process of electing the main node, the first node executes the operation of enabling the node to be added to join the blockchain system;
and if the node to be added requests to join the blockchain system under the condition that the blockchain system is in the process of electing the master node, the first node refuses the node to be added to join the blockchain system.
13. The method of claim 11, wherein the pre-vote message includes an identification of the node to join and a network address.
14. The method of claim 11, wherein the pre-vote confirmation message comprises consensus status information, identity, and current master node identity of the first node.
15. The method of claim 12, wherein the first node performs operations that cause the node to join the blockchain system, comprising:
the first node receives a transaction request sent by the node to be joined under the condition that the blockchain system is not in a master node election process, wherein the transaction request is used for requesting execution of a transaction for activating the node to be joined;
after reaching consensus of executing the transaction with each node in the blockchain system, the first node executes the transaction so that the node to join joins the blockchain system.
16. The method of claim 12, wherein the first node rejecting the node to join to the blockchain system comprises:
the first node receives a transaction request sent by the node to be joined under the condition that the blockchain system is in a master node election process, wherein the transaction request is used for requesting execution of a transaction for activating the node to be joined;
after reaching a consensus with each node in the blockchain system not to execute the transaction, the first node refuses to execute the transaction, so that the node to be joined cannot join the blockchain system.
17. The method of any of claims 11-16, wherein the blockchain system comprises a federation chain system.
18. A node, wherein the node is a to-join node to join a blockchain system, the node comprising:
the interactive unit is used for sending a pre-voting message to a node in a block chain system, wherein the pre-voting message comprises information used for identifying the node to be added; and receiving pre-vote confirmation messages sent by nodes in the blockchain system aiming at the pre-vote messages, wherein each pre-vote confirmation message indicates the consensus state of the node sending the pre-vote confirmation message; determining whether the blockchain system is currently in a master node election process based on the received pre-voting confirmation message;
and the determining unit is used for determining whether to join the block chain system currently or not according to the determination result of the interaction unit.
19. The node of claim 18, the node further comprising: an addition unit;
the adding unit is used for adding the block chain system under the condition that the block chain system is not in the process of selecting the main node;
the determining unit further determines that the blockchain system cannot be added when the blockchain system is in the process of electing the master node.
20. The node of claim 18, the blockchain system comprising N nodes, N being a positive integer greater than 1;
the interaction unit sends a pre-voting message to the N nodes; and receiving M pre-vote confirmation messages sent by M nodes in the N nodes aiming at the pre-vote messages, wherein M is a positive integer.
21. The node according to claim 20, wherein the node is a node,
an interaction unit, configured to determine that the blockchain system is in a master node election process if at least K pre-vote confirmation messages of the M pre-vote confirmation messages indicate a master node election state, where K is a fixed 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.
22. The node of claim 18, wherein the pre-poll message includes an identification of the node to join and a network address.
23. The node of claim 18, wherein each pre-vote confirmation message comprises consensus status information, identification, and current master node identification of the node sending the pre-vote confirmation message.
24. The node according to claim 19, wherein,
the joining unit is used for sending a transaction request to a node in the blockchain system 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 the transaction for activating the node to be joined;
wherein a node in the blockchain system executes the transaction after reaching a consensus to execute the transaction, such that the node to join joins the blockchain system.
25. The node according to claim 19, wherein,
the determining unit determines not to send a transaction request to a node in the blockchain system when the blockchain system is in a process of electing a master node, wherein the transaction request is used for requesting to execute a transaction for activating the node to be joined.
26. The node of claim 19, wherein,
the determining unit is used for sending a transaction request to a node in the blockchain system under the condition that the blockchain system is in the process of electing the main node, wherein the transaction request is used for requesting to execute the transaction for activating the node to be added;
wherein a node in the blockchain system does not execute the transaction after reaching a consensus that the transaction is not executed, such that the node to join determines that the blockchain system cannot be joined.
27. The node of any of claims 18-26, wherein the blockchain system comprises a federation chain system.
28. A node, wherein the node is a member node in a blockchain system, the node comprising:
the interactive unit is used for receiving a pre-voting message sent by a node to be added, wherein the pre-voting message comprises information used for identifying the node to be added; sending a pre-voting confirmation message aiming at the pre-voting message to the node to be added, wherein the pre-voting confirmation message indicates a consensus state of the first node so as to assist the node to be added in determining whether the blockchain system is in a main node election process;
and the execution unit is used for carrying out corresponding processing according to the consensus state if the node to be added requests to be added to the block chain system.
29. The node according to claim 28, wherein,
the execution unit is used for executing the operation of enabling the node to be added to join the blockchain system if the node to be added requests to join the blockchain system under the condition that the blockchain system is not in the process of electing the main node; and the number of the first and second groups,
and if the node to be added requests to join the blockchain system under the condition that the blockchain system is in the process of electing the master node, the first node refuses the node to be added to join the blockchain system.
30. The node of claim 28, wherein the pre-poll message includes an identification of the to-join node and a network address.
31. The node of claim 28, wherein the pre-vote confirmation message comprises consensus status information, identity, and current master node identity for the node.
32. The node according to claim 29, wherein,
the execution unit is used for receiving a transaction request sent by the node to be added under the condition that the blockchain system is not in the master node election process, wherein the transaction request is used for requesting to execute the transaction for activating the node to be added;
after reaching a consensus of performing the transaction with each node in the blockchain system, performing the transaction such that the node to join joins the blockchain system.
33. The node according to claim 29, wherein,
the execution unit is used for receiving a transaction request sent by the node to be added under the condition that the blockchain system is in a master node election process, wherein the transaction request is used for requesting to execute a transaction for activating the node to be added;
refusing to execute the transaction after reaching a consensus with each node in the blockchain system that the transaction is not executed, such that the node to join cannot join the blockchain system.
34. The node of any of claims 28-33, wherein the blockchain system comprises a federation chain system.
35. A computing device, comprising:
at least one processor;
a memory in communication with the at least one processor having executable instructions stored thereon that, when executed by the at least one processor, cause the at least one processor to:
sending a pre-vote message to a node in a blockchain system, wherein the pre-vote message comprises information for identifying the node to join;
receiving pre-vote confirmation messages sent by nodes in the blockchain system aiming at the pre-vote messages, wherein each pre-vote confirmation message indicates the consensus state of the node sending the pre-vote confirmation message;
determining whether the blockchain system is currently in a master node election process based on the received pre-voting confirmation message;
and determining whether to join the block chain system currently according to the determination result.
36. A computing device, comprising:
at least one processor;
a memory in communication with the at least one processor having executable instructions stored thereon that, when executed by the at least one processor, cause the at least one processor to:
receiving a pre-voting message sent by a node to be joined, wherein the pre-voting message comprises information for identifying the node to be joined;
sending a pre-voting confirmation message aiming at the pre-voting message to the node to be added, wherein the pre-voting confirmation message indicates a consensus state of a first node so as to assist the node to be added in determining whether the blockchain system is in a main node election process;
and if the node to be added requests to be added to the block chain system, performing corresponding processing according to the consensus state.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010778955.5A CN112015811A (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010181033.6A CN111046110B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
| CN202010778955.5A CN112015811A (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010181033.6A Division CN111046110B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112015811A true CN112015811A (en) | 2020-12-01 |
Family
ID=70230996
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010778955.5A Pending CN112015811A (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
| CN202010181033.6A Active CN111046110B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010181033.6A Active CN111046110B (en) | 2020-03-16 | 2020-03-16 | Method, node and computing device for node management of blockchain system |
Country Status (2)
| Country | Link |
|---|---|
| CN (2) | CN112015811A (en) |
| WO (1) | WO2021184877A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112910982A (en) * | 2021-01-27 | 2021-06-04 | 网易（杭州）网络有限公司 | Node access method and device of alliance chain, electronic equipment and storage medium |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112015811A (en) * | 2020-03-16 | 2020-12-01 | 支付宝(杭州)信息技术有限公司 | Method, node and computing device for node management of blockchain system |
| CN114448769B (en) * | 2022-04-02 | 2022-07-01 | 支付宝(杭州)信息技术有限公司 | Node election voting method and device based on consensus system |
| CN115208895A (en) * | 2022-07-19 | 2022-10-18 | 中软航科数据科技(珠海横琴)有限公司 | Automatic networking method and system for block chain technology |
| CN116192692A (en) * | 2022-12-30 | 2023-05-30 | 蚂蚁区块链科技(上海)有限公司 | Method for distributing consensus data in block chain network and block chain network |
| CN116260707B (en) * | 2023-05-15 | 2023-10-10 | 安徽中科晶格技术有限公司 | Block chain node disaster recovery method, device and equipment based on consensus and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
| WO2020048436A1 (en) * | 2018-09-07 | 2020-03-12 | 腾讯科技（深圳）有限公司 | Method, device, computer apparatus and storage medium for electing representative node apparatus |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101478774B (en) * | 2009-01-20 | 2010-07-28 | 中国科学院软件研究所 | Wireless sensor network access control method for voice collecting and transmitting and system thereof |
| CN106331046A (en) * | 2015-07-02 | 2017-01-11 | 中兴通讯股份有限公司 | Cluster main node voting method and device |
| US10142347B2 (en) * | 2016-02-10 | 2018-11-27 | Bank Of America Corporation | System for centralized control of secure access to process data network |
| CN107040594B (en) * | 2017-04-12 | 2020-04-10 | 山大地纬软件股份有限公司 | Method and device for allowing block chain node to be admitted based on PBFT |
| CN107171829B (en) * | 2017-04-24 | 2019-12-24 | 杭州趣链科技有限公司 | Dynamic node management method realized based on BFT consensus algorithm |
| TWI684100B (en) * | 2018-06-12 | 2020-02-01 | 中華電信股份有限公司 | Consensus system and method for public distributed ledgers |
| CN110474986B (en) * | 2019-08-20 | 2022-08-12 | 深圳前海微众银行股份有限公司 | Consensus method, device and system based on block chain system |
| CN110727731B (en) * | 2019-09-05 | 2021-12-21 | 创新先进技术有限公司 | Method for adding node in block chain network and block chain system |
| CN112015811A (en) * | 2020-03-16 | 2020-12-01 | 支付宝(杭州)信息技术有限公司 | Method, node and computing device for node management of blockchain system |
-
2020
- 2020-03-16 CN CN202010778955.5A patent/CN112015811A/en active Pending
- 2020-03-16 CN CN202010181033.6A patent/CN111046110B/en active Active
- 2020-12-26 WO PCT/CN2020/139711 patent/WO2021184877A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020048436A1 (en) * | 2018-09-07 | 2020-03-12 | 腾讯科技（深圳）有限公司 | Method, device, computer apparatus and storage medium for electing representative node apparatus |
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
Non-Patent Citations (2)
| Title |
|---|
| MAKOTO TAKEMIYA: "Sora: A Decentralized Autonomous Economy", IEEE, 1 July 2019 (2019-07-01) * |
| 韩镇阳;宫宁生;任珈民;: "一种区块链实用拜占庭容错算法的改进", 计算机应用与软件, no. 02, 12 February 2020 (2020-02-12) * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112910982A (en) * | 2021-01-27 | 2021-06-04 | 网易（杭州）网络有限公司 | Node access method and device of alliance chain, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111046110B (en) | 2020-06-26 |
| CN111046110A (en) | 2020-04-21 |
| WO2021184877A1 (en) | 2021-09-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111046110B (en) | Method, node and computing device for node management of blockchain system | |
| CN111049696B (en) | Method, node and computing device for node management of blockchain system | |
| US11461773B2 (en) | Blockchain-based node management methods and apparatuses | |
| EP3816910B1 (en) | Blockchain-based transaction processing method and apparatus, and electronic device | |
| EP3816922A1 (en) | Blockchain-based transaction processing method and apparatus, and electronic device | |
| CN100359508C (en) | Merge protocol for schooling computer system | |
| EP3816912B1 (en) | Blockchain-based transaction processing method and apparatus, and electronic device | |
| CN110635905B (en) | Key management method, related equipment and computer readable storage medium | |
| CN110502319B (en) | Distributed transaction processing method and device, electronic equipment and storage medium | |
| CN112422341B (en) | Fault detection method of block chain network and related equipment | |
| CN105677675B (en) | Method for processing business and device | |
| CN110602108B (en) | Data communication method, device, equipment and storage medium based on block chain network | |
| CN111399991B (en) | Virtual resource locking method and device, storage medium and electronic device | |
| CN110597918A (en) | Account management method and device and computer readable storage medium | |
| CN111880852A (en) | Operating system initialization method, system, computer device and storage medium | |
| CN111988418B (en) | Data processing method, device, equipment and computer readable storage medium | |
| CN111582845A (en) | Cross-chain transaction method and device of block chain and electronic equipment | |
| CN106571968B (en) | Service switching method and system | |
| CN115390939B (en) | Service processing method and system | |
| CN111416851A (en) | Method for session synchronization among multiple load balancers and load balancer | |
| CN113641391B (en) | Method and device for upgrading block chain system and terminal equipment | |
| CN113839865B (en) | Management method and system for cross-domain call service | |
| CN112395104B (en) | Method and device for realizing distributed transaction context transfer in routing layer | |
| CN113472781B (en) | Service acquisition method, server and computer readable storage medium | |
| CN107220818B (en) | Online payment method and device |
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 | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40041494 Country of ref document: HK |