HK40034420A - System and method for adding node in blockchain network - Google Patents

Description

System and method for adding nodes in a blockchain network

Cross Reference to Related Applications

This application claims priority and benefit to a chinese application having application number CN201910838736.9 filed on 5.9.2019 with the national intellectual property office (SIPO) of the republic of china, the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates generally to systems and methods for adding nodes in a blockchain network.

Background

The block chain technique may be built on a transport network (e.g., a point-to-point network). Network nodes in the transport network may authenticate and store data based on the chained data structures and generate and update data based on a distributed consensus algorithm. In some cases, it may be desirable to add nodes of such a blockchain network. It is therefore desirable to provide a method for adding nodes in a blockchain network.

Existing techniques for adding nodes often result in disruption of the normal operation of the blockchain. In one example, current methods for adding nodes in a blockchain network require stopping the entire blockchain system to add the nodes, and requiring restarting the system after the addition. As a result, the entire system must experience downtime. In another example, current methods for adding nodes in a blockchain network require deleting inactive nodes and then re-adding the nodes as active consensus nodes. As a result, nodes that have been deleted and added later must first be disconnected from the blockchain network and then added back.

Disclosure of Invention

Various embodiments herein include, but are not limited to, systems, methods, and non-transitory computer-readable media for adding nodes in a blockchain network.

According to some embodiments, a computer-implemented method for adding nodes in a blockchain network, comprises: a current consensus node of the blockchain network obtains a first transaction comprising a first request for adding a node as a new consensus node of the blockchain network; in response to successful consensus verification of the first transaction, executing the first transaction and numbering nodes in a node list based on numbers of a plurality of current consensus nodes in the blockchain network; and performing a view change to cause the node to participate in future consensus verification as a new consensus node of the blockchain network. In some embodiments, the node to be added may be an inactive consensus node of the blockchain network before the node addition, and by the node addition, the node becomes an active consensus node of the blockchain network. In some embodiments, the node to be added may not be part of the blockchain network prior to the addition of the node, and by the addition of the node, the node is added to the blockchain network as an active consensus node.

In some embodiments, the first transaction is configured to invoke a blockchain contract deployed in a blockchain maintained by the blockchain network.

In some embodiments, the blockchain contract comprises an initial contract or a system contract.

In some embodiments, the current consensus node obtaining the first transaction comprises: the first transaction is obtained from a command console of the client device or the controller.

In some embodiments, the current consensus node maintains a list of nodes locally, the list of nodes including one or more of: identifying a node, an IP address and a port number of the node; the plurality of common nodes are sequentially numbered in the node list.

In some embodiments, the list of nodes is in a world state of a blockchain maintained by the blockchain network.

In some embodiments, numbering nodes in a node list based on the numbers of a plurality of current consensus nodes in the blockchain network comprises: adding a node identifier to the tail part of the node list based on the numbers of a plurality of common nodes in the node list, and numbering the nodes in sequence; or reordering the plurality of consensus nodes and the nodes in a node list according to the node attributes.

In some embodiments, performing the view change includes initiating the view change in response to detecting any of the following conditions: the number of the common identification nodes in the node list is inconsistent with the number of the common identification nodes in the current view; the common node identification in the node list is inconsistent with the common node identification in the current view.

In some embodiments, performing the view change comprises: the view change is initiated in response to receiving a message broadcast by the node to initiate the view change.

In some embodiments, after numbering the nodes in the list of nodes and before performing the view change, the method further comprises: obtaining, from the node, a second transaction comprising a second request to activate the node; performing consensus verification on the second transaction; and in response to the consensus verification of the second transaction being successful, performing the second transaction for activating the node.

In some embodiments, performing the view change includes initiating the view change in response to detecting any of the following conditions: the number of the activated common knowledge nodes in the node list is inconsistent with the number of the activated common knowledge nodes in the current view; and the identification of the active consensus node in the node list is inconsistent with the identification of the active consensus node in the current view.

In some embodiments, the number of copies in the view change is the total number of consensus nodes that comprise the node.

In accordance with some embodiments, a system for adding nodes in a blockchain network, implemented in a currently known node of the blockchain network, and comprising one or more processors and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions executable by the one or more processors to perform operations comprising: obtaining a first transaction comprising a first request to add a node as a new consensus node of a blockchain network; and in response to the consensus verification of the first transaction being successful, performing the first transaction and numbering nodes in a node list based on the numbers of a plurality of current consensus nodes in the blockchain network; and performing a view change to cause the node to participate in future consensus verification as a new consensus node of the blockchain network.

According to other embodiments, a non-transitory computer-readable storage medium, implemented in a current consensus node of a blockchain network, and configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising: obtaining a first transaction comprising a first request to add a node as a new consensus node of a blockchain network; in response to successful consensus verification of the first transaction, executing the first transaction and numbering nodes in a node list based on numbers of a plurality of current consensus nodes in the blockchain network; and performing a view change to cause the node to participate in future consensus verification as a new consensus node of the blockchain network.

According to still other embodiments, an apparatus for adding a node in a blockchain network is implemented in a current consensus node of the blockchain network and comprises: an obtaining module to obtain a first transaction comprising a first request to add a node as a new consensus node of a blockchain network; the execution module is used for responding to successful consensus verification of the first transaction, executing the first transaction and numbering the nodes in the node list based on the numbers of a plurality of current consensus nodes in the block chain network; and an enforcement module to enforce the view change to cause the node to participate in future consensus verification as a new consensus node of the blockchain network.

According to some embodiments, a computer-implemented method for adding nodes in a blockchain network, comprises: synchronizing a blockchain to be added to nodes in a blockchain network to obtain a first local blockchain copy, wherein the blockchain network maintains a blockchain and includes a plurality of current consensus nodes; in response to determining that the first local blockchain copy includes a first request to add a node as a new consensus node of the blockchain network, sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes; and after adding the second transaction to the blockchain, synchronizing the first local blockchain copy with the blockchain to obtain a second local blockchain copy.

In some embodiments, prior to the synchronization blockchain, the method further comprises: a first transaction including a first request to add a node as a new consensus node of the blockchain network is sent to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction, and the first transaction is added to the blockchain in response to the consensus verification of the first transaction being successful.

In some embodiments, prior to the synchronization blockchain, the method further comprises: one of the plurality of current consensus nodes sends a first transaction comprising a first request to add the node as a new consensus node of the blockchain to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction and to add the first transaction into the blockchain in response to the consensus verification of the first transaction being successful.

In some embodiments, synchronizing the blockchain comprises: and respectively sending one or more synchronization requests to one or more of the plurality of current consensus nodes to obtain the data in the block chain.

In some embodiments, sending a second transaction including a second request to activate a node to one or more of the plurality of current consensus nodes comprises: the method further includes sending a second transaction including a second request for the activation node to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the second transaction, and executing the second transaction for the activation node in response to the consensus verification of the second transaction being successful.

In some embodiments, the method further comprises: after the plurality of current consensus nodes perform the view change for the blockchain, the second local blockchain copy is synchronized with the blockchain to obtain a third local blockchain copy.

In some embodiments, the method further comprises: and participating in consensus verification as a new consensus node of the blockchain network.

In some embodiments, the process of adding a node as a new consensus node of the blockchain network does not cause any interruption to the operation of the blockchain network.

In some embodiments, the method further comprises: determining, by the checkpoint message, that synchronization of the first local blockchain copy, the second local blockchain copy, or the second local blockchain copy is complete.

In some embodiments, the method further comprises: a request to query for a current maximum block number is sent to at least some of the plurality of current consensus nodes, and synchronization of the first, second, or second local block-chain copies is determined to have been completed by finding that the same maximum block number returned from at least some of the plurality of current consensus nodes coincides with the maximum local block number.

In some embodiments, the first request to add the node as a new consensus node of the blockchain network comprises: a request to change a node from an inactive consensus node of the blockchain network to an active consensus node of the blockchain network.

In some embodiments, the first request to add the node as a new consensus node of the blockchain network comprises: a request to include the node into the blockchain network as a new consensus node.

According to other embodiments, a system for adding nodes in a blockchain network includes one or more processors and one or more computer-readable memories coupled to the one or more processors and having stored thereon instructions executable by the one or more processors to perform the method of any of the preceding embodiments.

According to still further embodiments, a non-transitory computer-readable storage medium is configured with instructions executable by one or more processors to cause the one or more processors to perform the method of any of the preceding embodiments.

According to still further embodiments, an apparatus for adding nodes in a blockchain network comprises a plurality of modules for performing the method of any of the preceding embodiments.

In accordance with some embodiments, a system for adding nodes in a blockchain network, implemented in a node to be added to the blockchain network, and comprising one or more processors and one or more computer-readable memories coupled to the one or more processors and having stored thereon instructions executable by the one or more processors to: synchronizing a blockchain to obtain a first local blockchain copy, wherein a blockchain network maintains the blockchain and includes a plurality of current consensus nodes; in response to determining that the first local blockchain copy includes a first request to add a node as a new consensus node of the blockchain network, sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes; and after adding the second transaction to the blockchain, synchronizing the first local blockchain copy with the blockchain to obtain a second local blockchain copy.

According to other embodiments, a non-transitory computer-readable storage medium, implemented in a node to be added to a blockchain network, and configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising: synchronizing a blockchain to obtain a first local blockchain copy, wherein a blockchain network maintains the blockchain and includes a plurality of current consensus nodes; in response to determining that the first local blockchain copy includes a first request to add a node as a new consensus node of the blockchain network, sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes; and after adding the second transaction to the blockchain, synchronizing the first local blockchain copy with the blockchain to obtain a second local blockchain copy.

According to still other embodiments, an apparatus for adding a node in a blockchain network is implemented in a node to be added to the blockchain network and includes: a first synchronization module that synchronizes a blockchain to obtain a first local blockchain copy, wherein a blockchain network maintains the blockchain and includes a plurality of current consensus nodes; a sending module that sends a second transaction including a second request to activate a node to one or more of the plurality of current consensus nodes in response to determining that the first local blockchain copy includes a first request to add the node as a new consensus node of the blockchain network; and a second synchronization module to synchronize the first local blockchain copy with the blockchain to obtain a second local blockchain copy after the second transaction is added to the blockchain.

