Node updating method and apparatus

Abstract

The specification provides a node updating method and device. The method is applied to a blockchain system including a blockchain network, a management subsystem and a domain name subsystem. The blockchain network contains consensus nodes participating in consensus and read-only nodes not participating in consensus. The domain name subsystem provides domain name resolution services for each node based on a DNS list. The mapping relationship between the IP address and the domain name of any node is recorded in the corresponding entry of the DNS list. The method includes: the management subsystem acquires a first private key of any consensus node and selects a target read-only node when determining that the consensus node cannot participate in consensus; the management subsystem sends a first domain name update message to the domain name subsystem and updates the node private key of the target read-only node from a second private key to the first private key; and the domain name subsystem updates the second domain name recorded in the second entry corresponding to the target read-only node in the DNS list to the first domain name recorded in the first entry of the any consensus node.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a node update method and apparatus. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Users can participate in blockchain-related transactions through blockchain nodes. For example, multiple blockchain nodes corresponding to different users can perform secure multi-party computation (SMPC) on the private data of a particular node based on privacy technologies such as homomorphic encryption and zero-knowledge proofs.

[0003] Blockchain networks typically contain consensus nodes that cooperate to reach a consensus on blocks or messages. These nodes may malfunction, preventing them from participating in the consensus process. In related technologies, when a consensus node fails, the administrator usually removes it from the network and adds a new one. However, this method is labor-intensive and time-consuming, making the blockchain network intolerant of any consensus node errors for an extended period. This hinders the rapid restoration of the network's fault tolerance and is detrimental to the stable and efficient operation of the blockchain network. Summary of the Invention

[0004] The purpose of this invention is to provide a node update method and apparatus.

[0005] According to a first aspect of one or more embodiments of this specification, a node update method is proposed, applied to a blockchain system, the blockchain system including a blockchain network, a management subsystem, and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, and the domain name subsystem providing domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list, wherein any node among the consensus nodes and the read-only nodes has a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the method comprising:

[0006] If the management subsystem determines that any consensus node cannot participate in the consensus, it obtains the first private key of the consensus node and selects a target read-only node from the read-only nodes.

[0007] The management subsystem sends a first domain name update message to the domain name subsystem for any consensus node and the target read-only node; and updates the node private key of the target read-only node from the second private key to the first private key;

[0008] In response to the first domain name update message, the domain name subsystem queries the DNS list for the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node, and updates the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0009] According to a second aspect of one or more embodiments of this specification, a node update method is proposed, comprising: a management subsystem applied to a blockchain system, the blockchain system further comprising a blockchain network and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on a domain name system (DNS) list maintained by itself, wherein any node among the consensus nodes and the read-only nodes has a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the method comprising:

[0010] If it is determined that any consensus node cannot participate in the consensus, obtain the first private key of the consensus node, and select a target read-only node from the read-only nodes;

[0011] Update the private key of the target read-only node from the second private key to the first private key;

[0012] Send a first domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the first domain name update message by querying the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0013] According to a third aspect of one or more embodiments of this specification, a node update apparatus is provided, comprising: an application to a blockchain system, the blockchain system including a blockchain network, a management subsystem, and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, and the domain name subsystem providing domain name resolution services to each node in the blockchain network based on a domain name system (DNS) list maintained by itself, wherein any consensus node and any read-only node has a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the apparatus comprising:

[0014] The acquisition and selection unit is used to enable the management subsystem to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes;

[0015] The sending and updating unit is configured to enable the management subsystem to send a first domain name update message for any consensus node and the target read-only node to the domain name subsystem; and to update the node private key of the target read-only node from the second private key to the first private key;

[0016] The domain name update unit is configured to cause the domain name subsystem to respond to the first domain name update message by querying the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0017] According to a fourth aspect of one or more embodiments of this specification, a node update apparatus is provided, comprising: a management subsystem applied to a blockchain system, the blockchain system further comprising a blockchain network and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on a domain name system (DNS) list maintained by itself, wherein any consensus node and any read-only node has a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the apparatus comprising:

[0018] The acquisition and selection unit is used to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes.

[0019] A private key update unit is used to update the node private key of the target read-only node from the second private key to the first private key;

[0020] The message sending unit is configured to send a first domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the first domain name update message by querying the first entry corresponding to the consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of the consensus node recorded in the first entry.

[0021] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0022] processor;

[0023] Memory used to store processor-executable instructions;

[0024] The processor implements the method as described in any one of the first or second aspects by executing the executable instructions.

[0025] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in any one of the first or second aspects.

[0026] In the embodiments of this specification, the domain name subsystem in the blockchain system maintains a DNS list. This list records the correspondence between the IP addresses and domain names of various consensus nodes and read-only nodes in the blockchain network. The domain name subsystem provides domain name resolution services to various nodes in the blockchain network based on the DNS list. If it is determined that any consensus node cannot participate in consensus, the management subsystem obtains the first private key of that node and selects a target read-only node from the read-only nodes. Then, it sends a first domain name update message to the domain name subsystem for both the consensus node and the target read-only node, and updates the private key of the target read-only node from its second private key to its first private key. In response to the first domain name update message, the domain name subsystem queries the DNS list for the first entry corresponding to the consensus node and the second entry corresponding to the target read-only node, and updates the second domain name of the target read-only node recorded in the second entry to the first domain name of the consensus node recorded in the first entry.

