Systems and methods for deleting nodes in a blockchain network

Abstract

Methods, systems, and apparatuses for deleting nodes in a blockchain network are provided, including computer programs encoded on a computer storage medium. One method includes: a first consensus node in the blockchain network receiving a transaction including a request to delete a second consensus node in the blockchain network; in response to successful consensus verification of the transaction, executing the transaction and sequentially numbering multiple remaining consensus nodes in the blockchain network, excluding the second consensus node, in a node list; and implementing a view change to enable the remaining consensus nodes to participate in future consensus verification.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese application CN201910838733.5, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application generally relates to systems and methods for deleting nodes in a blockchain network. Background Technology

[0004] Blockchain technology can be built on transport networks (e.g., peer-to-peer networks). Network nodes in these networks can authenticate and store data based on a chained data structure and generate and update data based on distributed consensus algorithms. In some cases, it may be necessary to delete nodes in such blockchain networks. Therefore, it is desirable to provide a method for deleting nodes in a blockchain network.

[0005] Existing technologies for deleting nodes often disrupt the normal operation of the blockchain. In one example, current methods for deleting a node in a blockchain network require stopping the entire blockchain system to remove the node and then restarting the system afterward. As a result, the entire system must undergo downtime. Summary of the Invention

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

[0007] According to some embodiments, a computer-implemented method for deleting a node in a blockchain network includes: a first consensus node of the blockchain network receiving a transaction including a request to delete a second consensus node in the blockchain network; in response to successful consensus verification of the transaction, executing the transaction and sequentially numbering a plurality of remaining consensus nodes in the blockchain network, excluding the second consensus node, in a node list; and performing a view change to enable the remaining consensus nodes to participate in future consensus verification. In some embodiments, the node to be deleted may be an active consensus node in the blockchain network before the node deletion, and through node deletion, the node becomes an inactive consensus node in the blockchain network. In some embodiments, the node to be deleted may be part of the blockchain network before the node deletion, and through node deletion, the node is removed from the blockchain network.

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

[0009] In some embodiments, a blockchain contract includes a genesis contract or a system contract.

[0010] In some embodiments, the first consensus node obtains a transaction, including obtaining the transaction from the command console of a client device or controller.

[0011] In some embodiments, the first consensus node maintains a node list locally, which includes one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number; and before sequentially numbering the remaining consensus nodes in the blockchain network other than the second consensus node in the node list, sequentially numbering all consensus nodes in the blockchain network, including the second consensus node, in the node list.

[0012] In some embodiments, the node list is in the world state of the blockchain maintained by the blockchain network.

[0013] In some embodiments, executing a transaction includes: deleting a second consensus node from the node list; or configuring the second consensus node to be inactive in the node list.

[0014] In some embodiments, implementing a view change includes initiating a view change in response to detecting any of the following conditions: the number of consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; the consensus node identifiers in the node list are inconsistent with the consensus node identifiers in the current view; the number of active consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; and the identifiers of active consensus nodes in the node list are inconsistent with the identifiers of consensus nodes in the current view.

[0015] In some embodiments, implementing a view change includes initiating a view change in response to receiving a message broadcast by a second consensus node for initiating a view change.

[0016] In some embodiments, the number of replicas in a view change is the total number of remaining consensus nodes excluding the second consensus node.

[0017] In some embodiments, obtaining a transaction includes obtaining a transaction from a second consensus node, a third consensus node of the blockchain network, or an external device.

[0018] In some embodiments, the method further includes: participating in consensus verification in the absence of a second consensus node.

[0019] According to other embodiments, a system for deleting a node in a blockchain network includes one or more processors and one or more computer-readable storage devices coupled to the one or more processors and storing thereon instructions executable by the one or more processors to perform the methods of any of the foregoing embodiments.

[0020] According to some other embodiments, a non-transitory computer-readable storage medium is configured with instructions executable by one or more processors to cause one or more processors to perform any of the methods described in the foregoing embodiments.

[0021] According to some other embodiments, an apparatus for deleting a node in a blockchain network includes multiple modules for performing the methods of any of the foregoing embodiments.

[0022] According to some embodiments, a system for deleting a node in a blockchain network is implemented in a first consensus node of the blockchain network and includes one or more processors and one or more computer-readable storage devices coupled to and storing instructions thereon, the instructions being executable by the one or more processors to perform operations including: obtaining a transaction including a request to delete a second consensus node in the blockchain network; executing the transaction and sequentially numbering a plurality of remaining consensus nodes in the blockchain network other than the second consensus node in a node list in response to successful consensus verification of the transaction; and performing a view change to enable the remaining consensus nodes to participate in future consensus verification.

[0023] According to other embodiments, a non-transitory computer-readable storage medium is implemented in a first consensus node of a blockchain network and is configured to be executable by one or more processors to cause the one or more processors to perform instructions including: obtaining a transaction including a request to delete a second consensus node in the blockchain network; in response to successful consensus verification of the transaction, executing the transaction and sequentially numbering a plurality of remaining consensus nodes in the blockchain network other than the second consensus node in a node list; and performing a view change to enable the remaining consensus nodes to participate in future consensus verification.

[0024] According to yet another embodiment, an apparatus for deleting a node in a blockchain network, implemented in a first consensus node of the blockchain network, includes: an acquisition module for acquiring a transaction including a request to delete a second consensus node in the blockchain network; an execution module for executing the transaction and sequentially numbering a plurality of remaining consensus nodes in the blockchain network other than the second consensus node in a node list in response to successful consensus verification of the transaction; and an implementation module for implementing a view change to enable the remaining consensus nodes to participate in future consensus verification.

[0025] The embodiments disclosed herein have one or more technical effects. In some embodiments, deleting a node in a blockchain network removes malicious or faulty (e.g., abnormal, offline) nodes. Faulty states may be caused by, for example, configuration errors, machine malfunctions, network failures, software failures, etc. Therefore, deleting a node in a blockchain network can improve the robustness and reliability of the blockchain network. In some embodiments, by dynamically executing transactions for deleting a node, a node can be deleted without interrupting the operation of the blockchain network. In one embodiment, system downtime is avoided during the node deletion process, and the blockchain network maintains its normal operation. In some embodiments, through a view change, the remaining consensus nodes of the blockchain network (excluding the deleted node) all receive a copy of the same node list including the remaining consensus node numbers. Therefore, the remaining nodes can continue to perform consensus verification and maintain the blockchain.

[0026] These and other features of the systems, methods, and non-transitory computer-readable media disclosed herein, as well as the functionality and operation of the relevant components of the structure and the economy of assembly and manufacture of the parts, will become more apparent when considered in conjunction with the accompanying drawings, all of which form part of this document, and similar reference numerals denote corresponding portions in the respective drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be limiting. Attached Figure Description