The embodiments disclosed herein have one or more technical effects. In some embodiments, adding nodes in a blockchain network increases the total number of consensus nodes in the blockchain network (e.g., a pragmatine fault-tolerant (PBFT) system), which increases the tolerance of the blockchain network to malicious or faulty (e.g., abnormal, offline) nodes, because the maximum number of malicious or faulty nodes f that the PBFT system can tolerate is equal to (n-1)/3 rounded down to the nearest integer. In one embodiment, the fault condition may be due to, for example, a configuration failure, a machine failure, a network failure, a software failure, and the like. Therefore, adding nodes in the blockchain network can improve the robustness and reliability of the blockchain network. In some embodiments, a node may be added as a new consensus node to a pool of existing consensus nodes without disrupting the operation of the blockchain network by dynamically performing a first transaction to add the node and a second transaction to activate the node. In one embodiment, system downtime is avoided during the node addition process, and the blockchain network maintains its normal operation. In some embodiments, by synchronizing multiple times before, between, and after performing the first transaction and the second transaction, the newly added node can obtain, in a short period of time, the same node list copy as the node list maintained by the existing consensus node and synchronize to the same blockchain data. In one embodiment, through view changes, all consensus nodes including the added node obtain the same copy of the node list including all consensus node numbers. Therefore, the added node can contribute to consensus verification as soon as possible together with the existing consensus nodes, and avoid wasting computing resources.

These and other features of the systems, methods, and non-transitory computer-readable media disclosed herein, as well as the functions of the related elements of structure and methods of operation and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part hereof, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits.

Drawings

FIG. 1 illustrates a diagram for creating a blockchain contract, in accordance with various embodiments.

FIG. 2 illustrates a diagram for invoking a blockchain contract, in accordance with various embodiments.

FIG. 3 illustrates a diagram for creating and invoking a blockchain contract, in accordance with various embodiments.

Fig. 4 shows a flow chart for a Practical Byzantine Fault Tolerant (PBFT) algorithm.

FIG. 5 shows a flow chart for recovery after performing a view change of the PBFT algorithm.

FIG. 6 shows a flow chart for performing view change of the PBFT algorithm.

Fig. 7 illustrates a flow diagram for adding nodes in a blockchain network, in accordance with various embodiments.

Fig. 8 illustrates a flow diagram of a method for adding nodes in a blockchain network, in accordance with various embodiments.

Fig. 9A and 9B illustrate a flow diagram of a method for adding nodes in a blockchain network, in accordance with various embodiments.

Fig. 10 illustrates a block diagram for implementing a blockchain network, in accordance with various embodiments.

Fig. 11A illustrates a block diagram of an apparatus for adding nodes in a blockchain network, in accordance with some embodiments.

Fig. 11B illustrates a block diagram of an apparatus for adding nodes in a blockchain network, in accordance with some embodiments.

FIG. 12 illustrates a block diagram of an exemplary computer system in which any of the embodiments described herein may be implemented.

Detailed Description

Block chains can be divided into three types: public block chains, private block chains, and federation block chains. Furthermore, there may be various combinations between the three types of blockchains, such as private blockchain + federation blockchain, federation blockchain + public blockchain, and so forth. Among them, the common blockchain is most decentralized (decentralized). For a public blockchain represented by bitcoins and etherhouses, participants of the public blockchain (blockchain nodes, or simply nodes) can read data records from the blockchain, participate in transactions, and compete for accounting (bookkeeping) rights for new blocks, etc. In addition, each participant is free to join and leave the blockchain network and perform related operations. However, for private blockchains, the data write permissions of the blockchain network may be controlled by an entity or organization, while the data read permissions are determined by the entity or organization. Thus, a private blockchain may be considered a weakly centralized system, where participating nodes are constrained and limited in number. The federation blockchain is between the public blockchain and the private blockchain, and may implement "partial decentralization. Each node of a federation blockchain may correspond to an entity or organization. Participants can join the federation blockchain network by authorization, thereby forming a federation with a common interest, and collectively maintaining operation of the blockchain network. For any of the various types of blockchains described above, there may be a need to dynamically add nodes in a blockchain network.

In some embodiments, nodes with a level of voting authority may be referred to as consensus nodes, which form a blockchain network and maintain their operation through consensus protocols. For example, the consensus node may assume responsibility for performing consensus verification on blockchain transactions (or simply transactions). In contrast, inactive nodes (which may or may not be part of the blockchain network) do not participate in such consensus verification. Through consensus verification, the consensus node can agree on adding the newly generated tile to the tile chain. The newly generated block may include one or more transactions for which consensus verification is performed by the consensus node. The consensus node may also make other consensus decisions on the blockchain, such as setting a service fee for the blockchain.

In some embodiments, the consensus node may include two types: activated and inactivated. The active consensus node may participate in the consensus verification and may be stored in the local node list in a sequential number. The inactive consensus node may not participate in the consensus verification and therefore will not be numbered in the local node list with the active consensus node.

Each of the public blockchain, the private blockchain, and the federation blockchain may provide an intelligent contract. The smart contracts may be deployed in a blockchain through a blockchain transaction and then invoked by another blockchain transaction. For example, etherhouses support users in creating and invoking complex algorithms. As a programmable block chain, the core of the ethernet house is the ethernet house virtual machine (EVM). Each ethernet house node may run an EVM. EVMs are graphic-ready, which means that even complex algorithms can be implemented by them. Deployment and invocation of smart contracts may be performed in the EVM.

As shown in fig. 1, Bob may send a blockchain transaction that includes the creation of the smart contract to the ethernet house network. The EVM of blockchain node 1 may perform blockchain transactions to generate respective instances of the intelligent contract. In fig. 1, "0 x6f8ae93 …" represents the address of the intelligent contract. The data field of the blockchain transaction may store a bytecode. The "to" field of the blockchain transaction may be an empty (null) blockchain account. After the block chain nodes achieve consensus through the consensus mechanism, intelligent contracts are successfully created and deployed in the block chains maintained by the block chain network, and future users can invoke the deployed intelligent contracts.

After the intelligent contract is created, a contract account corresponding to the intelligent contract is created in the blockchain, and the contract account has a specific address. The contract code and account data will be stored under the contract account. The behavior of the intelligent contract is controlled by the contract code, and the contract account stores the state of the intelligent contract. In other words, intelligent contracts enable the creation of virtual accounts in a blockchain that include contract code and account storage.

As shown in fig. 2, still taking the ethernet house as an example, Bob sends a blockchain transaction that includes information for invoking the smart contract to the ethernet house network. The EVM of blockchain node 1 may perform blockchain transactions to generate respective instances of the intelligent contract. For blockchain transactions in FIG. 2, the "from" field may include the address of the blockchain account that invoked the intelligent contract, and the "0 x6f8ae93 …" in the "to" field may represent the address of the intelligent contract to be invoked, the "value" field may represent the value of the Ethernet currency, and the "data" field may store the methods and parameters for invoking the intelligent contract. The balance of the ethernet currency held by the blockchain account may change after the intelligent contract is invoked. In addition, a user client may view the balance through a blockchain node (e.g., blockchain node 6 in fig. 2).

The intelligent contracts may be executed independently in each blockchain node of the blockchain network according to a prescribed manner. All execution records and data may be stored in the blockchain. Thus, after such blockchain transactions are performed, tamper-resistant and permanent proof of transaction is saved into the blockchain.

FIG. 3 illustrates the creation and invocation of an intelligent contract. Creating intelligent contracts in an ethernet fab involves steps such as writing intelligent contracts, compiling to bytecode, and deploying in blockchains. Invoking intelligent contracts in an ethernet fab may refer to initiating a blockchain transaction that points to the address of the intelligent contract that has been deployed, such that the contract code executes in the EVM of each node in the ethernet fab network.

In addition to the user creating the smart contracts, the smart contracts may be configured by the system in the starting blocks of the block chain. This type of contract may be referred to as a starting contract. In the initial contract, the data structure, parameters, attributes and methods of the blockchain network may be configured. Additionally, accounts with system administrator privileges may create or modify system-level intelligent contracts (simply "system contracts"). Different blockchain networks may employ different virtual machines in addition to EVM, and are not limited herein.

One difference between the blockchain technique and the traditional decentralized technique is accounting, or distributed accounting, at each node, rather than the traditional centralized accounting. In various blockchain networks, consensus algorithms (i.e., the above-described consensus mechanism) may be implemented to ensure record consistency among the accounting nodes. When a node generates a new block, other nodes will record the same new block if it is accepted by other nodes. The other nodes acknowledge that the processing of the new block is a consensus mechanism. The consensus mechanism is such that: the blockchain nodes agree on the block information to ensure that new blocks are correctly added to the blockchain. Currently, mainstream consensus mechanisms include: proof of workload (POW), proof of interest (POS), proof of delegation of interest (DPOS), a pragmatistine fault tolerant (PBFT) algorithm, a HoneyBadger BFT algorithm, etc.