[0027] Understandably, before any consensus node fails, the first private key is the node private key of that consensus node, used to identify its identity in the blockchain network (e.g., it can be used to generate the node public key of that consensus node); the first domain name is the domain name of that consensus node, which other nodes can access. After any consensus node fails (i.e., the failed node), the management subsystem updates the node private key of the target read-only node from the second private key to the first private key, and the domain name subsystem updates the second domain name of the target read-only node recorded in the second entry to the first domain name. With both the second private key and the second domain name updated, the first private key becomes the private key of the target read-only node, used to identify its identity in the blockchain network (e.g., it can be used to generate the node public key of that target read-only node); the first domain name is the domain name of the target read-only node, which other nodes can access.

[0028] As can be seen, in the event of a consensus node failure, this scheme updates the node's private key through the management subsystem and the node's domain name through the domain name subsystem. This allows the updated target read-only node to use the identity of any of the aforementioned consensus nodes and participate in consensus as a consensus node. Thus, while maintaining the node's external identity, the target read-only node replaces any of the aforementioned consensus nodes. It is understandable that, compared to deleting a node and then adding a new one, this scheme only requires updating the target read-only node's private key and domain name to replace the old node with the new one. The replacement process is simple and efficient, quickly restoring the fault tolerance of the consensus network and thereby improving the stability of the blockchain system. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a flowchart of a node update method provided in an exemplary embodiment.

[0031] Figure 2 This is an exemplary embodiment of a schematic diagram of a consensus node before a failure.

[0032] Figure 3 This is a schematic diagram of a node after a consensus node failure, provided as an exemplary embodiment.

[0033] Figure 4 This is a schematic diagram of a node after a faulty node has been replaced, provided as an exemplary embodiment.

[0034] Figure 5 This is a schematic diagram of a node after a faulty node has been recovered, provided as an exemplary embodiment.

[0035] Figure 6 This is a flowchart of another node update method provided in an exemplary embodiment.

[0036] Figure 7 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0037] Figure 8 This is a block diagram of a node update apparatus provided in an exemplary embodiment.

[0038] Figure 9 This is a block diagram of another node update apparatus provided in an exemplary embodiment. Detailed Implementation

[0039] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0040] A blockchain system establishes a distributed network through multiple nodes, where any two nodes communicate at the application layer via a peer-to-peer (P2P) network. The blockchain system utilizes a chained block structure to construct a decentralized (or multi-centralized) distributed ledger, which is stored on each node (or most nodes, such as consensus nodes) within the distributed blockchain system. Therefore, the blockchain system needs to address the issue of consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Accordingly, each node in the blockchain system runs a blockchain program. With certain fault tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions. Transactions are packaged into blocks, and the world state is updated based on the execution results of the same transactions. The current mainstream consensus mechanisms include, but are not limited to: Proof of Work (POW), Proof of Stake (POS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0041] Blockchain networks typically contain consensus nodes that cooperate to reach a consensus on blocks or messages. Taking the PBFT algorithm as an example, with n consensus nodes, it can tolerate f (where n > 3f + 1) nodes failing (or acting maliciously). However, when one or more consensus nodes fail due to malfunction or other reasons, a new consensus node needs to be added to restore the network's original fault tolerance to ensure its continued operation. For instance, in a network with four consensus nodes (n = 4, f = 1), if one node fails, the network becomes intolerant (if another node fails, the remaining nodes will be insufficient to reach a consensus). Therefore, a new node can be added to restore the network's fault tolerance to the original four nodes (i.e., tolerating at most one node failure).

[0042] In related technologies, when a consensus node fails, the administrator typically deletes the node from the consensus network and then adds a new node as the new consensus node. However, this method is labor-intensive and time-consuming, making the blockchain network unable to tolerate any consensus node errors for an extended period. This hinders the rapid restoration of the consensus network's fault tolerance and is detrimental to the stable and efficient operation of the blockchain network.

[0043] To address the aforementioned problems in related technologies, this specification proposes a node update method. The management subsystem of the blockchain system updates the node's private key, and the domain name subsystem updates the domain names recorded in the DNS list, thereby enabling rapid replacement of faulty nodes and quickly restoring the fault tolerance capability of the consensus network. The scheme is described in detail below with reference to the accompanying drawings.

[0044] The node update method described in this specification is applied to a blockchain system, which includes a blockchain network, a management subsystem, and a domain name subsystem. The blockchain network comprises consensus nodes that participate in consensus and read-only nodes that do not. The management subsystem manages the consensus nodes and the read-only nodes. The domain name subsystem provides domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list. Each consensus node and each read-only node has a corresponding entry in the DNS list recording the mapping relationship between its IP address and its domain name. A domain name is the name of a computer or group of computers on the Internet, consisting of a string of characters separated by dots, used to identify the computer's electronic location during data transmission. The domain name of any node can be considered a substitute for its IP address for ease of memorization. For example, wikipedia.org is a domain name corresponding to the IP address 208.80.152.2.