[0027] Figure 1 Diagrams illustrating the creation of blockchain contracts according to various embodiments are shown.

[0028] Figure 2 A diagram illustrating the invocation of a blockchain contract according to various embodiments is shown.

[0029] Figure 3 Diagrams illustrating the creation and invocation of blockchain contracts according to various embodiments are shown.

[0030] Figure 4 A flowchart for the Practical Byzantine Fault Tolerance (PBFT) algorithm is shown.

[0031] Figure 5 A flowchart is shown for restoring the view after a view change is performed using the PBFT algorithm.

[0032] Figure 6 A flowchart is shown for the view change used to perform the PBFT algorithm.

[0033] Figure 7 A flowchart for deleting a node in a blockchain network is shown according to various embodiments.

[0034] Figure 8A flowchart illustrating a method for deleting a node in a blockchain network according to various embodiments is shown.

[0035] Figure 9 A flowchart illustrating a method for deleting a node in a blockchain network according to various embodiments is shown.

[0036] Figure 10 Block diagrams for implementing a blockchain network are shown according to various embodiments.

[0037] Figure 11 A block diagram of an apparatus for deleting a node in a blockchain network, according to some embodiments, is shown.

[0038] Figure 12 A block diagram of an exemplary computer system in which any of the embodiments described herein may be implemented is shown. Detailed Implementation

[0039] Blockchains can be categorized into three types: public blockchains, private blockchains, and consortium blockchains. Furthermore, various combinations of these three types are possible, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, etc. Public blockchains are the most decentralized. In public blockchains, exemplified by Bitcoin and Ethereum, participants (blockchain nodes, or simply nodes) can read data records from the blockchain, participate in transactions, and compete for the right to bookkeeping new blocks. Moreover, each participant can freely join and leave the blockchain network and perform related operations. However, in private blockchains, data writing permissions can be controlled by a specific entity or organization, while data reading permissions are determined by that entity or organization. Therefore, private blockchains can be considered weakly centralized systems, where the number of participating nodes is constrained and limited. Consortium blockchains fall between public and private blockchains and can achieve "partial decentralization." Each node in a consortium blockchain can correspond to an entity or organization. Participants can join a consortium blockchain network through authorization, forming an alliance with shared interests and jointly maintaining the operation of the blockchain network. For any of the above types of blockchains, there may be a need to dynamically delete nodes in the blockchain network.

[0040] In some embodiments, nodes with a certain level of voting power can be referred to as consensus nodes, which form the blockchain network and maintain its operation through a consensus protocol. For example, consensus nodes may be responsible 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 this consensus verification. Through consensus verification, consensus nodes can reach a consensus (protocol) on adding newly generated blocks to the blockchain. The newly generated blocks may include one or more transactions that have been consensus verified by the consensus nodes. Consensus nodes can also make other consensus decisions on the blockchain, such as setting service fees for the blockchain.

[0041] Each of public, private, and consortium blockchains can provide smart contracts. Smart contracts can be deployed on a blockchain through blockchain transactions and then invoked by other blockchain transactions. For example, Ethereum allows users to create and invoke complex algorithms. As a programmable blockchain, Ethereum's core lies in the Ethereum Virtual Machine (EVM). Each Ethereum node can run the EVM. The EVM is Turing complete, meaning that even complex algorithms can be implemented through it. Smart contracts can be deployed and invoked within the EVM.

[0042] like Figure 1 As shown, Bob can send blockchain transactions, including smart contract creation, to the Ethereum network. The EVM of blockchain node 1 can execute these blockchain transactions to generate corresponding instances of the smart contract. Figure 1 In the blockchain transaction, "0x6f8ae93…" represents the address of the smart contract. The "data" field of a blockchain transaction can store bytecode. The "to" field of a blockchain transaction can be null, representing an empty blockchain account. After the blockchain nodes reach consensus through the consensus mechanism, the smart contract is successfully created and deployed on the blockchain, and future users can invoke the deployed smart contract.

[0043] After a smart contract is created, a corresponding contract account is created in the blockchain, and this contract account has a specific address. The contract code and account data are stored under this contract account. The behavior of the smart contract is controlled by the contract code, and the contract account stores the state of the smart contract. In other words, smart contracts enable the creation of virtual accounts on the blockchain, including contract code and account storage.

[0044] like Figure 2 As shown, still using Ethereum as an example, Bob sends a blockchain transaction containing information for invoking a smart contract to the Ethereum network. The EVM of blockchain node 1 can execute the blockchain transaction to generate the corresponding instance of the smart contract. For Figure 2In blockchain transactions, the "from" field can include the address of the blockchain account calling the smart contract, the "to" field (e.g., "0x6f8ae93…") indicates the address of the smart contract to be called, the "value" field represents the value of Ether, and the "data" field stores the methods and parameters used to call the smart contract. After calling the smart contract, the Ether balance held by the blockchain account may change. Furthermore, a user client can access the smart contract through a blockchain node (e.g., ...). Figure 2 Use blockchain node 6 in the blockchain to check the balance.

[0045] Smart contracts can be executed independently on each blockchain node of a blockchain network according to a defined method. All execution records and data can be stored in the blockchain. Therefore, after such a blockchain transaction is executed, a tamper-proof and permanent proof of the transaction is saved in the blockchain.

[0046] Figure 3 This illustrates the creation and invocation of smart contracts. Creating a smart contract in Ethereum involves steps such as writing the smart contract, compiling it into bytecode, and deploying it on the blockchain. Invoking a smart contract in Ethereum refers to initiating a blockchain transaction pointing to the address of the deployed smart contract, so that the contract code is executed in the EVM of every node in the Ethereum network.

[0047] Besides user-created smart contracts, smart contracts can also be configured by the system in the blockchain's genesis block. This type of contract is called a genesis contract. Within the genesis contract, the blockchain network's data structures, parameters, attributes, and methods can be configured. Furthermore, accounts with system administrator privileges can create or modify system-level smart contracts (referred to as "system contracts"). Different blockchain networks can use different virtual machines besides the EVM; this article does not impose any restrictions.

[0048] One key difference between blockchain technology and traditional decentralized technologies is that ledger recording occurs on each node, or distributed ledger, rather than a traditional centralized ledger. In various blockchain networks, consensus algorithms (i.e., the consensus mechanisms mentioned above) can be implemented to ensure consistency of records among the nodes performing the ledger. When a node generates a new block, if the new block is accepted by other nodes, those other nodes will record the same new block. The confirmation of the new block by other nodes is the consensus mechanism. A consensus mechanism is a mechanism where blockchain nodes reach a network-wide consensus on block information to ensure that new blocks are correctly added to the blockchain. Currently, mainstream consensus mechanisms include: Proof-of-Work (PoW), Proof-of-Stake (PoS), Delegated Proof-of-Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadger BFT algorithm, etc.