In one example of the PBFT algorithm, some known attempts to dynamically add nodes in conjunction with PBFT are made. For example, "dynamic utility byzantine fault tolerance" (https:// ieeexplore. ieee.org/stamp. jsp. As another example, "Solida: a node adding and deleting algorithm based on bit coins POW and PBFT is provided based on a reconfigurable Byzantine consensus block chain protocol (https:// epicint. iacr. org/2017/1118.pdf), and a main node is selected based on POW voting by the algorithm. However, POWs are known to consume a significant amount of Central Processing Unit (CPU) resources. The consensus mechanism is described below using PBFT as an example.

The algorithm was proposed in 1999 by migel Castro and barbarba leiskov (barbarbarba L iskov), addressing the inefficiency of PBFT, reducing complexity from exponential to polynomial levels, making the application of PBFT feasible in real systems, paper published on the third ending operating system design and implementation seminar (1999) discourse the algorithm assumes that if up to f backup copies (i.e. nodes) are malicious or faulty, a total of 3f +1 or more copies can guarantee security and activity within asynchronous systems.

Furthermore, all copies go through a series of configurations (views) called views. In the view, one copy is the primary node and the other copies are backup nodes. The master node of a view is a replica p, such that p is v mod R, where v is the view number, the views are consecutively numbered, and R is the number of replicas. When a master node fails, it is necessary to trigger the view change protocol to make adjustments to change master nodes in the event of a system failure.

The PBFT algorithm is as follows.

1. Client device c sends a request to master node 0 (replica 0);

2. the main node 0 broadcasts a request to each backup node;

3. each of all the copies executes the request and sends a corresponding result to the client device c;

4. the client device c collects the same results from the f +1 different copies, respectively, as the final result of the operation.

An example of PBFT (incorporating the well-known problem of the byzantine general) is discussed below. Here, let n be 4 and f be 1, i.e. there are a total of four nodes, where the number of failed nodes is 1. Assume that the node numbers are 0, 1, 2, and 3, respectively, and the failed node is node 3. The process is as follows.

(request phase) client device c sends a request to master node 0;

(pre-preparation phase) master node 0 receives the request from client device c (or from the client device group), orders the requests (in the case of the client device group), and packages the requests into a message m. Master node 0 then broadcasts a prepare message to nodes 1, 2, and 3 (i.e., backup nodes 1, 2, and 3, also referred to as replicas or nodes 1, 2, and 3). The pre-prepared message comprises message m.

(preparation phase) after receiving the pre-preparation message, each of nodes 1, 2 and 3 will rebroadcast message m if nodes 1, 2 and 3 successfully validate message m. For example, node 1 will broadcast a prepare message to nodes 0, 2 and 3; node 2 will broadcast a prepare message to nodes 0, 1 and 3 and node 3 may experience downtime and be unable to broadcast. In addition, each node receives preparation messages broadcast by other nodes. Each node may add its own broadcast prepare message (a prepare message indicating its approval) and received prepare messages (a prepare message indicating approval by other nodes) to the local log. If a node receives a Quorum-1 acknowledgment for the same message (with a pre-prepare message and a Quorum-1 prepare message, the local log would have a Quorum acknowledgment), then the node transitions to the prepare phase.

(commit phase) each participating consensus node that has entered the prepare phase broadcasts a commit message to the other consensus nodes and adds the self-broadcast commit message (indicating self-approved commit message) to the local log. Each node then receives the commit message broadcast by the other nodes. If the node receives the Quorum-1 valid commit messages, the node adds the commit messages to the local log (with its own broadcast commit message and Quorum-1 commit messages, the local log will have Quorum commit messages) and transitions to the commit state.

(reply phase) each of all nodes participating in consensus verification sequentially executes a request or a set of ordered requests in message m of the pre-prepared message in its local virtual machine and then sends a reply to client device c.

If client device c receives f +1 identical reply messages, this indicates that the request by client device c has achieved network-wide consensus. Otherwise, the client device c may need to determine whether to resend the request to the master node 0.

The processing and description above with respect to fig. 4 is a conventional PBFT algorithm. The processing may be initiated by the client device such that one or more transactions in the client device-initiated request message are subjected to consensus verification and the results of the consensus verification are returned to the client device at the end of the consensus verification.

In a federation blockchain scenario, consensus verification (e.g., the pre-preparation, and commit processes of FIG. 4 above) may be initiated by any node. In the federation blockchain scenario, the client device is optional. If no client device is included, the request and reply phase of FIG. 4 becomes optional and the master node may initiate PBFT consensus verification after a certain number of blockchain transactions are obtained. If a client device is included, consensus verification may not be initiated by the client device, but may be initiated by the master node after the master node obtains a certain number of blockchain transactions. That is, the pre-preparation phase in FIG. 4 may not be triggered directly by the request phase.

If the master node behavior is malicious or malfunctioning (e.g., abnormal, offline), and fails to broadcast the client device's request, the client device may configure a timeout mechanism. If a timeout occurs, the client device may broadcast the request to all copies. If the replica detects malicious or faulty behavior of the master node (e.g., abnormal, offline), the replica may initiate a view change protocol phase to change the master node.

In addition, false proposals by the master node may result in failure of consensus verification in the three phases of pre-preparation, preparation and submission. Alternatively, in the preparation and commit phases, there may be no agreed upon Quorum, which also does not complete consensus verification. In these cases, a view change may also be initiated to change the master node.

In the view change protocol phase, the asynchronous problem between the previous node and the other nodes needs to be solved in order for the nodes to recover after the View Change (VC). For example, as shown in FIG. 5, at view v before the view change, master node replica 0 has submitted and executed proposal (disposition) m5 (e.g., message m5) corresponding to < v, n, d >, where v is the view number, n is the total number of nodes, and d is the message digest of proposal m 5. However, copy 1 may not have submitted proposal m5 due to network delays and is still in the pre-preparation phase. Copy 2 (and copy 3) may also be in a pre-preparation phase for proposal m 5. Thereafter, replica 0 experiences downtime. Thus, different nodes are in different states. After changing the master node, replica 0 can be recovered by a reboot. The master node may have changed to replica 1 and replicas 1-3 need to catch up with replica 0 on message processing progress. Thus, the new master node replica 1 needs to resend proposal m5 in the ready state for replicas 1-3 to execute and synchronize with the state of replica 0. Otherwise, at the new view v +1, copies 1-3 may complete the three-phase consensus verification for the new message m6, but only copy 0 has executed m5, while copies 1-3 have not executed m 5. That is, at new view v +1, the execution of new message m6 by copies 1-3 is initiated from a different state than copy 0. This may lead to inconsistencies between virtual machines of different nodes and to forking. In addition, in the above process, if replica 0 is in a ready state for m5, that is, if replica 0 has not yet executed m5 on its virtual machine, but other replicas lag behind replica 0 in processing, the ready state of replica 0 can be deleted without affecting the consistency of the entire system.

The view change protocol phase may include a view change protocol process and a new view protocol process. After the two protocol processes are executed, the change of the main node is completed. After the master node changes, the view number will be decremented by 1 to change to v + 1. The primary node replica 0 of fig. 4 changes to replica 1 according to p ═ v + 1)% n.

For example, as shown in fig. 6, a backup node that detects a primary node malicious or malfunctioning (e.g., abnormal, offline) may broadcast a message < view change, v +1, n, C, P, i > to other backup nodes. As shown in fig. 6, replica 1 detects that the original primary node replica 0 is behaving maliciously or malfunctioning (e.g., abnormal, offline), then replica 1 sends a message < view change, v +1, n, C, P, i > to replica 0, replica 2, and replica 3. Similarly, copy 2 sends message < view change, v +1, n, C, P, i > to copy 0, copy 1, and copy 3 sends message < view change, v +1, n, C, P, i > to copy 0, copy 1, and copy 2.

For broadcast messages, "view change" is a protocol identification indicating that the protocol is a view change protocol. The next view number is v +1, and "n" is the number of most recent stable checkpoints, and "C" is the set of 2f +1 checkpoint messages that have been verified. "P" is optional and, if present, indicates a set of one or more messages that have reached the ready state for the backup node that sent the view change message (corresponding to each < v, n, d > in the ready state, the pre-ready message and the signature that includes 2f different nodes).

After a new master node p ═ V +1 mod | R | such as copy 1 in fig. 6 receives 2f valid view change messages, the new master node broadcasts the message < new view, V +1, V, O, p > to the other nodes. The "new view" is a protocol identification indicating that the protocol is a new view protocol. The next view number is v + 1. "V" includes the view change message and the signatures received by the new master node from 2f different nodes, as well as the view change message for V +1 that has been sent or is to be sent by the new master node itself. "O" is the set of unexecuted pre-prepared messages retransmitted by the master node, and "p" is the signature of the current node (an existing node of the blockchain network, e.g., an existing/current consensus node). The selection rules for the set of pre-prepared messages include:

1. the stable checkpoint with the minimum number min-s is obtained from V, and the prepare message with the maximum number max-s is obtained from V.

2. Between min-s and max-s, if there is a message set P, then a message < < Prep, v +1, n, d >, m > is created. Otherwise, an empty pre-prepare message < < pre-prepare, v +1, n, d (null), m (null), is created, where m (null) is the empty message and d (null) is the digest of the empty message.

When the backup node receives a new view message from the primary node, the backup node verifies the signatures in V and O and the view change message. If so, the backup node enters the v +1 state and initiates processing of the prepare message in O.

In the example of a federation blockchain, in a federation blockchain scenario, a node may correspond to one or more accounts. Similarly, a node may not correspond to any account, but merely act as a consensus node. Additionally, the federation blockchain may include an initial contract or a system contract that may be generated as described above. The startup contract/system contract may configure a list of consensus nodes (node list, or simply list) for a federation blockchain, e.g., configure a set of public keys for the consensus nodes and arrange the public keys in the set according to a predetermined order. Each consensus node of the federation blockchain may locally store a local node list according to the list of consensus nodes in the start-up contract. In the local node list, each consensus node may be arranged according to the corresponding public key according to an order specified in the start-up contract/system contract. Thus, each local list of consensus nodes contains the same consensus nodes in the same order. In addition, methods and parameter configurations for consensus nodes may be added in the startup contract/system contract. Thus, based on the initial contract/system contract, each node may complete the node addition operation by changing the nodes in the local node list.

When the account initiates a request to add a consensus node, for example a transaction request, the first current consensus node may receive the request. For example, the request may be a node addition request made by the client device, thereby triggering the node addition process. Alternatively, the request may be a node addition request received by the first current consensus node from a command console of the controller, thereby triggering a node addition process. The controller may be operated by an administrator controlling the respective node, for example, by graphical or coded instructions. For a consensus algorithm with a primary node, such as PBFT, the first current consensus node may be the primary node. The first current consensus node may obtain the transaction request directly from the client device or the controller, or from other consensus nodes forwarding the transaction request. For a consensus algorithm without a host node, such as HoneyBadger BFT, there is no host node, then the first current consensus node is one of a plurality of consensus nodes.

Fig. 7 illustrates a flow diagram for adding nodes in a blockchain network, in accordance with various embodiments. The operations presented below are intended to be illustrative. Depending on the implementation, the exemplary steps may include additional, fewer, or alternative steps performed in various orders or in parallel. Fig. 7 provides an example of adding a node (node X) as a new consensus node in a blockchain network comprising a plurality of current consensus nodes. The blockchain network maintains blockchains. Node X may be added as a primary or backup node to the PBFT-based blockchain network.