[0045] As can be seen, the management subsystem and the domain name subsystem are bypass systems of the blockchain network. These bypass systems are used to cooperate with various blockchain nodes in the blockchain network to implement preset blockchain functions such as transaction initiation, message broadcasting, block consensus, transaction execution, and data storage. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating a node update method provided in an exemplary embodiment. Figure 1 As shown, the method includes steps 102-106.

[0046] Step 102: When the management subsystem determines that any consensus node cannot participate in the consensus, it obtains the first private key of the consensus node and selects a target read-only node from the read-only nodes.

[0047] The blockchain network described in this specification includes consensus nodes and read-only nodes. When all consensus nodes in the blockchain network participate normally in consensus, they can form a consensus network to participate in consensus, such as consensus on any transaction or block in the blockchain network. Unlike consensus nodes, read-only nodes do not participate in consensus. Furthermore, read-only nodes can synchronize blockchain data (such as on-chain blocks, world state, etc.) from the consensus network. For example, when any block passes consensus (at which point all consensus nodes record the block), each read-only node can synchronize the block from the consensus network. Therefore, at any given time, the blockchain data recorded by read-only nodes and consensus nodes may be the same or different. The difference is due to synchronization delay, and this incremental data, which is saved by consensus nodes but not by read-only nodes, is usually relatively small. It should be noted that, apart from the differences in whether they participate in consensus and the data stored locally, the consensus nodes and read-only nodes described in the embodiments of this specification do not have any functional differences compared to other solutions. This is the functional basis for this solution to use a target read-only node to replace any consensus node.

[0048] Furthermore, the number of consensus nodes is multiple. If all consensus nodes participate in consensus according to the aforementioned PBFT algorithm, the number of consensus nodes, n, needs to be no less than 3f+1, where f represents the fault tolerance capability of the consensus network (the size of f is positively correlated with the fault tolerance capability). The number of read-only nodes can be one or more. Of course, this solution does not impose any restrictions on the specific number of consensus nodes and read-only nodes. Additionally, in some scenarios, the blockchain network may also include nodes other than consensus nodes and read-only nodes (used to implement other functions); this solution does not focus on these types of nodes.

[0049] like Figure 2 As shown, let's assume there are four consensus nodes in the blockchain network, namely domain0 to domain3. Domain0's IP address (ip0) is 0.0.0.0, and its domain name (url) is x0.com. The meanings of the IP addresses and domain names of domains 1 to 3 are similar; see [link to relevant documentation]. Figure 1 This will not be elaborated further. At this point, domains 0-3 constitute the consensus network in the blockchain network. Additionally, the blockchain network also contains two read-only nodes, domains 4-5, which can respectively perform necessary data interactions with their respective consensus nodes (e.g., ...). Figure 1 As shown by the bidirectional arrows, it can synchronize blockchain data that has passed consensus from the consensus nodes it is connected to. It should be noted that... Figure 1Each domain (i.e., any node) shown can be a process or a group of processes. These processes form a blockchain node in the blockchain network at the logical level, which is used to implement blockchain nodes with functions such as consensus, data synchronization, and accounting.

[0050] exist Figure 1 During normal operation, as shown, domains 0 through 3 can participate in proposing and reaching consensus on any block (e.g., block B0), as well as executing transactions within that block and updating their locally maintained blockchain ledger. After block B0 is executed, domains 0 through 3 can broadcast notification messages for that block within the blockchain network. For example, the notification message broadcast by domain0 may include domain0's node identifier (e.g., "domain0" or its public key), the hash of block B0, and a node signature using domain0's private key on the hash of block B0. Once other nodes in the blockchain network receive a preset number (e.g., at least 2f+1) of these notification messages, they can accept block B0, persist it in their local storage (updating their own maintained blockchain ledger), and set the block to a stable state, thus completing the process of adding the block to the blockchain.

[0051] Unlike consensus nodes, domains 4-5, as read-only nodes, do not participate in consensus or proposals. Instead, they pull stable blocks from other nodes and, after obtaining a preset number of domain signatures, execute the transactions within that block and update their locally maintained blockchain ledger. Therefore, the blockchain data (such as the blockchain ledger) maintained by read-only nodes is almost identical to that of consensus nodes (though it may lag slightly at times). For example, the domain name subsystem maintains... Figure 2 The DNS list corresponding to each node is shown in Table 1 below:

[0052] Table 1

[0053] node IP address domain name state domain0 0.0.0.0 X0.com efficient domain1 1.1.1.1 x1.com efficient domain2 2.2.2.2 x2.com efficient domain3 3.3.3.3 x3.com efficient domain4 4.4.4.4 x4.com efficient domain5 5.5.5.5 x5.com efficient

[0054] At any given time, any consensus node in the consensus network may be unable to continue participating in consensus for various reasons. For example, any consensus node may receive a consensus stop instruction initiated by its owner or the blockchain network administrator, which can be used to instruct the consensus node to cease participating in consensus. In this case, although the consensus node still possesses the hardware and software capabilities to participate in consensus, it needs to respond to the consensus stop instruction and cease participating in consensus. As another example, any consensus node may also experience hardware or software failures (such as software failures in the network or processes, hardware failures in the disk, or even a system crash). These failures will cause the node to lose the hardware and software capabilities to participate in consensus, and naturally, it will be unable to continue participating in consensus.