[0049] Figure 4 The flowchart of the traditional PBFT algorithm is shown. Proposed by Miguel Castro and Barbara Liskov in 1999, the algorithm addresses the inefficiency of PBFT, reducing its complexity from exponential to polynomial, making its application in practical systems feasible. The paper was published in the proceedings of the Third Symposium on Operating System Design and Implementation (1999). The algorithm assumes that if up to f backup replicas (i.e., nodes) are malicious or faulty, then a total of 3f+1 or more replicas can guarantee security and liveness within the asynchronous system. To ensure data consistency across all replicas and meet fault tolerance requirements, a certain number of replicas (e.g., a set comprising most nodes in the distributed system) are needed to form a quorum. For example, if the total number of replicas n is 3f+1, then the quorum is 2f+1. In other words, the tolerance of a PBFT-based blockchain network for malicious or faulty (e.g., anomalous, offline) nodes is expressed as the maximum number of malicious or faulty nodes that the PBFT system can tolerate, denoted by f, which is (n-1) / 3 rounded to the nearest integer, where n is the total number of replicas. Therefore, for a distributed system with four nodes, any three of them can form a Quorum.

[0050] Furthermore, all replicas undergo a series of succession of configurations called views. In a view, one replica is the primary node, and the others are backup nodes. The primary node of a view is replica p, such that p = v mod |R|, where v is the view number (views are numbered consecutively), and |R| is the number of replicas. When the primary node fails, a view change protocol needs to be triggered to adjust for system failures and change the primary node.

[0051] The PBFT algorithm is as follows.

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

[0053] 2. The primary node 0 broadcasts a request to each backup node;

[0054] 3. Perform each execution request in all replicas and send the corresponding results to the client device c;

[0055] 4. Client device c collects the same result from f+1 different replicas as the final result of the operation.

[0056] The following discussion presents an example of PBFT (combined with the famous Byzantine Generals Problem). Here, assume n = 4 and f = 1, meaning there are a total of four nodes, with one faulty node. Assume the nodes are numbered 0, 1, 2, and 3, and the faulty node is node 3. The processing is as follows.

[0057] 1. (Request Phase) Client device c sends the request to master node 0;

[0058] 2. (Preparation Phase) Master node 0 receives a request from client device c (or a request from a group of client devices), sorts the requests (in the case of a group of client devices), and packages the requests into message m. Then, master node 0 broadcasts the preparation message to nodes 1, 2, and 3 (i.e., backup nodes 1, 2, and 3, also known as replicas or nodes 1, 2, and 3). The preparation message includes message m.

[0059] 3. (Preparation Phase) After receiving the pre-preparation message, if nodes 1, 2, and 3 successfully validate message m, each of nodes 1, 2, and 3 will rebroadcast message m. For example, node 1 will broadcast the preparation message to nodes 0, 2, and 3; node 2 will broadcast the preparation message to nodes 0, 1, and 3; node 3 may experience downtime and be unable to broadcast. Additionally, each node receives preparation messages broadcast by other nodes. Each node can add its own broadcast preparation messages (indicating its own validation) and received preparation messages (indicating validation by other nodes) to its local log. If nodes receive the same message's Quorum...

[0060] If a node receives -1 acknowledgment (with a pre-preparation message and a Quorum-1 preparation message, the local log will have a Quorum number of acknowledgments), then the node transitions to the preparation phase.

[0061] 4. (Commit Phase) Each participating consensus node that has entered the preparation phase broadcasts a commit message to other consensus nodes and adds its own broadcast commit message (indicating a commit message it approves) to its local log. Then, each node receives commit messages broadcast by other nodes. If a node receives a Quorum-1 valid commit messages, it adds the commit messages to its local log (with its own broadcast commit message and a Quorum-1 commit message, the local log will have a Quorum number of commit messages) and transitions to the committed state.

[0062] 5. (Response Phase) Each of the nodes participating in consensus verification executes the request in message m of the prepared message or a set of ordered requests in turn in its local virtual machine, and then sends the response to the client device c.

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

[0064] The above is about Figure 4 The processing and description are based on the traditional PBFT algorithm. Processing can be initiated by a client device, causing one or more transactions in the request message initiated by the client device to undergo consensus verification, and the consensus verification result is returned to the client device upon completion of the verification.

[0065] In a consortium blockchain scenario, consensus verification can be initiated by any node (e.g., above). Figure 4 (Preparation, preparation, and submission processing). In consortium blockchain scenarios, client devices are optional. If client devices are not included, then... Figure 4 The request and response phases become optional, and the masternode can initiate PBFT consensus verification after receiving a certain number of blockchain transactions. If client devices are included, consensus verification can be initiated by the masternode after it receives a certain number of blockchain transactions, rather than by the client device. Figure 4 The preparation phase in the process may not be directly triggered by the request phase.

[0066] If the master node behaves maliciously or malfunctions (e.g., abnormal, offline) and fails to broadcast the client device's request, the client device can configure a timeout mechanism. If a timeout occurs, the client device can broadcast the request to all replicas. If a replica detects that the master node is behaving maliciously or malfunctioning (e.g., abnormal, offline), the replica can initiate a view change protocol phase to change the master node.

[0067] Furthermore, erroneous proposals from the masternode can cause consensus verification to fail in all three phases: pre-preparation, preparation, and commit. Alternatively, during the preparation and commit phases, a Quorum that fails to reach a consensus may also fail, preventing consensus verification from being completed. In these cases, a view change can be initiated to change the masternode.

[0068] During the view change protocol phase, it's necessary to resolve the asynchronous issues between previous nodes and other nodes so that nodes can recover after the view change (VC). For example, ... Figure 5As shown, at view v before the view change, primary node replica 0 has already committed and executed the change.<v,n,d> The corresponding proposal m5 (e.g., message m5) is given, where v is the view number, n is the total number of nodes, and d is the message digest of proposal m5. However, replica 1 may not have committed proposal m5 due to network latency and is still in the pre-preparation phase. Replicas 2 (and 3) may also be in the pre-preparation phase for proposal m5. Subsequently, replica 0 experiences downtime. Therefore, different nodes are in different states. After the primary node changes, replica 0 can recover by restarting. The primary node may have changed to replica 1, and replicas 1-3 need to catch up with replica 0 in message processing progress. Therefore, the new primary node replica 1 needs to resend the proposal m5 in the pre-preparation phase for replicas 1-3 to execute and synchronize with the state of replica 0. Otherwise, at the new view v+1, replicas 1-3 may have completed the three-phase consensus verification of the new message m6, but only replica 0 has executed m5, while replicas 1-3 have not. That is, at the new view v+1, the execution of the new message m6 by replicas 1-3 starts from a different state than that of replica 0. This could lead to inconsistencies between virtual machines on different nodes, resulting in forks. Additionally, 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, and other replicas are lagging behind replica 0 in processing—the ready state of replica 0 can be removed without affecting the consistency of the entire system.