Adding nodes in a blockchain network may include at least the following embodiments. In some embodiments, node X may be an inactive consensus node of the blockchain network prior to node addition, and by node addition, node X becomes an active consensus node of the blockchain network. An inactive consensus node may not participate in the consensus verification and thus may be a non-consensus node. In some embodiments, node X may not be part of the blockchain network prior to adding the node, and through node addition, node X joins the blockchain network to become an active consensus node. The active consensus node may participate in the consensus verification.

Fig. 7 shows two parallel timelines, the top timeline carrying the time-dependent state of the local blockchain copy of node X, and the bottom timeline carrying the time-dependent state of the local blockchain copy of one of the current consensus nodes (node Y). Each current consensus node may perform the steps performed by node Y. Between the axes, there are various interactions in terms of message communication and data synchronization. In some embodiments, each current consensus node maintains a list of nodes locally, the list of nodes including one or more of: the method comprises the steps of identifying a node, identifying an IP address of the node and identifying a port number of the node. In one embodiment, the list of nodes is in a world state of a blockchain maintained by the blockchain network.

Along the top axis, node X experiences a transition from being an inactive consensus node of the blockchain network or not being a consensus node of the blockchain network, through a recovery phase (during which node X is not yet an active consensus node and consensus verification cannot be performed), to reaching a normal phase (during which node X is the same as the current consensus node and consensus verification can be performed). Along the bottom axis, node Y undergoes a transition from the normal phase (where consensus verification is performed as usual), to the view change phase (where consensus node state is synchronized), and then back to the normal phase. Also, along the top and bottom axes, the blockchain changes its state when one or more new blocks are added, and thus the blockchain state is updated from B _0 to B _ change, B _ act, and B _ newest. The "block" box on each axis represents the chain of blocks seen or stored by node X or node Y.

In some embodiments, at step 701, the administrative account, external account, or alternate account may initiate a first transaction "add node (AddNode)" to add node X in the blockchain network. The first transaction may be initiated by node X, node Y, or an external device coupled to the blockchain network and broadcast to all currently identified nodes. Node Y may obtain the first transaction from a command console of the client device or controller. At this point, node X may or may not have the original local blockchain copy at B _ 0. Node Y, as well as other current consensus nodes, may perform consensus verification on the first transaction.

In some embodiments, node X may send a first transaction comprising a first request to add node X as a new consensus node of the blockchain network to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction, and add the first transaction into the blockchain in response to the consensus verification of the first transaction being successful.

In some embodiments, one of the plurality of current consensus nodes may send a first transaction comprising a first request to add node X as a new consensus node of the blockchain network to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction, and add the first transaction to the blockchain in response to the consensus verification of the first transaction being successful.

In some embodiments, the first request to add node X as a new consensus node of the blockchain network comprises: a request to change node X from an inactive consensus node of the blockchain network to an active consensus node of the blockchain network, or a request to include node X in the blockchain network as a new consensus node.

In response to the consensus verification of the first transaction being successful, node Y may execute the first transaction. Thus, the first transaction is added to the blockchain, and the local blockchain copy of node Y is located at B _ change. The shaded box attached to the "block" represents a time lag that may exist before the first transaction is added to the blockchain. In addition, node Y may number node X in the node list based on the numbers of a plurality of currently co-identified nodes of the blockchain network. For example, node Y may add the identity of node X to the tail of node Y's node list based on the existing numbers of a number of co-identified nodes in the node list and sequentially number node X. As another example, node Y may reorder the plurality of consensus nodes with node X in the node list according to the node attributes. In one embodiment, prior to node addition, the node list indicates that the blockchain network includes node a (number 0), node B (number 1), node C (number 2), and node Y (number 3); and after adding the node, the node list indicates that the blockchain network includes node B (number 0), node a (number 1), node C (number 2), node Y (number 3), and node X (number 4).

In step 702, node X may synchronize a blockchain that includes the first blockchain and is at B _ change. For example, node X may send one or more synchronization requests to one or more of a plurality of current consensus nodes (e.g., node Y), respectively, to obtain data in the blockchain to download or update the local blockchain copy. In one embodiment, node X may send a synchronization request to node Y to obtain all the data in the blockchain. In another embodiment, node X may send different synchronization requests to different current consensus nodes to obtain different data in the blockchain. For example, if the data of the blockchain is currently stored in 100 blocks, node X may send a synchronization request to node Y to obtain the data in the first 70 blocks and a different synchronization request to node Z (another currently identified node) to obtain the data in the last 30 blocks, so node X may obtain the data in all 100 blocks in total.

As noted, node X may or may not have an original local blockchain copy at B _ 0. In some embodiments, if node X has an original local blockchain copy at B _0, node X may synchronize the blockchain to update the original local blockchain copy (B _0) to obtain a first local blockchain copy (B _ change). In some embodiments, if node X does not have a local blockchain copy, node X may synchronize the blockchain to download or otherwise obtain the first local blockchain copy (B _ change). Thus, node X obtains a first local blockchain copy of node X at B _ change. Node Y may obtain a first transaction that includes a first request to add node X as a new consensus node of the blockchain network. The first transaction may be configured to invoke a blockchain contract (e.g., a startup contract, a system contract) deployed in a blockchain maintained by the blockchain network.

Then, from the first local blockchain copy, node X may determine that the first local blockchain copy includes a first request to add node X as a new consensus node of the blockchain network and initiate a second transaction "activate node" (ActivateNode) accordingly. Node X may send a second transaction including a second request to activate the node to one or more of the plurality of currently identified nodes (e.g., node Y). Node Y may obtain a second transaction from node X that includes a second request to activate node X. Node Y, as well as other current consensus nodes, may perform consensus verification on the second transaction.

In step 703, node X may send a second transaction including a second request for activation of the node to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the second transaction and execute the second transaction for activation of node X in response to the consensus verification of the second transaction being successful.

With successful consensus verification, the second transaction is added to the blockchain and thus the local blockchain copy of node Y is updated to B _ act. The shaded box attached to the "block" represents a possible time lag before the second transaction is added to the blockchain. In response to the consensus verification of the second transaction being successful, node Y may execute the second transaction for activating the node.

After adding the second transaction to the blockchain, node X may synchronize its first local blockchain copy with the blockchain that includes the second blockchain and is located at B act, step 704. Thus, the first local blockchain copy of node X is updated to the second local blockchain copy at node X's B _ act.

At step 705, the current consensus node (e.g., node Y) may initiate a view change by which the local blockchain copy of node Y is updated to B _ newest. In some embodiments, node Y may initiate a view change in response to detecting any of the following conditions: the number of the common identification nodes in the node list is inconsistent with the number of the common identification nodes in the current view; and the common node identification in the node list is inconsistent with the common node identification in the current view. In some embodiments, node Y may initiate a view change in response to receiving a message broadcast by node X to initiate a view change. Node Y may initiate a view change in response to detecting any of the following conditions: the number of the activated common knowledge nodes in the node list is inconsistent with the number of the activated common knowledge nodes in the current view; and the identification of the active consensus node in the node list is inconsistent with the identification of the active consensus node in the current view.

Node Y may perform a view change to cause node X to participate in future consensus verification as a new consensus node for the blockchain network. If instead of entering a view change immediately, the master node of the current view initiates the next round of consensus verification, the consensus verification may fail temporarily, but eventually all consensus nodes may recover after performing the view change.

In some embodiments, the number of copies in the view change is the total number of consensus nodes including node X. That is, n for view change is 1+ the number of current consensus nodes.

At step 706, after multiple current consensus nodes perform view changes for the blockchain, node X may synchronize its second local blockchain copy with the blockchain located at B _ newest. Thus, the second local blockchain copy of node X is updated to the third local blockchain copy at B _ newest of node X.

Thus, node X determines that it has been activated as a consensus node and can participate in the consensus verification as a new consensus node of the blockchain network. That is, the consensus node comprising node X and node Y may perform the next round of consensus verification.

In some embodiments, node X may (1) determine from the checkpoint message that synchronization of the first local blockchain copy, the second local blockchain copy, or the second local blockchain copy has been completed; or (2) send a request to at least some of the plurality of current consensus nodes to query for a current maximum block number (e.g., block height), and determine that synchronization of the first, second, or third local blockchain copy has been completed by finding that the same maximum block number returned from at least some of the plurality of current consensus nodes coincides with the maximum local block number.

In this way, blockchain operation is not interrupted during node addition. Consensus verification may still be performed during the node addition process. Node addition can be accomplished without stopping the blockchain system, thereby eliminating system downtime and reducing synchronization time for introducing new nodes.

Fig. 8 illustrates a flow diagram of a method 800 for adding nodes in a blockchain network, in accordance with various embodiments. In some embodiments, the blockchain network may be based on federation blockchains. In some embodiments, the blockchain network may be based on PBFT.

S801 comprises: a first current consensus node of the block chain network obtains a transaction request for adding a node, and initiates consensus verification on the transaction request for adding the node; after the consensus verification is successful, the current consensus node performs a transaction for adding a node and numbers the node in the local node list based on the number of the current consensus node.

In some embodiments, the transaction request may be a transaction request for invoking a contract. In the transaction request, the address, calling method and input parameters of the invoked smart contract may be specified. For example, the invoked contract may be the above-described initial contract/system contract, the invocation method may be a method for adding a node, and the input parameters may include one or more of the following for the node to be added: identification, IP address and port number.

In some embodiments, the first current consensus node may trigger a node addition process by receiving a transaction request to add a node. For example, as described above, the first current consensus node may trigger the node addition process by receiving a transaction request for adding a node from a client device, or the first current consensus node may trigger the node addition process by receiving a transaction request for adding a node from a command console of a controller. The controller may be operated by an administrator controlling the respective node, for example, by graphical or coded instructions. Alternatively, the first common node may receive the relevant information of the node to be added from the node to be added to trigger the processing of the adding node.