[0055] In one embodiment, the management subsystem can detect the inability of any consensus node in the consensus network to participate in consensus in multiple ways. For example, the management subsystem can determine that any consensus node is unable to participate in consensus upon receiving a consensus stop message initiated by the owner of any consensus node or the administrator of the blockchain network. As another example, if any consensus node malfunctions, it can send a fault notification message to the management subsystem; or, other nodes in the blockchain network, upon sensing a fault in any consensus node, can also send a fault notification message to the management subsystem for that consensus node. Based on this, the management subsystem can determine that a node is unable to participate in consensus upon receiving such a fault notification message. Furthermore, since the consensus nodes in the consensus network may be unable to reach consensus on new blocks if any consensus node is unable to participate in consensus, and considering that the block production interval of the consensus network (i.e., the interval between two adjacent blocks) is usually relatively stable, the management subsystem can determine the inability to participate in consensus based on the working status of each consensus node if the consensus node fails to reach consensus on a new block after a preset time. The preset duration can be the aforementioned block interval or a preset multiple thereof, which will not be elaborated further.

[0056] like Figure 3 As shown, let's assume that any consensus node that cannot participate in the consensus is domain3 (if domain3 fails, it becomes a failed node). At this point, domains0-2 in the original consensus network still constitute the consensus network, while domain3 can leave the consensus network. Clearly, although the remaining (normal) consensus nodes in the network can continue to reach consensus (at this point, 3 = 2f + 1), their fault tolerance is reduced. The consensus network can no longer tolerate any further failures of any consensus node. At this point, the management subsystem can begin executing step 102 to upgrade any read-only node (i.e., the target read-only node below) to a consensus node, thereby restoring the fault tolerance of the consensus network.

[0057] Alternatively, if any consensus node is unable to participate in the consensus process, the management subsystem can first determine if the number of remaining consensus nodes at the current moment meets the consensus requirements. If it does, step 102 can be skipped; otherwise, step 102 will be executed. In other words, the management subsystem can obtain the first private key of any consensus node and select a target read-only node from the read-only nodes if the number of remaining consensus nodes capable of participating in the consensus process does not meet the consensus requirements.

[0058] Still with Figure 1 and Figure 2 For example, as mentioned earlier, in the event of a domain 3 failure, the remaining domains 0-2 can still achieve consensus, meaning the number of remaining consensus nodes meets the consensus requirements. Therefore, the management subsystem can temporarily suspend step 102. Subsequently, if domain 3 recovers its consensus capability first (e.g., after a failure), it can be rejoined to the consensus network to continue participating in consensus. Of course, if another consensus node fails to participate in consensus before domain 3's consensus capability recovers (e.g., domain 2 also fails), then since the two remaining consensus nodes at the current moment are insufficient to complete consensus, the management subsystem can execute step 102 for the failed domain 3 and / or domain 2 to convert at least one read-only node in the blockchain network into a consensus node, join the consensus network to participate in consensus, and thus restore the consensus capability of the consensus network as soon as possible.

[0059] As can be seen, the management subsystem can obtain the first private key of any consensus node when the number of consensus nodes currently available is insufficient to provide consensus services, and then select a target read-only node from among the read-only nodes. This approach minimizes the number of times this scheme is executed—it is only executed when the consensus network is insufficient to provide consensus services, thus reducing the number of node replacements.

[0060] In one embodiment, the management subsystem may randomly select a target read-only node from all read-only nodes; or, in order to minimize the amount of routing changes during communication between other nodes and the target read-only node after the target read-only node replaces any consensus node, the read-only node whose IP address is closest to any consensus node may be selected as the target read-only node.

[0061] Step 104: The management subsystem sends a first domain name update message to the domain name subsystem for any consensus node and the target read-only node; and updates the node private key of the target read-only node from the second private key to the first private key.

[0062] The first domain name update message may include the node identifiers (such as the public keys of the two nodes) of any consensus node and the target read-only node, so that the domain name subsystem can respond to the message and successfully update the entries in the DNS list. It should be noted that the process of the management subsystem "sending the first domain name update message" and "updating the private key of the target read-only node" does not necessarily have a specific order. For example, the first domain name update message can be sent first and then the private key of the target read-only node can be updated, or the private key of the target read-only node can be updated first and then the first domain name update message can be sent. Alternatively, the private key of the target read-only node can be updated simultaneously with the first domain name update message. This embodiment does not limit this approach.

[0063] In one embodiment, the management subsystem can obtain the first private key of any consensus node in multiple ways. For example, considering that any consensus node necessarily maintains its own first private key, if any consensus node is still able to receive and respond to instructions (such as if the consensus node stops participating in consensus due to receiving the aforementioned consensus stop instruction, or if it experiences a failure but does not shut down), the management subsystem can send a private key retrieval instruction to that node and receive the first private key returned by the consensus node in response to the instruction. As another example, the management subsystem, the owner of any consensus node, or other third parties (such as a pre-set key escrow institution) can pre-maintain the first private key of any consensus node. In this case, the management subsystem can read the first private key locally, obtain the first private key from the aforementioned owner, or obtain the first private key from the third party. For example, the first private key mentioned above can also be obtained by a preset user (such as the management user of the blockchain network, the operation and maintenance personnel of any consensus node, etc.). In this case, the management subsystem can send a message to the preset user to obtain the private key for any consensus node. Correspondingly, the preset user can respond to the message by manually entering the first private key through a preset page or input box or by importing it from a file so that the management subsystem can obtain the private key.