[0069] The view change protocol phase can include view change protocol processing and new view protocol processing. After both protocol processes are completed, the master node change is finished. After the master node changes, the view number will be incremented by 1, becoming v+1. According to p = (v+1)%n, Figure 4 The primary node replica 0 is changed to replica 1.

[0070] For example, such as Figure 6 As shown, a backup node that detects malicious activity or a malfunction (e.g., anomaly, offline) in the primary node can broadcast the message <view change, v+1, n, C, P, i> ​​to other backup nodes. Figure 6 As shown, if replica 1 detects that the original primary node replica 0 is behaving maliciously or malfunctioning (e.g., abnormal, offline), then replica 1 sends the message <view change, v+1, n, C, P, i> ​​to replica 0, replica 2, and replica 3. Similarly, replica 2 sends the message <view change, v+1, n, C, P, i> ​​to replica 0, replica 1, and replica 3, and replica 3 sends the message <view change, v+1, n, C, P, i> ​​to replica 0, replica 1, and replica 2.

[0071] For broadcast messages, "View Change" is the protocol identifier, indicating that the protocol is a view change protocol. The next view number is v+1, and "n" is the number of the latest stable checkpoints, and "C" is the set of 2f+1 verified checkpoint messages. "P" is optional and, if present, indicates the protocol for sending view change messages (corresponding to each in the ready state).<v,n,d> A set of one or more messages indicating that the backup node has reached a ready state (including the signatures of 2f different nodes).

[0072] In example Figure 6 After the new master node p = (v+1)mod|R| of replica 1 receives 2f valid view change messages, it broadcasts the message <new view, v+1, V, O, p> to other nodes. "New view" is the protocol identifier, indicating that the protocol is a new view protocol. The next view number is v+1. "V" includes the view change messages and signatures received by the new master node from 2f different nodes, as well as view change messages for v+1 that have been sent or are yet to be sent by the new master node itself. "O" is the set of unexecuted pre-prepared messages resent by the master node, and "p" is the signature of the current node. The selection rules for the pre-prepared message set include:

[0073] 1. Obtain the stable checkpoint with the minimum number min-s from V, and obtain the preparation message with the maximum number max-s from V.

[0074] 2. Between min-s and max-s, if a message set P exists, then create the message <<prepared, v+1, n, d>, m>. Otherwise, create an empty prepared message <<prepared, v+1, n, d(null)>, m(null)>, where m(null) is an empty message and d(null) is a summary of the empty message.

[0075] When a backup node receives a new view message from the primary node, it verifies the signatures in the V and O statements and the view change message. If valid, the backup node enters the v+1 state and begins processing the pre-prepared message in the O statement.

[0076] In the example of a consortium blockchain, nodes may correspond to one or more accounts. Similarly, a node may not correspond to any account but only act as a consensus node. Additionally, a consortium blockchain can include a genesis contract or system contract that can be generated as described above. The genesis contract / system contract can configure the consensus node list (node ​​list, or simply list) of the consortium blockchain, for example, configuring the public key set of consensus nodes and arranging the public keys in the set according to a predetermined order. Each consensus node in the consortium blockchain can store a local node list locally based on the consensus node list in the genesis contract. In the local node list, each consensus node can be arranged according to its corresponding public key, according to the order specified in the genesis contract / system contract. Therefore, each consensus node's local list contains the same consensus nodes arranged in the same order. Furthermore, methods and parameter configurations for consensus nodes can be added to the genesis contract / system contract. Therefore, based on the genesis contract / system contract, each node can perform a node deletion operation by changing the nodes in its local node list.

[0077] When an account initiates a request to delete a consensus node, such as a transaction request, the first consensus node can receive the request. For example, the request could be a node deletion request initiated by a client device, triggering the node deletion process. Alternatively, the request could be a node deletion request received by the first consensus node from the controller's command console, triggering the node deletion process. The controller can be operated by an administrator controlling the corresponding node, for example, through graphical or coded commands. For consensus algorithms with a master node, such as PBFT, the first consensus node can be the master node. The first consensus node can obtain transaction requests directly from the client device or controller, or from other consensus nodes forwarding the transaction requests. For consensus algorithms without a master node, such as HoneyBadger BFT, where there is no master node, the first consensus node is one of multiple consensus nodes.

[0078] Figure 7 A flowchart for deleting a node in a blockchain network according to various embodiments is shown. The operations presented below are intended to illustrate the purpose. Depending on the implementation, exemplary steps may include additional, fewer, or alternative steps performed in various orders or in parallel. Figure 7 This provides an example of deleting a node (node ​​X) in a blockchain network that includes multiple consensus nodes. The blockchain network maintains the blockchain. Node X, which is either a master node or a backup node in a PBFT-based blockchain network, can be deleted.

[0079] Deleting a node in a blockchain network can include at least the following embodiments. In some embodiments, node X may be an active consensus node in the blockchain network before deletion, and through node deletion, node X becomes an inactive consensus node in the blockchain network. Activated consensus nodes can participate in consensus verification. However, inactive consensus nodes cannot participate in consensus verification and are therefore likely to be non-consensus nodes. In some embodiments, node X may be part of the blockchain network before deletion (e.g., as an active consensus node), and through node deletion, node X is removed from the blockchain network.

[0080] Figure 7 Two parallel timelines are shown. The top timeline carries the time-dependent state of a local copy of the blockchain from node X, and the bottom timeline carries the time-dependent state of a local copy of the blockchain from one of the remaining consensus nodes (node ​​Y). Each remaining consensus node can perform the steps performed by node Y. Various interactions exist between the axes, including message communication and data synchronization. In some embodiments, each consensus node in the blockchain network maintains a local node list, which includes one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number. The consensus nodes of the blockchain network are sequentially numbered in the node list. Due to node deletion, the total number of consensus nodes in the blockchain network may decrease, and the numbering of consensus nodes in the node list may change. In one embodiment, the node list represents the world state of the blockchain maintained by the blockchain network.

[0081] Along the top axis, node X changes from being an active consensus node in the blockchain network to not being an active consensus node in the blockchain network. Along the bottom axis, node Y goes through a normal phase, a view-change phase, and then back to the normal phase. Similarly, along both the top and bottom axes, the blockchain changes its state when one or more new blocks are added, thus updating the blockchain state from B_1 to B_2 and then to B_3. The "block" box on each axis represents the blockchain that is seen or stored by node X or node Y.