In some embodiments, a transaction request for an add node is propagated to various consensus nodes in a blockchain network based on an underlying point-to-point (P2P) network. After the first current consensus node receives the transaction request for adding a node, the first current consensus node may initiate a consensus verification process as a master node associated with a consensus algorithm with a master node, or as a consensus node associated with a consensus algorithm without a master node. Taking the consensus algorithm with a master node, e.g. PBFT, as an example, the first current consensus node may be the master node and may initiate a consensus verification process for the transaction request for adding a node, i.e. mainly including the pre-prepare, prepare and commit processes in fig. 4 above. Alternatively, the first current consensus node may be a backup node that receives and forwards the transaction request to the primary node to initiate the consensus verification process.

In some embodiments, after the consensus verification is completed, the nodes in the blockchain network locally have the message content in the transaction request for the node to be added and agree on the consensus. Furthermore, if the message content in the transaction request for the add node forms a consensus result with other messages, the message content in the transaction request for the add node has the same sequence of messages on different nodes, i.e. at least the consensus node of Quorum has agreed on the content of the messages in the node add request and the order associated with the messages. The significance of having consensus on the content of the messages in the node addition request and the order associated with the messages is that if the messages contained in the pre-prepared message comprise at least two node addition messages, e.g. node m and node n, respectively, the content of the messages and the order associated with the messages can be fixed by the master node for consensus verification. Subsequently, node m and node n will have the same sequence number in the local node lists of different consensus nodes. That is, this will not occur: in a local node list of the consensus node, the number of the node m is 4, and the number of the node n is 5; and in the local node list of another consensus node, node n is numbered 4 and node m is numbered 5.

In some embodiments, after S801, at least the consensus nodes of the Quorum have agreed on the content of the message in the transaction request including the node addition, as previously described. Furthermore, the current consensus node may locally execute the corresponding contract. For example, the current consensus node may invoke the above-described startup contract/system contract, execute the method specified in the invocation of the startup contract/system contract in a virtual machine such as an EVM, and input the corresponding parameters. In one example, the input parameters may include, for example, an identification of the node to be added, an IP address of the node to be added, a port number of the node to be added, and the like. During execution of the contract, the current consensus node may add the identity of the node to be added to the tail of the list based on the current consensus node in the local node list and sequentially number it. In this way, the list of consensus nodes maintained by at least the current consensus node of Quorum has the relevant information of the nodes to be added sequentially in the same way.

In some embodiments, as described above, the current consensus node may maintain a list of consensus nodes locally, i.e., the local node list described above, which records basic information of all consensus nodes in the current block-link network. In one example, the basic information may include, for example, one or more of the following: and identifying node identification, IP address, port number and the like. Wherein the consensus nodes may be sequentially numbered in the local node list. The common node may have an Identification (ID), which may be an identification that uniquely identifies the node, such as the public key of the node, IP address + port number, etc. In some blockchain entries, the list of consensus nodes may logically exist in a world state. Taking EtherFang, Fabry (Fabric), and Federation blockchain as examples, each node maintains a world state locally, where the latest state of all accounts is available. For example, in an etherhouse, a node may maintain the latest status of all accounts based on the contents of the status tree, transaction tree, and receipt tree in the block.

In some embodiments, since the consensus node has performed several consensus, theoretically, consistency of the list of consensus nodes has been maintained between the current consensus nodes. For example, the current consensus nodes a, b, c and d have local node lists stored in their respective world states, and the current consensus nodes stored in the local node lists of the respective nodes a, b, c and d are four nodes a, b, c and d, and are in the order of a-b-c-d. Then, a, b, c and d are numbered 0, 1, 2 and 3, respectively. Thus, for the added node m, each current consensus node performs S801 based on the locally maintained consensus node list, and the nodes in the local node list of the current consensus node include nodes a, b, c, d, and m, for a total of five nodes, and the same sequence number (e.g., 4) is configured for node m.

In some embodiments, during execution of the contract, the current consensus node may reorder all consensus nodes including the node to be added according to specified attributes, in addition to the current consensus node adding the identity of the node to be added to the tail of the list and numbering the nodes in order based on the current node in the local node list. For example, current consensus nodes execute a method specified in a startup contract/system contract in a virtual machine such as an EVM that defines reordering of all nodes in a local node list according to attributes. For example, the current nodes a, b, c and d have local node lists stored in their respective world states, and the current common nodes stored in the local node lists of the respective nodes a, b, c and d are four nodes a, b, c and d, and are in the order of a-b-c-d. Then, a, b, c and d are numbered 0, 1, 2 and 3, respectively. Thus, for the added node m, each current consensus node performs S801 based on the locally maintained consensus node list, and the nodes of the current consensus node in the local node list include a, b, c, d, m, for a total of five nodes. For example, a method in the initial contract/system contract is to reorder all consensus nodes, including the node to be added, according to a specified attribute public key, i.e., sort the public keys as strings. For example, the result after reordering is a-b-m-c-d with the comparison from the most significant bit and continuing to the least significant bit. Thus, the numbers of a, b, m, c and d are 0, 1, 2, 3 and 4, respectively. It can be seen that the newly added node m has a number of 2, and the numbers of the current nodes c and d change from 2 to 3 and from 3 to 4, respectively.

S803 includes the tile data in the node-to-be-added synchronization tile chain.

In some embodiments, as such, the node to be added joins and becomes one of the nodes in the blockchain network. If the node to be added is added to the blockchain network and becomes a consensus node, i.e., subsequently participates in the consensus verification process, the node to be added may need to obtain all blockchain data and a list including all consensus nodes in the blockchain network. When the node to be added obtains all tile data for the tile chain, each transaction may be performed in the local state machine in order from the starting tile to the latest tile, thereby updating the local world state. Since the transaction from the starting block to the latest block performed by the node to be added is the same as the transaction from the starting block to the latest block performed by other common nodes, the world state of the node to be added can be kept consistent with the world states of other common nodes. In this way, after the node to be added becomes the consensus node, the node to be added can be in the same initial state as other current nodes to perform subsequent transactions, and the world state of the node to be added is kept consistent with the world states of other current nodes.

In some embodiments, to obtain all tile data for a tile chain, the node to be added may broadcast a synchronization request to some or all current nodes to obtain tiles from the current nodes. In one embodiment, the node to be added may send a synchronization request to the current node to obtain all tile data from the current node.

Furthermore, in some embodiments, to achieve high efficiency, similar to the P2P propagation principle, the node to be added may broadcast synchronization requests to obtain different tiles to different current nodes, and the sum of the synchronization requests is all the tiles to be obtained. For example, there are ten chunks from 0 to 9 in total, and the node to be added may request to obtain chunks 0-3 from current node 1, chunks 4-6 from current node 2, and chunks 7-10 from current node 3. In this way, all blocks can be composed after the node to be added has obtained different blocks from different current nodes.

In some embodiments, all blocks generally include every block from the starting block to the newly generated block. The node to be added may use the checkpoint message to determine whether synchronization of the chunks is complete.

In some embodiments, in the three stages of PBFT processing described above, when a copy sends a message or receives messages sent by other nodes (including prepare, commit messages), each copy is recorded in a message log in the local memory of the copy. As the PBFT progresses, the log will take up a large amount of memory. Thus, in order to save memory space, it is necessary to perform garbage collection, i.e., clearing the log when the copy completes the proposed execution. One way is that whenever a copy executes an offer, the copy is broadcast to other nodes to see if the log can be cleared to achieve a network wide consensus. Each copy is also broadcast to the other copies upon receiving the broadcast. If an acknowledgement is received from a different node of the Quorum, the nodes will delete the message records in the local log corresponding to the offer. Alternatively, if the copy performs K offers, it broadcasts to other nodes to see if the log can be cleared to achieve a network wide consensus. Each copy is also broadcast to the other copies upon receiving the broadcast. If acknowledgements are received for different nodes of the Quorum, these nodes will delete the message records in the local log corresponding to the K proposals. The above delete log message is a CHECKPOINT message in the format < CHECKPOINT (CHECKPOINT), n, d, i >. Where n is the minimum sequence number that the current node desires to retain, d is the message digest that it desires to retain, and i is the copy number of the outgoing checkpoint message. The check point message sent by the copy and the received check point message are recorded in the message log. If copy i receives from different nodes Quorum-1 valid checkpoint messages and the checkpoint message sent by the copy itself, then the checkpoint message for < n, d > in the log reaches Quorum, and then clears all messages before n (including prepare, commit messages, and may also include checkpoint messages).

In some embodiments, it may be determined whether the above-mentioned node to be added has completed synchronization of the tile data by using a checkpoint message. In one example, a node to be added may receive Quorum-1 valid checkpoint messages sent by different nodes, where n coincides with the largest n of the node to be added to synchronize blockchain data, and may determine that synchronization of blockchain data is complete.

Furthermore, in some embodiments, the checkpoint message may also directly indicate the current latest block number. The node to be added can receive the Quorum-1 valid check point messages sent by different nodes, wherein the specified current latest block number is consistent with the maximum block number in the blocks synchronized by the node to be added, and the synchronization of all the blocks can be determined to be completed.

In some embodiments, the node to be added may instead send a request to other nodes to query the current maximum block number and determine that synchronization of the block data is complete by finding that the same maximum block number fed back from most nodes is consistent with the maximum local block number.

In some embodiments, S801 and S803 are not in strict order and may be performed asynchronously or in parallel.

S805 includes a current consensus node to perform a view change.

After the current consensus node performs a transaction for adding a node, the current consensus node may update a local node list S801. In the current view, the original nodes participating in consensus verification and their order are not changed. Thus, after the current consensus node performs the transaction of adding the node, they can detect that the number of consensus nodes in the local consensus node list is inconsistent with the number of consensus nodes in the current view, or that the consensus node identifications in the local consensus node list are inconsistent with the consensus node identifications in the current view. Thus, the current consensus node may initiate a view change.

In some embodiments, after the node to be added has synchronized the blockchain data of the blockchain, the node may broadcast a message to the blockchain network for initiating a view change indicating that the node to be added has completed synchronization, has the capability to join the blockchain network and act as a consensus node, and requests to initiate a view change. Thus, the current consensus node may initiate the view change process upon receiving the message.