[0064] In one embodiment, when updating the private key of a target read-only node, the management subsystem can first control the shutdown of the target read-only node, then update its private key from the second private key to the first private key; and, after the update is completed, control the restart of the target read-only node. It is understood that the restarted target read-only node will use the first private key as its own private key. Furthermore, the target read-only node can generate its own public key based on the first private key, which serves as its node identifier when communicating with other nodes. This public key can be generated using the same algorithm as that used to generate the first public key of any consensus node based on the first private key, ensuring that the generated public key is identical to the first public key, thereby preventing other nodes in the blockchain network from updating the identity identifier of any consensus node they maintain. Alternatively, the management subsystem can also obtain the public key of any consensus node while obtaining the first private key, and configure the public key of the target read-only node as its public key when updating the target read-only node's public key, using it as the updated node identity of the target read-only node.

[0065] Step 106: In response to the first domain name update message, the domain name subsystem queries the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and updates the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0066] Upon receiving the first domain name update message, the domain name subsystem can respond by updating entries in the DNS list. Specifically, the domain name subsystem can update the second entry corresponding to the target read-only node in the DNS list, updating the second domain name of the target read-only node recorded in that entry to the first domain name of any consensus node recorded in the first entry. Thereafter, the domain name subsystem can provide domain name resolution services for the target read-only node to the blockchain nodes based on the second entry.

[0067] After the target read-only node's private key and node domain name are updated, the target read-only node can connect to nodes in the blockchain network using the identity of any of the consensus nodes, thereby joining the consensus network. Figure 4 As shown, after the update, the domain name of domain3 remains x3.com, while its IP address remains the original IP address of domain4, 4.4.4.4. For example, the domain name subsystem maintains... Figure 4 The DNS list corresponding to each node shown is shown in Table 2 below:

[0068] Table 2

[0069]

[0070]

[0071] Understandably, before any consensus node fails, the first private key is the node private key of that consensus node, used to identify its identity in the blockchain network (e.g., it can be used to generate the node public key of that consensus node); the first domain name is the domain name of that consensus node, which other nodes can access. After any consensus node fails (i.e., the failed node), the management subsystem updates the node private key of the target read-only node from the second private key to the first private key, and the domain name subsystem updates the second domain name of the target read-only node recorded in the second entry to the first domain name. With both the second private key and the second domain name updated, the first private key becomes the private key of the target read-only node, used to identify its identity in the blockchain network (e.g., it can be used to generate the node public key of that target read-only node); the first domain name is the domain name of the target read-only node, which other nodes can access.

[0072] As can be seen, in the event of a consensus node failure, this scheme updates the node's private key through the management subsystem and the node's domain name through the domain name subsystem. This allows the updated target read-only node to use the identity of any of the consensus nodes and participate in consensus as a consensus node. Thus, while maintaining the node's external identity, the target read-only node replaces any of the consensus nodes. It is understandable that, compared to deleting a node and adding a new one, this scheme only requires updating the target read-only node's private key and domain name to replace the old node with the new one. The replacement process is simple and efficient, quickly restoring the fault tolerance of the consensus network, thereby improving the stability of the blockchain system and effectively solving the technical problems existing in related technologies.

[0073] Understandably, after the above update, both the first and second entries in the DNS list will record the first domain name. At this point, for a blockchain message targeting the first domain name, the domain name subsystem can resolve the destination IP of the message to the latest IP address corresponding to the first domain name, i.e., the IP address of the target read-only node. For example... Figure 4As shown, the Domain Name Subsystem can resolve the destination IP address of a blockchain message for x3.com to 4.4.4.4, so that the blockchain node can forward the message to the target read-only node (i.e., the current domain3). Of course, to avoid resolution confusion or to additionally record the chronological order of update times for each domain name, the first entry corresponding to any consensus node can be deleted from the DNS list, or the first entry can be set to an invalid state. This ensures that only the second entry in the DNS list records the first domain name, or only the second entry records the first domain name, thus effectively preventing the blockchain node from forwarding the message corresponding to the first domain name to any consensus node (which is currently deployed on the consensus node).

[0074] In one embodiment, after the target read-only node updates its private key and domain name, it needs to ensure that the data it stores is consistent with the data stored by other consensus nodes in order to participate in consensus. Therefore, it can synchronize incremental data from other consensus nodes. This incremental data consists of data stored by other consensus nodes but not stored by the target read-only node. Where the target read-only node has not synchronized data from consensus nodes before updating, the amount of incremental data it needs to synchronize is usually large. As mentioned earlier, there may be a synchronization delay during the process of the read-only node synchronizing data from consensus nodes. Without a synchronization delay, the target read-only node can participate in consensus immediately after updating its private key and domain name; however, with a synchronization delay, the data stored by the target read-only node is usually less than the data stored by other consensus nodes outside of the aforementioned consensus nodes. That is, there is a portion of incremental data stored by other consensus nodes that the target read-only node does not store, so the target read-only node can synchronize this incremental data from the other consensus nodes. It is understandable that even if there is a synchronization delay between consensus nodes and read-only nodes, the incremental data between the target read-only node and other existing consensus nodes in the consensus network after the update is completed is usually relatively small. Therefore, the target read-only node only needs to synchronize this small amount of data to start participating in consensus. Although it is called a "target read-only node", the node is essentially a consensus node at this time.