[0082] In some embodiments, in step 701, a management account, external account, or alternative account may initiate a transaction "DeleteNode" to delete node X from the blockchain network. The transaction may be initiated by node X, node Y, or an external device coupled to the blockchain network and broadcast to all consensus nodes. Node Y may obtain the transaction from a client device or the command console of a controller. For example, node Y may obtain the transaction from node X, another consensus node in the blockchain network, or an external device. At this time, a local copy of the blockchain for node X is located at B_1. Consensus nodes (e.g., node X, node Y) may perform consensus verification on the transaction. In some embodiments, the transaction is configured to invoke a blockchain contract deployed in the blockchain maintained by the blockchain network. In some embodiments, the blockchain contract includes a genesis contract or a system contract.

[0083] In some embodiments, in response to successful consensus verification of a transaction, consensus nodes (e.g., node X, node Y) can each execute the transaction and include multiple remaining consensus nodes of the blockchain network, excluding node X, in the node list.

[0084] In some embodiments, in order to execute a transaction, node Y can delete node X from its node list or configure node X as inactive in its node list.

[0085] In some embodiments, each consensus node (e.g., node X, node Y) maintains a local node list, which includes one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number. Before sequentially numbering the remaining consensus nodes in the blockchain network (excluding node X), the node list sequentially numbers all consensus nodes in the blockchain network, including nodes X and Y. For example, before a node is deleted, the node list indicates that the blockchain network includes node A (number 0), node B (number 1), node C (number 2), node X (number 3), and node Y (number 4); and after a node is deleted, the node list indicates that the blockchain network includes node B (number 0), node A (number 1), node C (number 2), and node Y (number 3).

[0086] In some embodiments, in step 702, a consensus node (e.g., node X, node Y) may initiate a view change. For example, a consensus node may initiate a view change in response to detecting any of the following conditions: the number of consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; the identifiers of consensus nodes in the node list are inconsistent with the identifiers of consensus nodes in the current view; the number of active consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; and the identifiers of active consensus nodes in the node list are inconsistent with the identifiers of consensus nodes in the current view. In one embodiment, a consensus node may initiate a view change in response to receiving a message broadcast by node X for initiating a view change.

[0087] In some embodiments, the remaining consensus nodes (e.g., node Y) may implement a view change to enable the remaining consensus nodes to participate in future consensus verification. The number of replicas in the view change is the total number of remaining consensus nodes excluding the second consensus node. In some embodiments, the remaining consensus nodes may participate in consensus verification without node X. In some embodiments, in steps 703 and 704, although not acting as an active consensus node, node X may synchronize to the blockchain to update its local blockchain copy.

[0088] In this way, the blockchain operation is not interrupted during node deletion. Consensus verification can still be performed during the node deletion process. Node deletion can be achieved without stopping the blockchain system, thus eliminating system downtime.

[0089] Figure 8 A flowchart illustrating a method 800 for deleting a node in a blockchain network according to various embodiments is shown. In some embodiments, the blockchain network may be based on a consortium blockchain. In some embodiments, the blockchain network may be based on PBFT.

[0090] S801 includes: the first consensus node of the blockchain network receives a transaction request for deleting a node and initiates consensus verification for the transaction request for deleting a node; after the consensus verification is successful, the remaining consensus nodes execute the transaction for deleting the node and number the remaining consensus nodes other than the node to be deleted in the local node list.

[0091] In some embodiments, a transaction request may be a transaction request for invoking a contract. The transaction request may specify the address of the smart contract to be invoked, the invocation method, and input parameters. For example, the invoked contract may be the aforementioned generative contract / system contract, the invocation method may be a method for deleting a node, and the input parameters may include one or more of the following for the node to be deleted: identifier, IP address, and port number.

[0092] In some embodiments, the first consensus node can trigger node deletion processing by receiving a transaction request for deleting the node. For example, as described above, the first consensus node can trigger node deletion processing by receiving a transaction request for deleting the node from a client device, or by receiving a transaction request for deleting the node from the controller's command console. The controller can be operated by an administrator controlling the corresponding node, for example, through graphical or coded instructions. Alternatively, the first consensus node can receive relevant information about the node to be deleted from the node to trigger node deletion processing.

[0093] In some embodiments, a transaction request for deleting a node is propagated to various consensus nodes in a blockchain network based on an underlying peer-to-peer (P2P) network. After receiving the transaction request for deleting a node, the first consensus node can initiate consensus verification processing as a master node associated with a consensus algorithm that has a master node, or as a consensus node associated with a consensus algorithm that does not have a master node. Taking, for example, PBFT's consensus algorithm with a master node, the first consensus node can be the master node and can initiate consensus verification processing for the transaction request for deleting a node, which mainly includes the above... Figure 4 The process involves pre-preparation, preparation, and submission. Alternatively, the first consensus node can be a backup node, which receives and forwards transaction requests to the primary node to initiate consensus verification processing.

[0094] In some embodiments, after consensus verification is completed, nodes in the blockchain network have locally the message content of the transaction request for the node to be deleted, and a consensus is reached. Furthermore, if the message content of the transaction request for deleting the node, along with other messages, forms a consensus result, then the message content of the transaction request for deleting the node has the same message sequence on different nodes; that is, at least the consensus nodes of Quorum have reached a consensus on the message content of the node deletion request and the order associated with the messages.

[0095] In some embodiments, after S801, as previously described, at least the consensus nodes of Quorum have reached a consensus on the message content in the transaction request that includes node deletion. Furthermore, the remaining consensus nodes can execute the corresponding contract locally. For example, the remaining consensus nodes can call the aforementioned generative contract / system contract, execute the method specified in the call to the generative contract / system contract in a virtual machine such as the EVM, and input the corresponding parameters. In one example, the input parameters may include, for example, the identifier of the node to be deleted, the IP address of the node to be deleted, the port number of the node to be deleted, etc. During contract execution, the remaining consensus nodes can delete the information of the node to be deleted from the local node list and sequentially number the remaining consensus nodes in the local node list. Thus, the consensus node list maintained by at least the remaining consensus nodes of Quorum has the same remaining consensus nodes, and these same remaining consensus nodes are numbered in the same order.

[0096] In some embodiments, as described above, consensus nodes can maintain a local consensus node list, i.e., the aforementioned local node list, which records basic information about all consensus nodes in the current blockchain network. In one example, the basic information may include one or more of the following: consensus node identifier, IP address, port number, etc. The consensus nodes can be sequentially numbered in the local node list. A consensus node can have an identifier (ID), which can be a unique identifier for the node, such as the node's public key, IP address + port number, etc. In some blockchain projects, the consensus node list can logically exist within the world state. Taking Ethereum, Fabric, and consortium blockchains as examples, each node maintains a local world state where the latest state of all accounts is available. For example, in Ethereum, a node can maintain the latest state of all accounts based on the contents of the state tree, transaction tree, and receipt tree in the blocks.