In some embodiments, R in the view change process (i.e., the number of copies in the view change process) is the total number of consensus nodes including the node to be added, i.e., the number of nodes including the node to be added in the local node list.

In some embodiments, similar to the foregoing, the current consensus node may broadcast a message < view change, v +1, n, C, P, i > to other replica nodes, where n is the number of most recent stable checkpoints, C is a set of 2f +1 verified checkpoint messages, and P is a set of prepare and prepare messages for which the current replica node has not completed processing.

In some embodiments, assume that the current node includes nodes 0, 1, 2, and 3 and the node to be added is node 4. Node 0 is the primary node in, for example, the PBFT, and nodes 1, 2, and 3 are backup nodes in, for example, the PBFT. The new master node number may be calculated by p ═ v) mod | R |. For example, if p is 1, the new master node is node b. Here, the local node list of R includes the number of nodes to be added. For example, there are a total of four current consensus nodes, numbered 0, 1, 2 and 3, respectively. Each current consensus node records the numbers of the four nodes 0, 1, 2 and 3 in the local node list. In this case, R ═ 4. In the example of performing S801 to S805, each current consensus node may number the to-be-added node sequentially based on the numbers of the nodes already existing in the local node list, that is, may number the to-be-added node sequentially to 4. In this case, R becomes 5. As described above, the view number in the view change process is increased, i.e., from v to v + 1.

In some embodiments, when the contract-for-creation/system contract is invoked in S801, the invoked method is a method that adds a node. And after the consensus verification is completed, the current consensus node executes the transaction for adding the node, and numbers the node to be added based on the number of the existing consensus node in the local node list. The added node may be initialized in the local node list to a default inactive state (e.g., in an inactive state). Furthermore, the node to be added may attempt to activate itself by initiating a transaction request, and the current consensus node may also change the newly added node from an inactive state to an active state by performing a corresponding transaction after consensus is reached.

Thus, between S803 and S805, the method further comprises: after the block data in the node synchronization block chain is added, the node to be added sends a transaction request for activating the node to the block chain network, and after the current consensus node performs consensus verification, the transaction request for activating the node is executed.

In some embodiments, after the node to be added completes synchronization of all tile data, a transaction request for activating the node may be sent to the blockchain network. In one example, the node to be added may send a transaction request to activate the node to the blockchain network through its own account. Similar to the transaction request for adding a node described above, the transaction request for activating a node may also be a transaction that invokes a contract. Accordingly, the method for activating a node may already exist in the startup contract/system contract. The transaction request for activating a node may indicate a method in the invoked startup contract/system contract and may include parameters such as node identification, node IP address, node port number, and the like.

In some embodiments, similarly, a transaction request for an activation node may be propagated to each consensus node in a blockchain network based on an underlying point-to-point (P2P) network. The current consensus node may initiate a consensus verification of the transaction request for the activation node. Taking the consensus algorithm with a master node, such as PBFT for example, the first current consensus node may be the master node and may initiate a consensus verification process for transaction requests including transaction requests for activation of the node, i.e. mainly including the pre-prepare, prepare and commit process in fig. 4 above.

In some embodiments, after completion of consensus verification, at least the consensus nodes of the Quorum in the blockchain network have message content in the transaction request locally for the add node and consensus is reached. In addition, the current consensus node may locally invoke the corresponding contract to execute. For example, the current consensus node may invoke the above-described startup contract/system contract, execute a method specified in the invoked startup contract/system contract in a virtual machine such as an EVM, and input corresponding parameters. In one example, the input parameters include the node identification, node IP address, node port number, and the like. During contract execution, the current consensus node configures the state of the node in the local node list that is in the inactive state as active. In addition, the current consensus node detects that the number of the active consensus nodes in the local consensus node list is inconsistent with the number of the active consensus nodes in the current view, or detects that the identities of the active consensus nodes in the local consensus node list are inconsistent with the identities of the active consensus nodes in the current view. Thus, the current consensus node may initiate a view change.

In some embodiments, the transaction request for the activation node will form a new block after passing consensus verification (a block may also include transactions other than the transaction for the activation node). After consensus verification, the newly generated tile exists at least on the current consensus node of the Quorum and not in the newly activated node (i.e., the node just added). This is because the just activated node did not participate in consensus verification prior to activation. Therefore, after S801, the node to be added may continue to send synchronization requests to some or all current nodes, thereby obtaining tiles from the current nodes. In this way, the node to be added can obtain a block containing the transaction request for activating the node.

S807 includes: after the view change is complete, the node participates in consensus verification.

In some embodiments, after the view change is completed, each consensus node including the node to be added locally has the same list of node numbers and has the same tile data, so that the node to be added can participate in consensus verification, i.e., perform consensus verification jointly with the current consensus node. In this way, the node addition processing is completed.

The method 800 may be further broken down into a method 900 (fig. 9A) performed by a currently co-located node of the blockchain network maintaining the blockchain and a method 910 (fig. 9B) performed by a node to be added to the blockchain network.

Fig. 9A and 9B illustrate a flow diagram of a method for adding nodes in a blockchain network, in accordance with various embodiments. Fig. 9A shows steps performed by a current consensus node of a blockchain network that maintains blockchains, and the steps may be referred to as a method 900. Fig. 9B shows steps performed by a node to be added to a blockchain network, and the steps may be referred to as a method 910.

Adding nodes in a blockchain network may include at least the following embodiments. In some embodiments, the node to be added may be an inactive consensus node of the blockchain network before the node addition, and by the node addition, the inactive consensus node becomes an active consensus node of the blockchain network (i.e., a new consensus node of the blockchain network). An inactive consensus node may not participate in the consensus verification and thus may be a non-consensus node. In some embodiments, the node to be added may not be part of the blockchain network prior to the addition of the node, and by the addition of the node, the node is added to the blockchain network as an active consensus node. The active consensus node may participate in the consensus verification.

Referring to fig. 9A, the method 900 may be performed by an apparatus, device, or system for adding a node, such as a currently co-located node of a blockchain network (e.g., the blockchain node of fig. 1-3, the currently co-located node of fig. 7 or 10), in a blockchain network. The current consensus node may be an existing consensus node prior to the node addition. The current consensus node may be a primary or backup node of the PBFT-based blockchain network. The current consensus node may be implemented by a system or device (e.g., computer, server) including various hardware machines and/or software. For example, a system or device may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the method 900.

The operations of method 900 presented below are intended to be illustrative. Depending on the implementation, method 900 may include additional, fewer, or alternative steps performed in various orders or in parallel. One or more of the following steps, e.g., blocks S903-S905, may be optional. Further details of the method 900 may be found in fig. 1-8 and 10 and the related description. The steps described with reference to fig. 1-8 and 10 for adding nodes in a blockchain network are included in the method 900.

Block S901 includes: a current consensus node of the blockchain network obtains a first transaction that includes a first request to add a node as a new consensus node of the blockchain network. In some embodiments, the first transaction is configured to invoke a blockchain contract deployed in a blockchain maintained by the blockchain network. In some embodiments, the blockchain contract comprises an initial contract or a system contract.

In some embodiments, the current consensus node obtaining the first transaction comprises: the first transaction is obtained from a command console of the client device or the controller.

Block S902 includes: the first transaction is executed in response to successful consensus verification of the first transaction, and the nodes are numbered in the node list based on the numbers of the plurality of current consensus nodes in the blockchain network. In some embodiments, the current consensus node maintains a list of nodes locally, the list of nodes including one or more of: identifying a node, an IP address and a port number of the node; and sequentially numbering the plurality of consensus nodes in the node list. In some embodiments, the list of nodes is in a world state of a blockchain maintained by the blockchain network.

In some embodiments, numbering nodes in the list of nodes based on the number of a plurality of current consensus nodes in the blockchain network comprises: adding the identifier of the node to the tail part of the node list based on the numbers of a plurality of common nodes in the node list, and numbering the nodes in sequence; or reordering the plurality of consensus nodes and the nodes in a node list according to the node attributes.

Block S903 includes: a second transaction is obtained from the node that includes a second request to activate the node.

Block S904 includes: consensus verification is performed on the second transaction.

Block S905 includes: in response to the consensus verification of the second transaction being successful, the second transaction for activating the node is performed.

Block S906 includes: a view change is performed to cause the node to participate in future consensus verifications as a new consensus node of the blockchain network. In some embodiments, the number of copies in the view change is the total number of consensus nodes that include the node.

In some embodiments, performing the view change includes initiating the view change in response to detecting any of the following conditions: the number of the common identification nodes in the node list is inconsistent with the number of the common identification nodes in the current view; and the common node identification in the node list is inconsistent with the common node identification in the current view.

In some embodiments, performing the view change comprises: the view change is initiated in response to receiving a message broadcast by the node to initiate the view change.

In some embodiments, performing the view change includes initiating the view change in response to detecting any of the following conditions: the number of the activated common knowledge nodes in the node list is inconsistent with the number of the activated common knowledge nodes in the current view; and the identification of the active consensus node in the node list is inconsistent with the identification of the active consensus node in the current view.

Referring to fig. 9B, the method 910 may be performed by an apparatus, device, or system for adding a node, such as a node to be added to a blockchain network (e.g., the node to be added of fig. 7 or 10), in a blockchain network. Nodes may be added to make them the primary or backup nodes of the PBFT-based blockchain network.

The nodes to be added may be implemented by a system or device (e.g., computer, server) including various hardware machines and/or software. For example, a system or device may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the method 910.

The operations of method 910 presented below are intended to be illustrative. Depending on the implementation, the method 910 may include additional, fewer, or alternative steps performed in various orders or in parallel. One or more of the following steps, such as blocks S914-S915, may be optional. Further details of the method 910 may be found in fig. 1-8 and 10 and the related description. The step of adding a node in the blockchain network described with reference to fig. 1 to 8 and 10 is included in the method 910.

Block S911 includes: a blockchain is synchronized to nodes to be added to a blockchain network to obtain a first local blockchain copy, wherein the blockchain network maintains the blockchain and includes a plurality of current consensus nodes. In some embodiments, the synchronization blockchain comprises: one or more synchronization requests are respectively sent to one or more of the plurality of current consensus nodes to obtain data in the blockchain.