[0075] After the target read-only node's private key and domain name are updated, the target read-only node can participate in consensus as a member of the consensus network. If any consensus node is unable to participate in consensus due to its own failure, it can still participate in the blockchain network once the failure has been resolved. Since the consensus network can now reach consensus normally, any consensus node that has recovered from its failure can be set as a read-only node.

[0076] For example, the management subsystem can, upon determining that the failure of any consensus node has been recovered, send a second domain name update message to the domain name subsystem for both the consensus node and the target read-only node; and update the private key of the consensus node from the first private key to the second private key. Correspondingly, the domain name subsystem can, in response to the second domain name update message, update the first domain name recorded in the first entry corresponding to the consensus node in the DNS list to the second domain name. Following the foregoing embodiments, if the first entry is deleted, the domain name subsystem can create a new first entry in the DNS list and record the second domain name in it. If the first entry is set to an invalid state, the domain name subsystem can update the first domain name recorded in the first entry to the second domain name and reset the entry to a valid state. Thereafter, the domain name subsystem can provide domain name resolution services for the blockchain nodes based on the first entry for the consensus node.

[0077] like Figure 5 As shown, after updating the private key and domain name of any consensus node that has recovered from the fault (i.e., the original domain3, now domain4), the node's IP address is updated to 3.3.3.3, and its domain name is updated to x4.com. In this way, any consensus node can participate in the blockchain network as the target read-only node—although called a "consensus node," it is essentially a read-only node at this point. For example, the domain name subsystem maintains... Figure 5 The DNS list corresponding to each node shown is shown in Table 3 below:

[0078] Table 3

[0079]

[0080]

[0081] In the above, as Figure 1 The illustrated embodiment describes the node update process of the scheme described in this specification from the perspective of the entire blockchain system. The following section, in conjunction with... Figure 6 This specification describes the technical solution from the perspective of the management subsystem. It is easy to understand that... Figure 6 The illustrated embodiments and Figure 1 The embodiments shown are not fundamentally different, as previously stated... Figure 1 The descriptions of the embodiments shown are all applicable to Figure 6 The example shown.

[0082] Figure 6This is a flowchart illustrating another node update method provided in an exemplary embodiment. The method is applied to a management subsystem in a blockchain system, which further includes a blockchain network and a domain name subsystem. The blockchain network contains consensus nodes participating in consensus and read-only nodes not participating in consensus. The management subsystem manages the consensus nodes and the read-only nodes. The domain name subsystem provides domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list. The corresponding entry in the DNS list for any consensus node or read-only node records the mapping relationship between the node's IP address and its domain name. Figure 6 As shown, the method includes steps 602-606.

[0083] Step 602: If it is determined that any consensus node cannot participate in the consensus, obtain the first private key of the consensus node and select a target read-only node from the read-only nodes.

[0084] Step 604: Update the private key of the target read-only node from the second private key to the first private key.

[0085] Step 606: Send a first domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the first domain name update message by querying the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0086] In one embodiment, if any consensus node is unable to participate in consensus due to its own failure, the method further includes:

[0087] If it is determined that the failure of any of the consensus nodes has been recovered, the private key of any of the consensus nodes is updated from the first private key to the second private key; and,

[0088] Send a second domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the second domain name update message and updates the first domain name recorded in the first entry of the DNS list corresponding to any consensus node to the second domain name.

[0089] For details of the various embodiments of the node update method executed by the management subsystem, please refer to the descriptions in the foregoing embodiments, which will not be repeated here.

[0090] Figure 7 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 7At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 710, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into memory 708 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0091] like Figure 8 As shown, Figure 8 This is a block diagram of a node update apparatus provided in this specification according to an exemplary embodiment. The apparatus can be applied to, for example... Figure 7 The device shown implements the technical solution of this specification. The device is applied to a blockchain system, which includes a blockchain network, a management subsystem, and a domain name subsystem. The blockchain network includes consensus nodes participating in consensus and read-only nodes not participating in consensus. The management subsystem manages the consensus nodes and the read-only nodes. The domain name subsystem provides domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list. Each consensus node and each read-only node has a corresponding entry in the DNS list recording the mapping relationship between its IP address and domain name. The device includes:

[0092] The acquisition and selection unit 801 is used to enable the management subsystem to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes.

[0093] The sending and updating unit 802 is configured to cause the management subsystem to send a first domain name update message for any consensus node and the target read-only node to the domain name subsystem; and to update the node private key of the target read-only node from the second private key to the first private key;

[0094] The domain name update unit 803 is used to cause the domain name subsystem to respond to the first domain name update message, query the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and update the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry.

[0095] Optional, also includes:

[0096] The entry processing unit 804 is used to cause the domain name subsystem to delete the first entry in the DNS list or set the first entry to an invalid state.

[0097] Optional, also includes:

[0098] The data synchronization unit 805 is used to enable the target read-only node to synchronize incremental data from other consensus nodes after the node private key and domain name are updated. The incremental data is data that is saved by other consensus nodes but not saved by the target read-only node.