[0097] In some embodiments, since several consensuses have already been implemented by the consensus nodes, theoretically, the consistency of the consensus node list has been maintained among the consensus nodes. For example, consensus nodes a, b, c, d, and m have local node lists stored in their respective world states, and the consensus nodes stored in the local node lists of each node a, b, c, d, and m are five nodes a, b, c, d, and m, in the order abcdm. Then, a, b, c, d, and m are numbered 0, 1, 2, 3, and 4, respectively. Thus, for the deleted node m, each consensus node implements S801 based on the consensus node list maintained locally, and the nodes in the local node list of the consensus node include nodes a, b, c, and d, a total of four nodes, and the remaining nodes are configured with the same sequence number (e.g., 0-1-2-3).

[0098] In some embodiments, consensus nodes can include two types: active and inactive. Active consensus nodes can participate in consensus verification and can be stored in the local node list with sequential numbers. Inactive consensus nodes may not participate in consensus verification and therefore will not be numbered together with active consensus nodes in the local node list. Therefore, instead of deleting the node to be deleted from the local node list as described above, the node to be deleted can be set to an inactive state. As a result, the node to be deleted can be frozen without being removed from the blockchain network and thus no longer acts as a consensus node.

[0099] S803 includes implementing view changes for the remaining consensus nodes.

[0100] In S801, after the remaining consensus nodes execute the transaction for deleting a node, they can update their local node lists. In the current view, the original node participated in consensus verification but has not yet executed node deletion, and its order is preserved. Thus, after the remaining consensus nodes execute the node deletion transaction, they can detect that the number of consensus nodes in their local consensus node lists is inconsistent with the number of consensus nodes in the current view, or that the consensus node identifiers in their local consensus node lists are inconsistent with the consensus node identifiers in the current view. Therefore, the remaining consensus nodes can initiate a view change.

[0101] In some embodiments, R (i.e., the number of replicas in the view change process) in the view change process is the total number of consensus nodes excluding the node to be deleted, that is, the number of nodes in the local node list excluding the node to be deleted.

[0102] In some embodiments, similar to the foregoing, the remaining consensus nodes can broadcast the message <view change, v+1, n, C, P, i> ​​to other replica nodes, where n is the number of the latest stable checkpoints, C is the set of 2f+1 verified checkpoint messages, and P is the set of pre-preparation and ready messages that the replica nodes have not yet finished processing.

[0103] In some embodiments, there are five consensus nodes, numbered a, b, c, d, and m. It is assumed that the remaining nodes include nodes a, b, c, and d, while the node to be deleted is node m. Node a is, for example, the master node in PBFT, while nodes b, c, d, and m are, for example, backup nodes in PBFT. The new master node number can be calculated using p = (v)mod|R|. For example, if p = 1, the new master node is node b. Here, R is the number of nodes in the local node list excluding the node to be deleted. Each consensus node records the numbers of the five nodes a, b, c, d, and m in its local node list. In this case, R equals 5. In the example executing S801 to S803, each consensus node can sequentially number the remaining consensus nodes excluding the node to be deleted; that is, the remaining nodes a, b, c, and d can be sequentially numbered 0, 1, 2, and 3. In this case, R becomes 4. As described above, the view number increases during the view change process, i.e., from v to v+1.

[0104] In another example, there are five consensus nodes, numbered a, b, c, d, and m. Assuming the node to be deleted is node c, the remaining nodes include nodes a, b, d, and m. After executing steps S801-S803, each consensus node can number the remaining consensus nodes (excluding the node to be deleted) based on the node numbering of the previous consensus node. Therefore, the remaining consensus nodes a, b, d, and m are renumbered as 0, 1, 2, and 3.

[0105] Furthermore, for the method of configuring consensus nodes to an inactive state to freeze consensus nodes, the remaining consensus nodes may initiate a view change in response to detecting any of the following conditions: the number of active consensus nodes in the local consensus node list is inconsistent with the number of consensus nodes in the current view, or the identifier of the active consensus node in the local consensus node list is inconsistent with the identifier of the consensus node in the current view.

[0106] S805 includes: after the view change is completed, the remaining consensus nodes participate in consensus verification.

[0107] In some embodiments, after the view change is completed, the remaining consensus nodes, excluding the deleted node, each have the same list of node numbers and the same block data locally, so that the remaining consensus nodes can participate in consensus verification normally. Thus, the node deletion process is complete.

[0108] Figure 9 A flowchart of a method 900 for deleting a node in a blockchain network according to various embodiments is shown. Method 900 may be used for deleting, for example, a consensus node in a blockchain network (e.g., Figure 1-3 blockchain nodes, Figure 7 or Figure 10Method 900 can be implemented by a device, apparatus, or system of a node in a blockchain network (the remaining consensus nodes). Method 900 can be implemented by the first consensus node of the blockchain network. The first consensus node can be a master node or backup node in a PBFT-based blockchain network. The first consensus node can be implemented by a system or device (e.g., a computer, a server) comprising various hardware machines and / or software. For example, the 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), the computer-readable storage media being coupled to one or more processors and configured with instructions executable by one or more processors to cause the system or device (e.g., a processor) to perform method 900.

[0109] The operation of method 900 presented below is intended to illustrate the concept. Depending on the implementation, method 900 may include additional, fewer, or alternative steps performed in various orders or in parallel. Further details of method 900 can be found in [reference needed]. Figures 1 to 8 and Figure 10 And related descriptions. References Figures 1 to 8 and Figure 10 The steps described for deleting a node in a blockchain network are included in method 900.

[0110] Deleting a node in a blockchain network can include at least the following embodiments. In some embodiments, the node to be deleted (e.g., a second consensus node) may be an active consensus node in the blockchain network before the node deletion, and through node deletion, the node becomes an inactive consensus node in the blockchain network. Activated consensus nodes can participate in consensus verification. However, inactive consensus nodes cannot participate in consensus verification and are therefore likely to be non-consensus nodes. In some embodiments, the node to be deleted may be part of the blockchain network before the node deletion (e.g., as an active consensus node), and through node deletion, the node is removed from the blockchain network.

[0111] Block S901 includes: a first consensus node in the blockchain network receiving a transaction including a request to delete a second consensus node in the blockchain network. In some embodiments, the first consensus node receiving the transaction includes: receiving the transaction from a command console of a client device or a controller. In some embodiments, receiving the transaction includes: receiving the transaction from a second consensus node, a third consensus node in the blockchain network, or an external device.

[0112] In some embodiments, the transaction is configured to invoke a blockchain contract deployed in a blockchain maintained by a blockchain network. In some embodiments, the blockchain contract includes a genesis contract or a system contract.

[0113] Block S902 includes: in response to successful consensus verification of a transaction, executing the transaction and sequentially numbering the remaining consensus nodes in the blockchain network, excluding the second consensus node, in the node list. In some embodiments, executing the transaction includes: deleting the second consensus node from the node list; or configuring the second consensus node in the node list to an inactive state.