In some embodiments, prior to the synchronization blockchain, the method further comprises: a first transaction including a first request to add a node as a new consensus node of the blockchain network is sent to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction, and the first transaction is added to the blockchain in response to the consensus verification of the first transaction being successful.

In some embodiments, prior to the synchronization blockchain, the method further comprises: one of the plurality of current consensus nodes sends a first transaction comprising a first request to add the node as a new consensus node of the blockchain network to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the first transaction and to add the first transaction to the blockchain in response to the consensus verification of the first transaction being successful.

Block S912 includes: in response to determining that the first local blockchain copy includes a first request to add a node as a new consensus node of the blockchain network, sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes. In some embodiments, sending a second transaction comprising a second request to activate a node to one or more of the plurality of current consensus nodes comprises: the method further includes sending a second transaction including a second request for the activation node to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification on the second transaction, and executing the second transaction for the activation node in response to the consensus verification of the second transaction being successful.

In some embodiments, the first request to add the node as a new consensus node of the blockchain network comprises: a request to change a node from an inactive consensus node of the blockchain network to an active consensus node of the blockchain network.

In some embodiments, the first request to add the node as a new consensus node of the blockchain network comprises: a request to include the node into the blockchain network as a new consensus node.

Block S913 includes: after adding the second transaction to the blockchain, the first local blockchain copy is synchronized with the blockchain to obtain a second local blockchain copy.

Block S914 includes: after the plurality of current consensus nodes perform the view change for the blockchain, the second local blockchain copy is synchronized with the blockchain to obtain a third local blockchain copy.

Block S915 includes: and the new consensus node is used as a new consensus node of the block chain network and participates in consensus verification. In some embodiments, the process of adding a node as a new consensus node of the blockchain network does not disrupt the operation of the blockchain network.

In some embodiments, the method further comprises: determining, by the checkpoint message, that synchronization of the first local blockchain copy, the second local blockchain copy, or the second local blockchain copy has been completed.

In some embodiments, the method further comprises: sending a request to at least some of the plurality of current consensus nodes to query for a current maximum block number, and determining that synchronization of the first, second, or third local block chain copy has been completed by finding that the same maximum block number returned from at least some of the plurality of current consensus nodes coincides with the maximum local block number.

Fig. 10 illustrates a block diagram for implementing a blockchain network, in accordance with various embodiments. As shown, prior to node addition, the blockchain network may include a plurality of currently co-identified nodes 1003 (e.g., 1003a, 1003b, 1003c, 1003d), and the node to add 1002 will be added to the blockchain network. Any one of the current consensus nodes may be a first current consensus node for receiving a first transaction. Here, node 1003a is designated as the first current consensus node. After the node addition is complete, the blockchain network may include nodes 1002, 1003a, 1003b, 1003c, and 1003d, all as common nodes. In some embodiments, the blockchain network may be PBFT based, and in each view, one of its nodes may be the primary node and the remaining nodes are backup nodes.

In some embodiments, the blockchain system includes a node to be added 1002 and a plurality of current consensus nodes 1003. The first current consensus node 1003a is configured to obtain a transaction request for adding node 1002 and initiate a consensus verification for the transaction request for adding node 1002 to the blockchain network. Upon successful consensus verification, the current consensus nodes 1003 are each configured to perform a transaction to add node 1002 and number node 1002 in the local node list based on the number of the current consensus node. The node to be added 1002 is configured to synchronize tile data in the tile chain. The current consensus node 1003 is configured for performing a view change. The node 1002 is configured to participate in consensus verification for blockchains after the view change is complete.

In some embodiments, the transaction request to add a node comprises a transaction request to invoke a contract. In some embodiments, the invoked contract comprises a startup contract or a system contract. In some embodiments, obtaining the transaction request for adding a node by the first current consensus node 1003a includes: the first current consensus node 1003a obtains a transaction request for adding a node from a client device; or the first current consensus node 1003a gets the transaction request for the add node from the command console of the controller.

In some embodiments, the current consensus nodes 1003 are each configured to locally maintain a list of nodes that includes one or more of: and the node comprises a consensus node identifier, a consensus node IP address and a consensus node port number, wherein the consensus node is sequentially numbered in the node list. In one embodiment, the list of nodes maintained locally by the consensus node is in a world state.

In some embodiments, to perform the transaction for adding a node and number the node based on the number of the current consensus node in the local node list, the current consensus nodes 1003 are each configured to perform the transaction for adding a node, and add the identity of the node to be added to the tail of the list based on the current consensus node in the local node list and number the node to be added sequentially; or configured to perform a transaction for adding a node and reorder all consensus nodes including the node to be added according to specified attributes.

In some embodiments, to synchronize tile data in a chain of tiles, the to-be-added node 1002 is configured to send a synchronization request to the current node to obtain all tile data from the current node; or configured to send synchronization requests to different current nodes to obtain different chunks.

In some embodiments, the to-be-added node 1002 is configured to determine that the synchronization block data has been completed by a checkpoint message; or configured to transmit a request for inquiring a current maximum block number to other nodes and determine that the synchronized block data is completed by finding that the same maximum block number fed back from most nodes coincides with the maximum local block number.

In some embodiments, any current consensus node 1003 may be configured to initiate a view change in response to detecting any of the following conditions: the number of the common consensus nodes in the local common consensus node list is inconsistent with the number of the common consensus nodes in the current view; and the common node identification in the local common node list is inconsistent with the common node identification in the current view.

In some embodiments, any current consensus node 1003 may be configured to initiate a view change in response to receiving a message for initiating a view change broadcast by the to-be-added node.

In some embodiments, after the to-be-added node 1002 synchronizes tile data in the blockchain, the to-be-added node 1002 is configured to send a transaction request for the activation node to the blockchain network, and the current consensus node 1003 is configured to execute the transaction request for the activation node after performing consensus verification.

In some embodiments, any current consensus node 1003 may be configured to initiate a view change in response to detecting any of the following conditions: the number of the activated common consensus nodes in the local common consensus node list is inconsistent with the number of the activated common consensus nodes in the current view; and the identification of the activated consensus node in the local consensus node list is inconsistent with the identification of the activated consensus node in the current view.

In some embodiments, the number of copies in the view change is the total number of consensus nodes including the node to be added.

Fig. 11A illustrates a block diagram of an apparatus 1100 for adding nodes in a blockchain network, in accordance with some embodiments. Apparatus 1100 may be an example of an implementation of one or more components of a node (e.g., a blockchain node of fig. 1-3, a currently co-aware node of fig. 7 or 10). The node may be a primary or backup node of a PBFT-based blockchain network. One or more steps of method 800 and method 900 may be performed by apparatus 1100.

The apparatus 1100 may be implemented in a computer system or device comprising one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the steps of the method (e.g., the method 800 or 900) described above. The apparatus 1100 may include various units/modules corresponding to instructions (e.g., software instructions).

In some embodiments, apparatus 1100 may comprise: a first obtaining module 1101 that obtains a first transaction comprising a first request to add a node as a new consensus node of a blockchain network; a first execution module 1102, in response to successful consensus verification for the first transaction, executing the first transaction and numbering nodes in a node list based on numbers of a plurality of current consensus nodes in the blockchain network; a second obtaining module 1103 that obtains, from the node, a second transaction including a second request for activating the node; a first performing module 1104 that performs consensus verification on the second transaction; a second execution module 1105, responsive to the consensus verification for the second transaction being successful, executing the second transaction for activating the node; and a second performing module 1106 that performs view changes to engage the node as a new consensus node of the blockchain network in future consensus verifications. One or more modules (e.g., the second obtaining module 1103, the first performing module 1104, the second performing module 1105) are optional.

Fig. 11B illustrates a block diagram of an apparatus 1110 for adding nodes in a blockchain network, in accordance with some embodiments. The apparatus 1110 may be an example of an implementation of one or more components to be added to a node in a blockchain network (e.g., the node to be added of fig. 7 or 10). Nodes may be added to become the primary or backup nodes of the PBFT-based blockchain network. One or more steps of method 800 and method 910 may be performed by apparatus 1110.

The apparatus 1110 may be implemented in a computer system or device comprising one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the steps of the method (e.g., the method 800 or 910) described above. The apparatus 1110 may include various units/modules corresponding to instructions (e.g., software instructions).

In some embodiments, the apparatus 1110 may comprise: a first synchronization module 1111 that synchronizes the blockchain to obtain a first local blockchain copy, wherein the blockchain network maintains the blockchain and comprises a plurality of current consensus nodes; a sending module 1112 that sends a second transaction including a second request to activate a node to one or more of the plurality of current consensus nodes in response to determining that the first local blockchain copy includes a first request to add the node as a new consensus node of the blockchain network; a second synchronization module 1113 that synchronizes the first local blockchain copy with the blockchain to obtain a second local blockchain copy after the second transaction is added to the blockchain; and a third synchronization module 1114 that synchronizes the second local blockchain copy with the blockchain to obtain a third local blockchain copy after the view change is performed for the blockchain by the plurality of current consensus nodes; and a participation module 1115 participating in consensus verification as a new consensus node of the blockchain network. One or more modules (e.g., third sync module 1114, participation module 1115) are optional.

The techniques described herein may be implemented by one or more special-purpose computing devices. A special-purpose computing device may be a desktop computer system, a server computer system, a portable computer system, a handheld device, a network device, or any other device or combination of devices that contain hardwired and/or program logic to implement the techniques. A special purpose computing device may be implemented as a personal computer, laptop computer, cellular telephone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet, wearable device, or a combination thereof. The computing device is typically controllable and coordinatable by operating system software. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file systems, networking, I/O services, and provide user interface functions, such as a graphical user interface ("GUI"), among others. The various systems, apparatus, storage media, modules, and units described herein can be implemented in one or more computing chips of a special-purpose computing device or one or more special-purpose computing devices. In some embodiments, the instructions described herein may be implemented in a virtual machine on a special purpose computing device. When executed, the instructions may cause a special-purpose computing device to perform various methods described herein. The virtual machine may comprise software, hardware, or a combination thereof.