[0099] Optionally, the acquisition and selection unit 801 is further configured to:

[0100] The management subsystem, upon detecting a consensus stop command or fault notification message for any consensus node, determines that any consensus node is unable to participate in the consensus process; or,

[0101] If the consensus node fails to reach a consensus on a new block within a preset time period, the management subsystem determines any consensus node that cannot participate in the consensus based on the working status of each consensus node.

[0102] Optionally, the acquisition and selection unit 801 is further used for one of the following:

[0103] The management subsystem initiates a private key acquisition instruction to any consensus node and receives the first private key returned by any consensus node in response to the instruction.

[0104] If the management subsystem or a third party has backed up the first private key of any of the consensus nodes, the management subsystem may obtain the first private key from the local machine or the third party.

[0105] The management subsystem initiates a private key retrieval message for any consensus node to a preset user, and receives the first private key specified by the preset user.

[0106] Optionally, the sending and updating unit 802 is further configured to:

[0107] The management subsystem controls the shutdown of the target read-only node and updates the node private key of the target read-only node from the second private key to the first private key; and, after the update is completed, controls the restart of the target read-only node.

[0108] Optionally, the acquisition and selection unit 801 is further configured to:

[0109] If the number of consensus nodes that the management subsystem can participate in at the current time is insufficient to provide consensus services, the subsystem obtains the first private key of any consensus node and selects a target read-only node from the read-only nodes.

[0110] Optionally, if any consensus node is unable to participate in consensus due to its own failure, the device further includes:

[0111] The second sending and updating unit 806 is configured to enable the management subsystem to send a second domain name update message for the consensus node and the target read-only node to the domain name subsystem when it is determined that the failure of any consensus node has been recovered; and to update the node private key of any consensus node from the first private key to the second private key.

[0112] The second domain name update unit 807 is used to cause the domain name subsystem to respond to the second domain name update message and update the first domain name recorded in the first entry of the DNS list corresponding to any consensus node to the second domain name.

[0113] like Figure 9 As shown, Figure 9 This is a block diagram of another node update apparatus provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 7 The device shown implements the technical solution of this specification. The device is applied to a management subsystem of a blockchain system, which further includes a blockchain network and a domain name subsystem. The blockchain network includes consensus nodes participating in consensus and read-only nodes not participating in consensus. The management subsystem manages the consensus nodes and the read-only nodes. The domain name subsystem provides domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list. Each consensus node and each read-only node has a corresponding entry in the DNS list recording the mapping relationship between its IP address and domain name. The device includes:

[0114] The acquisition and selection unit 901 is used to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes.

[0115] Private key update unit 902 is used to update the node private key of the target read-only node from the second private key to the first private key;

[0116] The message sending unit 903 is used to send a first domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the first domain name update message by querying the first entry corresponding to the consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of the consensus node recorded in the first entry.

[0117] Optionally, if any consensus node is unable to participate in consensus due to its own failure, the device further includes:

[0118] The second private key update unit 904 is used to update the private key of any consensus node from the first private key to the second private key when it is determined that the failure of any consensus node has been recovered; and,

[0119] The second message sending unit 905 is used to send a second domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the second domain name update message and updates the first domain name recorded in the first entry of the DNS list corresponding to any consensus node to the second domain name.

[0120] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0121] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0122] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this invention does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0123] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0124] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0125] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0126] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0127] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0128] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0129] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0130] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0131] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0132] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0133] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0134] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A node update method applied to a blockchain system, the blockchain system comprising a blockchain network, a management subsystem, and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list, wherein each of the consensus nodes and the read-only nodes has a corresponding entry in the DNS list recording the mapping relationship between the node's IP address and its domain name, the method comprising: If the management subsystem determines that any consensus node cannot participate in the consensus, it obtains the first private key of the consensus node and selects a target read-only node from the read-only nodes. The management subsystem sends a first domain name update message to the domain name subsystem for any consensus node and the target read-only node; In addition, the private key of the target read-only node is updated from the second private key to the first private key, so that the target read-only node can use the first private key to generate the same public key and signature as any consensus node, thereby inheriting the node identity of any consensus node in the blockchain network. In response to the first domain name update message, the domain name subsystem queries the DNS list for the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node, and updates the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry. This allows other nodes in the blockchain system to access the target read-only node through the IP address resolved by the first domain name, and, in conjunction with the first private key held by the target read-only node, identify the target read-only node as any consensus node to continue participating in consensus.

2. The method according to claim 1, further comprising: The Domain Name Subsystem deletes the first entry in the DNS list or sets the first entry to an invalid state.

3. The method according to claim 1, further comprising: After the target read-only node completes the update of its private key and domain name, it synchronizes incremental data from other consensus nodes. The incremental data is data that is saved by other consensus nodes but not by the target read-only node.

4. The method according to claim 1, wherein the management subsystem determines that any consensus node cannot participate in the consensus, including: If the management subsystem detects a consensus stop instruction or fault notification message for any consensus node, it determines that the consensus node cannot participate in the consensus process. or, If the consensus nodes fail to reach a consensus on a new block within a preset time period, the management subsystem determines any consensus node that cannot participate in the consensus based on the working status of each consensus node.