[0114] In some embodiments, the node list is in the world state of the blockchain maintained by the blockchain network. In some embodiments, the first consensus node maintains the node list locally, which includes one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number; and before sequentially numbering the remaining consensus nodes in the blockchain network other than the second consensus node, sequentially numbering all consensus nodes in the blockchain network, including the second consensus node, in the node list.

[0115] Block S903 includes: implementing a view change to enable the remaining consensus nodes to participate in future consensus verification. In some embodiments, implementing a view change includes: initiating a view change in response to receiving a message broadcast by a second consensus node for initiating a view change.

[0116] In some embodiments, implementing a view change includes initiating a view change in response to detecting any of the following conditions: the number of consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; the consensus node identifiers in the node list are inconsistent with the consensus node identifiers in the current view; the number of active consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; and the identifiers of active consensus nodes in the node list are inconsistent with the identifiers of consensus nodes in the current view.

[0117] In some embodiments, the number of replicas in a view change is the total number of remaining consensus nodes excluding the second consensus node.

[0118] In some embodiments, the method further includes: participating in consensus verification in the absence of a second consensus node.

[0119] Figure 10 Block diagrams for implementing a blockchain network according to various embodiments are shown. As illustrated, the blockchain network may include multiple consensus nodes 1002 before node deletion, where the node to be deleted from the blockchain network is 1003, and the remaining nodes are 1004. Any one of the consensus nodes 1004 can be a first consensus node for receiving transactions. Here, node 1001 is designated as the first consensus node. In some embodiments, the blockchain network may be based on PBFT, and in each view, one of its nodes may be a master node while the remaining nodes may serve as backup nodes.

[0120] In some embodiments, a first consensus node 1001 is configured to receive a transaction request for deleting node 1003 in the blockchain network and initiate consensus verification for the transaction request to delete node 1003. After successful consensus verification, each consensus node 1002 is configured to execute the transaction for deleting node 1003 and sequentially number the remaining consensus nodes 1004 excluding the node to be deleted. The remaining consensus nodes 1004 are configured to implement view changes and participate in consensus verification for the blockchain after the view changes are completed.

[0121] In some embodiments, the transaction request for deleting a node includes a transaction request for invoking a contract. In some embodiments, the contract being invoked includes a genesis contract or a system contract. In some embodiments, the first consensus node 1001 obtaining the transaction request for deleting a node includes: the first consensus node 1001 obtaining the transaction request for deleting a node from a client device; and the first consensus node 1001 obtaining the transaction request for deleting a node from the controller's command console.

[0122] In some embodiments, each consensus node 1002 is configured to maintain a node list locally, the node list including one or more of the following: identifier, IP address, and port number, wherein the consensus nodes 1002 are sequentially numbered in the node list. In one embodiment, the node list maintained locally by the consensus node 1002 is in a world state.

[0123] In some embodiments, consensus node 1002 executing a transaction for deleting node 1003 includes: consensus node 1002 deleting consensus node 1003 from the node list; or configuring consensus node 1003 as inactive in the node list.

[0124] In some embodiments, any consensus node 1002 may be configured to initiate a view change in response to detecting any of the following conditions: the number of consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; the consensus node identifiers in the node list are inconsistent with the consensus node identifiers in the current view; the number of active consensus nodes in the node list is inconsistent with the number of consensus nodes in the current view; and the identifiers of active consensus nodes in the node list are inconsistent with the identifiers of consensus nodes in the current view.

[0125] In some embodiments, consensus node 1002 may initiate a view change in response to receiving a message broadcast by consensus node 1003 for initiating a view change.

[0126] In some embodiments, the number of replicas in a view change is the total number of remaining consensus nodes 1004 excluding consensus node 1003.

[0127] Figure 11 A block diagram of an apparatus 1100 for deleting a node in a blockchain network, according to some embodiments, is shown. The apparatus 1100 may be a node (e.g., Figure 1-3 blockchain nodes, Figure 7 or Figure 10 An implementation example of one or more components (remaining consensus nodes). A node can be a master node or a backup node in a PBFT-based blockchain network. One or more steps of methods 800 and 900 can be implemented by device 1100.

[0128] Apparatus 1100 may be implemented in a computer system or device, which includes 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., processor) to perform the steps of the methods described above (e.g., method 800 or 900). Apparatus 1100 may include various units / modules corresponding to the instructions (e.g., software instructions).

[0129] In some embodiments, the apparatus 1100 may include: an acquisition module 1101, which acquires a transaction including a request to delete a second consensus node in the blockchain network; an execution module 1102, which, in response to successful consensus verification of the transaction, executes the transaction and sequentially numbers a plurality of remaining consensus nodes in the blockchain network other than the second consensus node in a node list; and an implementation module 1103, which implements a view change to enable the remaining consensus nodes to participate in future consensus verification.

[0130] The techniques described herein can be implemented by one or more dedicated computing devices. A dedicated computing device can 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 includes hard-wired and / or program logic to implement these techniques. A dedicated computing device can be implemented as a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination thereof. Computing devices are typically controlled and coordinated by operating system software. Traditional 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 graphical user interfaces (“GUIs”). The various systems, apparatuses, storage media, modules, and units described herein can be implemented in a dedicated computing device or one or more computing chips within one or more dedicated computing devices. In some embodiments, the instructions described herein can be implemented in a virtual machine on a dedicated computing device. When executed, the instructions can cause the dedicated computing device to perform the various methods described herein. A virtual machine can include software, hardware, or a combination thereof.

[0131] Figure 12 A block diagram of a computer system in which any of the embodiments described herein may be implemented is shown. System 1200 can be Figure 1-7 , Figure 10 and Figure 11 Implemented in any component of the environment, system, or device shown. It can be implemented through one or more embodiments of computer system 1200. Figure 8 and Figure 9 One or more methods are shown.

[0132] Computer system 1200 may include bus 1202 or other communication mechanisms for communicating information, and one or more hardware processors 1204 coupled to bus 1202 for processing information. Hardware processor 1204 may be, for example, one or more general-purpose microprocessors.

[0133] Computer system 1200 may also include main memory 1206, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 1202 for storing information and instructions executable by processor 1204. Main memory 1206 may also be used to store temporary variables or other intermediate information during the execution of instructions executable by processor(s) 1204. When stored in a storage medium accessible by processor(s) 1204, such instructions present computer system 1200 to a dedicated machine tailored to perform the operations specified in the instructions. Computer system 1200 may further include read-only memory (ROM) 1208 or other static storage devices coupled to bus 1202 for storing static information and instructions for processor 1204. Storage devices 1210, such as disks, optical discs, USB thumb drives (flash drives), etc., may be provided and coupled to bus 1202 to store information and instructions.