FIG. 12 illustrates a block diagram of a computer system in which any of the embodiments described herein may be implemented. The system 1200 may be implemented in any component of the environments, systems, or devices shown in fig. 1-7, 10, 11A, and 11B. One or more of the methods illustrated in fig. 8, 9A, and 9B may be performed by one or more embodiments of computer system 1200.

Computer system 1200 can include a bus 1202 or other communication mechanism for communicating information, one or more hardware processors 1204 coupled with bus 1202 for processing information. Hardware processor 1204 may be, for example, one or more general purpose microprocessors.

Computer system 1200 may also include a main memory 1206, such as a Random Access Memory (RAM), cache, and/or other dynamic storage device, coupled to bus 1202 for storing information and instructions to be executed by processor 1204. Main memory 1206 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor(s) 1204. When stored in a storage medium accessible to processor(s) 1204, such instructions render computer system 1200 into a special-purpose machine that is customized to perform the operations specified in the instructions. Computer system 1200 may further include a Read Only Memory (ROM)1208 or other static storage device coupled to bus 1202 for storing static information and instructions for processor 1204. A storage device 1210, such as a magnetic disk, optical disk, USB thumb drive (flash drive), etc., can be provided and coupled to bus 1202 for storing information and instructions.

Computer system 1200 can implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and/or program logic that in combination with the computer system cause computer system 1200 to be a special-purpose machine or program computer system 1200 to be a special-purpose machine. According to one embodiment, the operations, methods, and processes described herein are performed by computer system 1200 in response to processor 1204 executing one or more sequences of one or more instructions contained in main memory 1206. Such instructions may be read into main memory 1206 from another storage medium, such as storage device 1210. Execution of the sequences of instructions contained in main memory 1206 causes processor 1204 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

As used herein, the term "non-transitory medium" and similar terms refer to media that store data and/or instructions that cause a machine to operate in a specific manner, the media not including transitory signals.

For example, network interface 1218 may be AN Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line.

Computer system 1200 can send messages and receive data, including program code, through the network(s), network link(s) and network interface 1218. In the Internet example, a server might transmit a requested code for an application program through the Internet, an ISP, local network and network interface 1218.

The received code may be executed by processor 1204 as it is received, and/or stored in storage device 1210, or other non-volatile storage for later execution.

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and implemented fully or partially automatically by, code modules executed by one or more computer systems or computer processors, including computer hardware. The processes and algorithms may be implemented in part or in whole in application specific circuitry.

The various features and processes described above may be used independently of one another or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this document. Additionally, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be performed in other appropriate orders. For example, described blocks or states may be performed in an order different than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. Examples of blocks or states may be performed in series, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed embodiments. Examples of the systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged compared to the disclosed embodiments.

Various operations of the methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such a processor may constitute a processor-implemented engine for performing one or more operations or functions described herein.

Similarly, the methods described herein may be implemented at least in part by a processor, where a particular processor is an example of hardware. For example, at least some of the operations of the method may be performed by one or more processors or processor-implemented engines. Further, the one or more processors may also be operable to support performance of related operations in a "cloud computing" environment, or to operate as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a set of computers (as an example of machines including processors), which may be accessed via a network (e.g., the internet) via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs)).

The performance of certain operations may be distributed among the processors, not only residing in a single machine, but also being deployed across multiple machines. In some embodiments, the processor or processor-implemented engine may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

In this document, multiple instances may implement a component, an operation, or a structure described as a single instance. Although the individual operations of one or more methods are illustrated and described as separate operations, one or more of the separate operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in the configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the subject matter herein.

Although the summary of the subject matter has been described with reference to specific embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of the embodiments herein. The detailed description is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. Furthermore, the use of relational terms such as "first," "second," "third," and the like, as used herein, do not denote any order, importance, or importance, but rather are used to distinguish one element from another. Furthermore, the terms "a," "an," and "a" herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item. In addition, herein, "or" is inclusive rather than exclusive, unless explicitly stated otherwise or indicated otherwise by context. Thus, herein, "a or B" means "A, B or both," unless expressly indicated otherwise or indicated otherwise by context. Also, "and" is both conjunctive and plural, unless expressly indicated otherwise or indicated otherwise by context. Thus, herein, "a and B" means "a and B, collectively or individually," unless expressly specified otherwise or indicated otherwise by context.

Claims (30)

1. A computer-implemented method for adding nodes in a blockchain network, comprising:

obtaining, by a current consensus node in the blockchain network, a first transaction comprising a first request to add the node as a new consensus node of the blockchain network;

in response to a successful consensus verification of the first transaction, performing the first transaction and numbering a plurality of current consensus nodes in the blockchain network in a list of nodes based on the numbers of the nodes; and

performing a view change to cause the node to participate in future consensus verification as the new consensus node of the blockchain network.

2. The method of claim 1, wherein the first transaction is configured to invoke a blockchain contract deployed in a blockchain maintained by the blockchain network.

3. The method of claim 2, wherein the blockchain contract comprises a startup contract or a system contract.

4. The method of any of claims 1-3, wherein the current consensus node obtaining the first transaction comprises:

the first transaction is obtained from a command console of a client device or controller.

5. The method of any one of claims 1-4, wherein:

the current consensus node maintains the node list locally, the node list including one or more of: identifying a node, an IP address and a port number of the node; and

sequentially numbering the plurality of consensus nodes in the node list.

6. The method of any of claims 1-5, wherein the list of nodes is in a world state of a blockchain maintained by the blockchain network.

7. The method of any of claims 1-6, wherein numbering the nodes in a node list based on the numbers of a plurality of current consensus nodes in the blockchain network comprises:

adding the identification of the node to the tail part of the node list based on the numbers of the plurality of common nodes in the node list, and numbering the nodes in sequence; or

Reordering the plurality of consensus nodes and the nodes in the node list according to a node attribute.

8. The method according to any of claims 1-7, wherein the performing a view change comprises initiating the view change in response to detecting any of the following conditions:

the number of the common nodes in the node list is inconsistent with the number of the common nodes in the current view; and

and the common identification node identification in the node list is inconsistent with the common identification node identification in the current view.

9. The method according to any of claims 1-8, wherein the performing a view change comprises: the view change is initiated in response to receiving a message broadcast by the node to initiate the view change.

10. The method of any of claims 1-9, further comprising, after numbering the nodes in a list of nodes and before the performing a view change:

obtaining, from the node, a second transaction comprising a second request to activate the node;

performing consensus verification of the second transaction; and

in response to a consensus verification of the second transaction being successful, performing the second transaction for activating the node.

11. The method of claim 10, wherein the performing the view change comprises initiating the view change in response to detecting any of the following conditions:

the number of the activated common knowledge nodes in the node list is inconsistent with the number of the activated common knowledge nodes in the current view; and

the identification of the active consensus node in the node list is inconsistent with the identification of the active consensus node in the current view.

12. The method of any of claims 1-11, wherein the number of copies in the view change is a total number of consensus nodes including the node.

13. A system for adding nodes in a blockchain network, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-12.

14. An apparatus for adding nodes in a blockchain network, comprising a plurality of modules for performing the method of any of claims 1-12.

15. A non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform the method of any one of claims 1-12.

16. A computer-implemented method for adding nodes in a blockchain network, comprising:

synchronizing a blockchain to be added to the nodes in the blockchain network to obtain a first local blockchain copy, wherein the blockchain network maintains the blockchain and includes a plurality of current consensus nodes;

in response to determining that the first local blockchain copy includes a first request to add the node as a new consensus node of the blockchain network, sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes; and

after adding the second transaction to the blockchain, synchronizing the first local blockchain copy with the blockchain to obtain a second local blockchain copy.

17. The method of claim 16, further comprising, prior to the synchronization blockchain:

sending a first transaction comprising the first request to add the node as the new consensus node of the blockchain network to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification of the first transaction, and adding the first transaction into the blockchain in response to the consensus verification of the first transaction being successful.

18. The method of claim 16, further comprising, prior to the synchronization blockchain:

one of the plurality of current consensus nodes sends a first transaction to one or more of the plurality of current consensus nodes including the first request to add the node as the new consensus node of the blockchain network for the plurality of current consensus nodes to perform consensus verification of the first transaction, and adds the first transaction into the blockchain in response to the consensus verification of the first transaction being successful.

19. The method of any of claims 16-18, wherein the synchronization blockchain comprises:

sending one or more synchronization requests to one or more of the plurality of current consensus nodes, respectively, to obtain data in the blockchain.

20. The method of any of claims 16-19, wherein sending a second transaction including a second request to activate the node to one or more of the plurality of current consensus nodes comprises:

sending the second transaction including the second request to activate the node to one or more of the plurality of current consensus nodes for the plurality of current consensus nodes to perform consensus verification of the second transaction, and in response to the consensus verification of the second transaction being successful, performing the second transaction to activate the node.

21. The method according to any one of claims 16-20, further comprising:

after the plurality of current consensus nodes perform the view change for the blockchain, synchronizing the second local blockchain copy with the blockchain to obtain a third local blockchain copy.

22. The method of claim 21, further comprising:

and the new consensus node as the block chain network participates in consensus verification.

23. The method according to any one of claims 21-22, further comprising: determining, by a checkpoint message, that synchronization of the first, second, or third local blockchain copies has been completed.

24. The method according to any one of claims 21-22, further comprising: sending a request to at least some of the plurality of current consensus nodes to query for a current maximum block number, and determining that synchronization of the first, second, or second local block-chain copy has been completed by finding that the same maximum block number returned from the at least some of the plurality of current consensus nodes coincides with a maximum local block number.

25. The method of any one of claims 16-24, wherein:

the process of adding the node as the new consensus node of the blockchain network does not cause any interruption to the operation of the blockchain network.

26. The method of any of claims 16-25, wherein adding the node as the first request of the new consensus node of the blockchain network comprises:

a request to change the node from an inactive consensus node of the blockchain network to an active consensus node of the blockchain network.

27. The method of any of claims 16-25, wherein adding the node as the first request of the new consensus node of the blockchain network comprises:

including the node in the blockchain network as a request for the new consensus node.

28. A system for adding nodes in a blockchain network, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 16-27.

29. An apparatus for adding nodes in a blockchain network, comprising a plurality of modules for performing the method of any of claims 16-27.

30. A non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform the method of any one of claims 16-27.