5. The method according to claim 1, wherein the management subsystem obtains the first private key of any consensus node, including one of the following: The management subsystem sends a private key acquisition instruction to any consensus node and receives the first private key returned by any consensus node in response to the instruction. If the management subsystem or a third party has backed up the first private key of any of the consensus nodes, the management subsystem obtains the first private key from the local machine or the third party. The management subsystem initiates a private key retrieval message for any of the consensus nodes to the preset user, and receives the first private key specified by the preset user.

6. The method according to claim 1, wherein the management subsystem updates the node private key of the target read-only node from the second private key to the first private key, comprising: The management subsystem controls the shutdown of the target read-only node and updates the node private key of the target read-only node from the second private key to the first private key; And, after the update is complete, control the restart of the target read-only node.

7. The method according to claim 1, wherein the management subsystem obtains the first private key of any consensus node and selects a target read-only node from the read-only nodes, comprising: If the number of consensus nodes that can participate in the consensus at the current time is insufficient to provide consensus services, the management subsystem obtains the first private key of any consensus node and selects a target read-only node from the read-only nodes.

8. The method according to claim 1, wherein any consensus node is unable to participate in consensus due to its own failure, the method further includes: When the management subsystem determines that the failure of any consensus node has been recovered, it sends a second domain name update message for the consensus node and the target read-only node to the domain name subsystem; and updates the private key of the consensus node from the first private key to the second private key. In response to the second domain name update message, the domain name subsystem updates the first domain name recorded in the first entry of the DNS list corresponding to any consensus node to the second domain name.

9. A node update method applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on its own maintained Domain Name System (DNS) list, each of the consensus nodes and the read-only nodes having a corresponding entry in the DNS list recording the mapping relationship between the node's IP address and domain name, the method comprising: If it is determined that any consensus node cannot participate in the consensus, obtain the first private key of the consensus node, and select a target read-only node from the read-only nodes; The target read-only node's private key is updated from the second private key to the first private key, so that the target read-only node can use the first private key to generate the same node public key and node signature as any consensus node, thereby inheriting the node identity of any consensus node in the blockchain network. A first domain name update message is sent to the domain name subsystem for both the consensus node and the target read-only node. In response to this message, the domain name subsystem queries the DNS list for the first entry corresponding to the consensus node and the second entry corresponding to the target read-only node. The second domain name of the target read-only node recorded in the second entry is updated to the first domain name of the consensus node recorded in the first entry. This allows other nodes in the blockchain system to access the target read-only node via the IP address resolved from the first domain name. Combined with the first private key held by the target read-only node, the target read-only node is identified as one of the consensus nodes and allowed to continue participating in the consensus process.

10. The method according to claim 9, wherein any consensus node is unable to participate in consensus due to its own failure, the method further includes: If it is determined that the failure of any consensus node has been recovered, the node private key of any consensus node is updated from the first private key to the second private key; as well as, Send a second domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the second domain name update message and updates the first domain name recorded in the first entry of the DNS list corresponding to any consensus node to the second domain name.

11. A node update device applied to a blockchain system, the blockchain system comprising a blockchain network, a management subsystem, and a domain name subsystem, the blockchain network comprising consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on a DNS list it maintains, each of the consensus nodes and the read-only nodes having a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the device comprising: The acquisition and selection unit is used to enable the management subsystem to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes; The sending and updating unit is configured to enable the management subsystem to send a first domain name update message for any consensus node and the target read-only node to the domain name subsystem. In addition, the private key of the target read-only node is updated from the second private key to the first private key, so that the target read-only node can use the first private key to generate the same public key and signature as any consensus node, thereby inheriting the node identity of any consensus node in the blockchain network. The domain name update unit is configured to cause the domain name subsystem to respond to the first domain name update message, query the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and update the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry, so that other nodes in the blockchain system can access the target read-only node through the IP address resolved by the first domain name, and, in conjunction with the first private key held by the target read-only node, identify the target read-only node as any consensus node to continue participating in consensus.

12. A node update device, applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network and a domain name subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the management subsystem for managing the consensus nodes and the read-only nodes, the domain name subsystem providing domain name resolution services to each node in the blockchain network based on a DNS list it maintains, each of the consensus nodes and the read-only nodes having a corresponding entry in the DNS list recording a mapping relationship between the node's IP address and a domain name, the device comprising: The acquisition and selection unit is used to acquire the first private key of any consensus node when it is determined that any consensus node cannot participate in the consensus, and to select a target read-only node from the read-only nodes. The private key update unit is used to update the private key of the target read-only node from the second private key to the first private key, so that the target read-only node can use the first private key to generate the same node public key and node signature as any consensus node, thereby inheriting the node identity of any consensus node in the blockchain network. The message sending unit is configured to send a first domain name update message to the domain name subsystem for any consensus node and the target read-only node, so that the domain name subsystem responds to the first domain name update message by querying the first entry corresponding to any consensus node and the second entry corresponding to the target read-only node in the DNS list, and updating the second domain name of the target read-only node recorded in the second entry to the first domain name of any consensus node recorded in the first entry, so that other nodes in the blockchain system can access the target read-only node through the IP address resolved by the first domain name, and, in conjunction with the first private key held by the target read-only node, identify the target read-only node as any consensus node to continue participating in consensus.

13. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-10 by executing the executable instructions.

14. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

Images