[0134] Computer system 1200 may use custom hardwired logic, one or more ASICs or FPGAs, firmware and / or program logic, which, in combination with the computer system, make computer system 1200 a special-purpose machine or program computer system 1200 into a special-purpose machine to implement the techniques described herein. 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. These instructions may be read into main memory 1206 from another storage medium, such as storage device 1210. Executing the sequence of instructions contained in main memory 1206 causes processor 1204 to perform the processing steps described herein. In alternative embodiments, hardwired circuitry may be used instead of software instructions or in combination with software instructions.

[0135] Main memory 1206, ROM 1208, and / or storage device 1210 may include non-transitory storage media. As used herein, the term "non-transitory media" and similar terms refer to a medium that stores data and / or instructions that cause a machine to operate in a particular manner, excluding transient signals. Such non-transitory media may include non-volatile media and / or volatile media. For example, non-volatile media include optical discs or magnetic disks, such as storage device 1210. Volatile media include dynamic memory, such as main memory 1206. Conventional forms of non-transitory media include, for example, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes and their network versions.

[0136] Computer system 1200 may include a network interface 1218 coupled to bus 1202. Network interface 1218 may provide bidirectional data communication coupling for one or more network links connected to one or more local networks. For example, network interface 1218 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, network interface 1218 may be a Local Area Network (LAN) card to provide data communication connectivity to a compatible LAN (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, network interface 1218 may transmit and receive electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0137] Computer system 1200 can send messages and receive data including program code via a network, network link, and network interface 1218. In an Internet example, the server can transmit application request code via the Internet, ISP, local network, and network interface 1218.

[0138] The received code may be executed by processor 1204 upon receipt and / or stored in storage device 1210 or other non-volatile memory for later execution.

[0139] Each process, method, and algorithm described in the preceding sections can be embodied in a code module executed by one or more computer systems or computer processors, including computer hardware, and implemented by them, either fully or partially automatically. The processes and algorithms can be implemented, partially or entirely, in dedicated circuitry.

[0140] The various features and processes described above can be used independently of each other or 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 not limited to any particular order, and the associated blocks or states may be performed in other suitable orders. For example, the described blocks or states may be performed in a different order than specifically disclosed, or multiple blocks or states may be combined in a single block or state. Examples of blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be removed or omitted from the disclosed embodiments. Examples of systems and components described herein may be configured differently from those described. For example, elements may be removed, omitted, or rearranged compared to the disclosed embodiments.

[0141] The various operations of the methods described herein can 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 processors can constitute the engine of a processor implementation for performing one or more operations or functions described herein.

[0142] Similarly, the methods described herein can be implemented at least in part by a processor, where a specific processor is an example of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also be operated to support the performance of related operations in a “cloud computing” environment or as a “Software as a Service” (SaaS) operation. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), and these operations can be accessed via a network (e.g., the Internet) through one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0143] The performance of certain operations can be distributed among processors, not just residing on a single machine, but deployed across multiple machines. In some embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., within a home environment, office environment, or server cluster). In other embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0144] In this document, multiple instances can implement the components, operations, or structures described as a single instance. Although the individual operations of one or more methods are shown and described as independent operations, one or more independent operations can be performed simultaneously, and they do not need to be performed in the order shown. Structures and functions presented as independent components in a configuration can be implemented as composite structures or components. Similarly, structures and functions presented as single components can be implemented as independent components. These and other changes, modifications, deletions, and improvements all fall within the scope of the subject matter herein.

[0145] Although an overview of the subject matter has been described with reference to specific embodiments, various modifications and changes can be made to these embodiments without departing from the broad scope of the embodiments described herein. The specific embodiments should not be considered limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents. Furthermore, the related terms used herein (such as “first,” “second,” “third,” etc.) do not indicate any order, importance, or significance, but are used to distinguish one element from another. Additionally, the terms “a,” “an,” and “a plurality” do not indicate a limitation on quantity herein, but rather indicate the presence of at least one of the said items. Moreover, in this document, “or” is inclusive rather than exclusive unless explicitly stated or indicated by the context. Thus, in this document, “A or B” means “A, B, or both” unless explicitly stated or indicated by the context. And, “and” is both a conjunction and a plurality unless explicitly stated or indicated by the context. Thus, in this document, “A and B” means “A and B, jointly or separately” unless explicitly stated or indicated by the context.

Claims

1. A computer-implemented method for deleting a node in a blockchain network, comprising: The first consensus node of the blockchain network receives a transaction that includes a request to remove the second consensus node from the blockchain network; In response to the successful consensus verification of the transaction, the transaction is executed and the remaining consensus nodes in the blockchain network, excluding the second consensus node, are sequentially numbered in the node list. The first consensus node maintains the node list locally. Before the remaining consensus nodes are sequentially numbered, all consensus nodes in the blockchain network are sequentially numbered in the node list. as well as A view change is implemented to ensure that the numbers of the consensus nodes in the node list are consistent with the numbers of the remaining consensus nodes in the changed view, and the remaining consensus nodes participate in future consensus verification.

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

3. The method according to claim 2, wherein, The blockchain contract includes a founding contract or a system contract.

4. The method according to any one of claims 1-3, wherein, The first consensus node obtains the transaction, including: The transaction is obtained from the command console of the client device or controller.

5. The method according to any one of claims 1-3, wherein: The first consensus node maintains the node list locally, the node list including one or more of the following: consensus node identifier, consensus node IP address, and consensus node port number; and Before sequentially numbering the remaining consensus nodes in the blockchain network other than the second consensus node in the node list, sequentially number all consensus nodes in the blockchain network, including the second consensus node, in the node list.

6. The method according to any one of claims 1-3, wherein, The list of nodes is in the world state of the blockchain maintained by the blockchain network.

7. The method according to any one of claims 1-3, wherein, Executing the transaction includes: Remove the second consensus node from the node list; or The second consensus node is configured to be inactive in the node list.

8. The method according to any one of claims 1-3, wherein, The implementation view change includes: In response to receiving a message broadcast by the second consensus node for initiating a view change, the view change is initiated.

9. The method according to any one of claims 1-3, wherein, The number of replicas in the view change is the total number of the remaining consensus nodes excluding the second consensus node.

10. The method according to any one of claims 1-3, wherein, The transaction that receives the request to remove the second consensus node from the blockchain network includes: The transaction is obtained from the second consensus node, the third consensus node of the blockchain network, or an external device.

11. The method according to any one of claims 1-3, further comprising: Participate in consensus verification in the absence of a second consensus node.

12. A system for deleting a node in a blockchain network, comprising: One or more processors; as well as One or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon that can be executed by the one or more processors to perform the method of any one of claims 1-11.

13. An apparatus for deleting a node in a blockchain network, comprising a plurality of modules for performing the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing instructions executable by one or more processors to cause the one or more processors to perform the method according to any one of claims 1-11.

Images