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 and a management subsystem, the blockchain network containing consensus nodes participating in consensus and read-only nodes not participating in consensus, type information of the consensus nodes and the read-only nodes being recorded in a contract state of a system contract of the blockchain network, and the type information of any node being used to represent whether the node is a consensus node or a read-only node. The method includes: the management subsystem selecting a target read-only node from the read-only nodes in a case where it is determined that any consensus node cannot participate in consensus; the management subsystem initiating a first updating transaction for the target read-only node to the blockchain network; and any node in the blockchain network modifying type information of the target read-only node by calling the system contract when the first updating transaction is executed, so as to update the target read-only node to a 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 and a management subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the method comprising:

[0006] If the management subsystem determines that any consensus node cannot participate in the consensus, it will select a target read-only node from the read-only nodes.

[0007] The management subsystem initiates a first update transaction for the target read-only node to the blockchain network;

[0008] When any node in the blockchain network executes the first update transaction, it modifies the type information of the target read-only node by calling the system contract, so as to update the target read-only node into a consensus node.

[0009] According to a second aspect of one or more embodiments of this specification, a node update method is proposed, applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the method comprising:

[0010] If it is determined that any consensus node cannot participate in the consensus, a target read-only node is selected from the read-only nodes;

[0011] A first update transaction is initiated to the blockchain network for the target read-only node. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to modify the type information of the target read-only node, so as to update the target read-only node into a consensus node.

[0012] According to a third aspect of one or more embodiments of this specification, a node update apparatus is provided, applied to a blockchain system, the blockchain system including a blockchain network and a management subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the apparatus comprising:

[0013] The node selection unit is used to enable the management subsystem to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus.

[0014] The first initiating unit is used to enable the management subsystem to initiate a first update transaction for the target read-only node to the blockchain network.

[0015] The first update unit is used to enable any node in the blockchain network to modify the type information of the target read-only node by calling the system contract when executing the first update transaction, so as to update the target read-only node into a consensus node.

[0016] According to a fourth aspect of one or more embodiments of this specification, a node update apparatus is provided, applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the apparatus comprising:

[0017] A node selection unit is used to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus.

[0018] The first initiating unit is used to initiate a first update transaction for the target read-only node to the blockchain network. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to modify the type information of the target read-only node, so as to update the target read-only node to a consensus node.

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

[0020] processor;

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

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

[0023] 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.

[0024] In the embodiments described in this specification, when the management subsystem of the blockchain system determines that any consensus node cannot participate in the consensus, it selects a target read-only node from the read-only nodes and then initiates a first update for the target read-only node to the blockchain network. When any node in the blockchain network executes the first update transaction, it modifies the type information of the target read-only node by calling the system contract to update the target read-only node to a consensus node.

[0025] It is understandable that, since the system contract of the blockchain network records the type information of the consensus node and the read-only node in the contract state, and the contract state is maintained by each node in the blockchain network, the type information of the target read-only node is also maintained by each node in the contract state of the system contract. For the first update transaction initiated by the management subsystem, any node in the blockchain network can modify the type information of the target read-only node it maintains during the execution of the transaction. This transaction can be executed by each node in the blockchain network, so each node can modify the type information of the target read-only node it maintains. Therefore, after a sufficient number of nodes in the blockchain network have completed the execution of the first update transaction, the target read-only node can be updated to a consensus node at the blockchain network level, realizing the replacement of any consensus node by the target read-only node. Compared to the process of deleting a node and then adding a new node, this scheme only requires executing a transaction that calls the system contract to achieve the replacement of the old and new nodes. The replacement process is simple and efficient, and can quickly restore the fault tolerance of the consensus network, thereby improving the stability of the blockchain network. Attached Figure Description

[0026] 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.

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

[0028] Figure 2 This is a schematic diagram of a consensus node before a failure, provided as an exemplary embodiment.

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

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

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

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

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

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

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

[0036] 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.

[0037] 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.

[0038] 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).

[0039] 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.

[0040] To address the aforementioned problems in related technologies, this specification proposes a node update method. When any consensus node is unable to participate in consensus, the type information of the target read-only node is modified by executing a first update transaction that calls the system contract, thereby updating it to a consensus node to replace any previously mentioned consensus node. The solution is described in detail below with reference to the accompanying drawings.

[0041] The node update method described in this specification is applied to a blockchain system, which includes a blockchain network and a management subsystem. The blockchain network includes consensus nodes that participate in consensus and read-only nodes that do not participate in consensus. The contract state of the system contract of the blockchain network records the type information of the consensus nodes and the read-only nodes. The type information of any node is used to characterize whether the node is a consensus node or a read-only node.

[0042] The management subsystem is a bypass system within the blockchain network. Such bypass systems cooperate with various blockchain nodes in the network to implement preset blockchain functions such as transaction initiation, message broadcasting, block consensus, transaction execution, and data storage. In fact, the management subsystem can be used to manage various blockchain nodes within the network. In addition to the management subsystem, the blockchain system may also include a domain name subsystem that maintains a DNS list. The entry in the DNS list corresponding to any node in the blockchain network can record the mapping relationship between the node's IP address and domain name. The domain name subsystem can provide domain name resolution services to various nodes in the blockchain network based on the DNS list. Of course, the blockchain system may also include other bypass systems with corresponding functions, which will not be elaborated further.

[0043] Please see 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.

[0044] Step 102: If the management subsystem determines that any consensus node cannot participate in the consensus, it selects a target read-only node from the read-only nodes.

[0045] Step 104: The management subsystem initiates a first update transaction for the target read-only node to the blockchain network.

[0046] 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.

[0047] 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.

[0048] 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 1 Each 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 realize a blockchain node with functions such as data synchronization and accounting.

[0049] 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.

[0050] Unlike consensus nodes, domains 4 and 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 signatures from domains, execute the transactions within that block and update the locally maintained blockchain ledger. Therefore, the blockchain data (such as the blockchain ledger) maintained by read-only nodes is almost entirely consistent with that of consensus nodes (though it may lag slightly at certain times).

[0051] In addition to recording the type information of each node, the contract state of the system contract described in this specification may also record node identifiers (or node IDs), IP addresses, domain names, and other related information; these can be collectively referred to as domain information. This domain information can be stored using a key-value pair data structure. For example, Figure 1 The domain information for each node shown is as follows:

[0052] 1.key<domain0's id> ,value{"url":"x0.com","is_consensus_domain":true}

[0053] 2.key<domain1's id> ,value{"url":"x1.com","is_consensus_domain":true}

[0054] 3.key<domain2's id> ,value{"url":"x2.com","is_consensus_domain":true}

[0055] 4.key<domain3's id> ,value{"url":"x3.com","is_consensus_domain":true}

[0056] 5.key<domain4's id> ,value{"url":"x4.com","is_consensus_domain":false}

[0057] 6.key<domain5's id> ,value{"url":"x5.com","is_consensus_domain":false}

[0058] Taking domain0 as an example, "domain0's id" is the node identifier of domain0, which can be the node's public key; "url" is the IP address of domain0, such as 1.1.1.1; "x0.com" is the domain name of domain0. As mentioned earlier, the mapping relationship between this IP address and the domain name can be recorded in the DNS list maintained by the aforementioned domain name subsystem; "is_consensus_domain":true" is the type information of domain0, where the consensus identifier is true, indicating that domain0 is a consensus node. The domain information of other nodes is similar to that of domain0 and will not be described in detail. It should be noted that the consensus identifier recorded in the type information of domain4 and domain5 is false, indicating that domain4 and domain5 are both consensus nodes.

[0059] At any given time, any consensus node in the consensus network may be unable to continue participating in consensus for various reasons. For example, a consensus node may receive a consensus stop instruction initiated by its owner or the blockchain network administrator, which can instruct the node to cease participating in consensus. In this case, although the node still possesses the software / hardware capabilities to participate in consensus, it needs to comply with the consensus stop instruction and cease participation. As another example, a consensus node may also experience software / hardware 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 its software / hardware capabilities to participate in consensus, thus preventing it from continuing to participate.

[0060] In one embodiment, the management subsystem can detect the inability of any consensus node to participate in consensus in various ways. For example, the management subsystem can determine that a consensus node is unable to participate in consensus if it receives a consensus stop instruction initiated by the owner or the administrator of the blockchain network targeting that consensus node. Another example is that if any consensus node malfunctions, it can send a fault notification message to the management subsystem; or, other nodes in the blockchain network can also send a fault notification message to the management subsystem upon detecting a fault in any consensus node. Accordingly, 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 (i.e., the time interval between two adjacent blocks) of the consensus network is usually relatively stable, the management subsystem can determine the unreachable consensus node 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, etc., which will not be elaborated further.

[0061] like Figure 3 As shown, let's assume that any consensus node that cannot participate in the consensus is domain3 (e.g., domain3 becomes a failed node due to a failure). In this case, domains0-2 in the original consensus network still constitute the consensus network, while domain3 can leave the consensus network (but the type information of domain3 recorded in the system contract's contract state has not yet changed). According to the PBFT algorithm, Figure 3 The minimum number of consensus nodes in the blockchain network shown is 3. Clearly, even if domain3 fails, the remaining (normal) consensus nodes in the network can still reach consensus (2f+1=3), but their fault tolerance is reduced. The network can no longer tolerate any further failure 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 network's fault tolerance.

[0062] In one embodiment, the first update transaction initiated by the management subsystem in step 104 can be a blockchain transaction that can be executed without consensus; or it can be a blockchain transaction that can only be executed after consensus is reached. Depending on whether consensus is required before the execution of the first update transaction, the management subsystem can select a target read-only node at different times if any consensus node cannot participate in the consensus process.

[0063] For example, if the first update transaction does not require consensus, then each consensus node in the blockchain network can execute the transaction without the participation of all consensus nodes. Therefore, regardless of whether the remaining consensus nodes can continue to reach consensus at the current moment (i.e., after any of the aforementioned consensus nodes cannot participate in consensus), it does not affect the smooth execution of the first update transaction, and any of the aforementioned consensus nodes can be replaced by the target read-only node.

[0064] For example, when consensus is required for the first update transaction, to ensure its successful execution, the management subsystem can first determine whether the number of consensus nodes currently capable of participating in the consensus is sufficient to meet the consensus requirements. If it is (i.e., the number of consensus nodes capable of participating in the consensus is not less than the minimum number of consensus nodes), step 102 can be skipped. If it is not (i.e., the number of consensus nodes capable of participating in the consensus is less than the minimum number of consensus nodes), then step 102 can be executed. In other words, the management subsystem can select a target read-only node from the read-only nodes provided that the number of consensus nodes capable of participating in the consensus is not less than the minimum number of consensus nodes.

[0065] Still with Figure 1 and Figure 2 For example, according to the PBFT algorithm, the minimum number of consensus nodes in the blockchain network is 3. If... Figure 1 and Figure 2 The blockchain network shown contains 5 consensus nodes. If any consensus node cannot participate in the consensus, the remaining 4 consensus nodes can still complete the consensus (the number of consensus nodes that can participate in the consensus at the current moment is greater than the minimum number of consensus nodes). At this time, the management subsystem can temporarily not select the target read-only node.

[0066] Furthermore, even if domain3 fails, the remaining domains 0-2 can still achieve consensus, meaning the number of remaining consensus nodes meets the consensus requirement (the number of consensus nodes capable of participating in consensus at the current moment equals the minimum number of consensus nodes). In this case, if the management subsystem initiates the first update transaction, it can execute successfully (without considering other factors) regardless of whether consensus is required before execution. Therefore, the management subsystem can select a target read-only node from the consensus nodes for subsequent updates. Afterward, if domain3 recovers its consensus capability (e.g., after a failure), it can be rejoined to participate in the consensus network. Thus, the management subsystem can select a target read-only node from the read-only nodes when the number of consensus nodes capable of participating in consensus at the current moment is equal to the minimum number of consensus nodes in the blockchain network. This method 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.

[0067] Furthermore, if only domains 0 to 2 remain in the consensus network (e.g., before the consensus capability of domain 3 is restored), and another consensus node is unable to participate in the consensus (e.g., domain 2 also fails), then since the two remaining consensus nodes at the current moment are insufficient to complete the consensus, the management subsystem can determine the target read-only node. However, the first update transaction initiated by the management subsystem in step 104 can only be a blockchain transaction that can be executed without consensus, and cannot be a blockchain transaction that can only be executed after consensus is reached (because such transactions cannot currently complete consensus, so even if initiated, they cannot be successfully executed).

[0068] 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.

[0069] In one embodiment, the system contract described in this invention can be recorded in the creation block of the blockchain network. As the initiator of the first update transaction, the management subsystem should have the authority to invoke the system contract so that it can successfully invoke the system contract during the execution of the first update transaction. For example, the management subsystem can initiate the first update transaction as an administrator of the blockchain network, such as by adding a signature generated based on the administrator's private key to the first update transaction.

[0070] Step 106: When any node in the blockchain network executes the first update transaction, it modifies the type information of the target read-only node by calling the system contract, so as to update the target read-only node into a consensus node.

[0071] In one embodiment, when executing the first update transaction, the management subsystem may invoke the system contract to determine the type information of the target read-only node from the contract state of the system contract it maintains. For example, the first update transaction may include the node identifier of the target read-only node (such as the node's public key). For instance, in the case of the aforementioned domain3 failure and domain4 being selected as the target read-only node, the transaction parameters of the first update transaction may include:

[0072] <domain4's id,“change_domain_state”,{"url":"x4.com","is_consensus_domain":true}>

[0073] The "domain4's id" and "change_domain_state" fields are used to instruct any blockchain node to modify the type identifier of domain4. Based on the node identifier "domain4'sid" of the target read-only node, the blockchain node executing the transaction can find the type information of the target read-only node in the type information of each node maintained locally. This type information may include a read-only identifier—used to indicate that the target read-only node is a read-only node. Further, the management subsystem can modify the read-only identifier to a consensus identifier—used to indicate that the target read-only node is a consensus node.

[0074] Still with Figure 3 For example, if domain4 is selected as the target read-only node through the aforementioned steps, the first update transaction can include "domain4's id". Based on this, any node executing the first update transaction can search for "domain4's id" in the keys of various domain information maintained locally (recorded in the contract state of the system contract), thereby finding the type information of domain4, namely ""is_consensus_domain":false". Further, any node can modify "false (i.e., read-only identifier)" in this type information to "true (i.e., consensus identifier)", and the modified domain information of domain4 is:

[0075] 5.key<domain4's id> ,value{"url":"x4.com","is_consensus_domain":true}

[0076] Alternatively, the aforementioned read-only flag and consensus flag can also take other forms, such as "onlyread" and "consensus" respectively. For example, let's assume the domain information of domain4 before modification is as follows:

[0077] 5.key<domain4's id> ,value{"url":"x4.com","onlyread"}

[0078] Therefore, the transaction parameters for the first update transaction may include:

[0079] <domain4's id,“change_domain_state”,{"url":"x4.com","consensus"}>

[0080] After finding the domain information by "domain4's id", any node can change "onlyread" to "consensus" in this information, so that the domain information of domain4 after the modification is as follows:

[0081] 5.key<domain4's id> ,value{"url":"x4.com","consensus"}

[0082] After a sufficient number of nodes in the blockchain network have completed the first update transaction, the target read-only node can connect with other read-only nodes as a consensus node and join the consensus network, thereby replacing any of the consensus nodes. The threshold value corresponding to "sufficient number" can be determined according to the specific consensus algorithm; for example, in the PBFT algorithm, the threshold value can be 2f+1. Figure 4 As shown, after the update, domain4 joins the consensus network as a new consensus node. This concludes the introduction to the initiation and execution process of the first update transaction.

[0083] It is understandable that, since the system contract of the blockchain network records the type information of the consensus node and the read-only node in the contract state, and the contract state is maintained by each node in the blockchain network, the type information of the target read-only node is also maintained by each node in the contract state of the system contract. For the first update transaction initiated by the management subsystem, any node in the blockchain network can modify the type information of the target read-only node it maintains during the execution of the transaction. This transaction can be executed by each node in the blockchain network, so each node can modify the type information of the target read-only node it maintains. Therefore, after a sufficient number of nodes in the blockchain network have completed the execution of the first update transaction, the target read-only node can be updated to a consensus node at the blockchain network level, realizing the replacement of any consensus node by the target read-only node. Compared to the process of deleting a node and then adding a new node, this scheme only requires executing a transaction that calls the system contract to achieve the replacement of the old and new nodes. The replacement process is simple and efficient, and can quickly restore the fault tolerance of the consensus network, thereby improving the stability of the blockchain network.

[0084] In one embodiment, after the target read-only node is updated to a consensus node, 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 did not synchronize data from consensus nodes before the update, 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 a read-only node synchronizing data from consensus nodes. Without a synchronization delay, the target read-only node can participate in consensus immediately after being updated to a consensus node; 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 in the consensus network. That is, there is a portion of incremental data stored by other consensus nodes but not stored by the target read-only node, 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 that is updated to a consensus node and the other existing consensus nodes in the consensus network 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.

[0085] In one embodiment, when any node executes the first update transaction, it modifies the type information of the consensus node by invoking the system contract to update the consensus node to a read-only node. For example, the first update transaction may also include the node identifier of the consensus node (such as the node's public key). For instance, in the case of domain3 failure and domain4 being selected as the target read-only node, the transaction parameters of the first update transaction could be:

[0086] <domain3's id,“change_domain_state”,{"url":"x3.com","is_consensus_domain":false}>

[0087] or<domain3's id,“change_domain_state”,{"url":"x3.com","onlyread"}>

[0088] Based on the node identifier of any of the aforementioned consensus nodes, the blockchain node executing the transaction can find the type information of that node in the type information of each node maintained locally, and further modify the consensus identifier in the type information to a read-only identifier. Similar to the aforementioned process of modifying the type information of the target read-only node, each blockchain node executing the first update transaction can modify the consensus identifier in the type information of any of the aforementioned blockchain nodes to a read-only identifier when executing the transaction. After a sufficient number of blockchain nodes in the blockchain network have executed the first update transaction, the aforementioned blockchain node is updated to a read-only node in the blockchain network.

[0089] In another embodiment, if any consensus node is unable to participate in consensus due to its own failure, it can still participate in the blockchain network after the failure has been resolved. Since the consensus network can now reach consensus normally, the recovered consensus node can be updated to a read-only node. For example, the management subsystem can initiate a second update transaction for any consensus node to the blockchain network after determining that the failure of any consensus node has been resolved. Correspondingly, when executing the second update transaction, any node in the blockchain network can modify the type information of any consensus node by calling the system contract to update the consensus node to a read-only node. The second update transaction may include the node identifier of any consensus node to indicate the identity of the consensus node to the blockchain node executing the transaction. The specific execution process of the second update transaction is similar to that described above and will not be repeated here. After a sufficient number of blockchain nodes in the blockchain network have executed the second update transaction, the any blockchain node is updated to a read-only node in the blockchain network.

[0090] like Figure 5 As shown, after the above update is completed for the domain3 that has recovered from the fault, the node can synchronize blockchain data from the consensus nodes in the consensus network as a read-only node—although it is called a "consensus node", the node is essentially a read-only node at this time.

[0091] 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 will combine... 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.

[0092] Figure 6 This 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 containing consensus nodes participating in consensus and read-only nodes not participating in consensus. The contract state of the system contract in the blockchain network records the type information of the consensus nodes and the read-only nodes, whereby the type information of any node is used to characterize whether the node is a consensus node or a read-only node. Figure 6 As shown, the method includes steps 602-604.

[0093] Step 602: If it is determined that any consensus node cannot participate in the consensus, select a target read-only node from the read-only nodes.

[0094] Step 604: Initiate a first update transaction for the target read-only node to the blockchain network. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to modify the type information of the target read-only node, so as to update the target read-only node into a consensus node.

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

[0096] If it is determined that the failure of any consensus node has been recovered, a second update transaction is initiated to the blockchain network for any consensus node. When the second update transaction is executed by any node in the blockchain network, it is used to trigger any node to modify the type information of any consensus node by calling the system contract, so as to update any consensus node to a read-only node.

[0097] 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.

[0098] Figure 7 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 7 At 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 software and hardware, 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.

[0099] 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, which can be applied to, for example... Figure 7The device shown is used to implement the technical solution of this specification. The device is applied to a blockchain system, which includes a blockchain network and a management subsystem. The blockchain network includes consensus nodes that participate in consensus and read-only nodes that do not participate in consensus. The contract state of the system contract of the blockchain network records the type information of the consensus nodes and the read-only nodes. The type information of any node is used to characterize whether the node is a consensus node or a read-only node. The device includes:

[0100] The node selection unit 801 is used to enable the management subsystem to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus.

[0101] The first initiating unit 802 is used to enable the management subsystem to initiate a first update transaction for the target read-only node to the blockchain network.

[0102] The first update unit 803 is used to enable any node in the blockchain network to modify the type information of the target read-only node by calling the system contract when executing the first update transaction, so as to update the target read-only node into a consensus node.

[0103] Optional, also includes:

[0104] The second update unit 804 is used to enable any node to modify the type information of any consensus node by calling the system contract when executing the first update transaction, so as to update any consensus node to a read-only node.

[0105] Optionally, the first update unit 803 is specifically used for:

[0106] The system contract is invoked by any of the nodes to determine the type information of the target read-only node from the contract state of the system contract maintained by the node itself.

[0107] The node modifies the read-only identifier in the determined type information to a consensus identifier, wherein the read-only identifier is used to indicate that the target read-only node is a read-only node, and the consensus identifier is used to indicate that the target read-only node is a consensus node.

[0108] Optional, also includes:

[0109] The data synchronization unit 805 is used to enable the target read-only node to synchronize incremental data from other consensus nodes after being updated to a consensus node. The incremental data is data that is saved by other consensus nodes but not saved by the target read-only node.

[0110] Optionally, the node selection unit 801 is specifically used for:

[0111] 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,

[0112] 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.

[0113] Optional,

[0114] The node selection unit 801 is specifically used for: when the number of consensus nodes that the management subsystem can participate in consensus at the current moment is the minimum number of consensus nodes in the blockchain network, selecting a target read-only node from the read-only nodes; or,

[0115] The first update transaction initiated by the management subsystem is a transaction that does not require consensus.

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

[0117] The second initiating unit 806 is used to enable the management subsystem to initiate a second update transaction for any consensus node to the blockchain network when it is determined that the failure of any consensus node has been recovered.

[0118] The third execution unit 807 is used to enable any node in the blockchain network to modify the type information of any consensus node by calling the system contract when executing the second update transaction, so as to change the type information of any node.

[0119] 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 is used to implement the technical solution of this specification. The device is applied to a management subsystem in a blockchain system. The blockchain system further includes a blockchain network, which contains consensus nodes participating in consensus and read-only nodes not participating in consensus. The contract state of the system contract of the blockchain network records the type information of the consensus nodes and the read-only nodes. The type information of any node is used to characterize whether the node is a consensus node or a read-only node. The device includes:

[0120] The node selection unit 901 is used to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus.

[0121] The first initiating unit 902 is used to initiate a first update transaction for the target read-only node to the blockchain network. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to modify the type information of the target read-only node, so as to update the target read-only node to a consensus node.

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

[0123] The second initiating unit 903 is used to initiate a second update transaction for any consensus node to the blockchain network when it is determined that the failure of any consensus node has been recovered. When the second update transaction is executed by any node in the blockchain network, it is used to trigger any node to modify the type information of any consensus node by calling the system contract, so as to update the any consensus node to a read-only node.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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 the same or more software and / or hardware, 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.

[0129] 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.

[0130] 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.

[0131] 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.

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

[0133] 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.

[0134] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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 including a blockchain network and a management subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording the type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the method comprising: When the management subsystem determines that any consensus node cannot participate in the consensus and the number of consensus nodes that can participate in the consensus at the current moment is equal to the minimum number of consensus nodes in the blockchain network, it selects a target read-only node from the read-only nodes. The management subsystem initiates a first update transaction to the blockchain network for the target read-only node. The first update transaction is a transaction that does not require consensus. When any node in the blockchain network executes the first update transaction, it determines the type information of the target read-only node by calling the system contract in the contract state of the system contract it maintains, and modifies the read-only identifier in the determined type information to the consensus identifier, so as to update the target read-only node to a consensus node.

2. The method according to claim 1, further comprising: When executing the first update transaction, any node modifies the type information of any consensus node by calling the system contract, thereby updating any consensus node to a read-only node.

3. The method according to claim 1, further comprising: After being updated to a consensus node, the target read-only node 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 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.

5. 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: If the management subsystem determines that the failure of any consensus node has been recovered, it initiates a second update transaction for that consensus node to the blockchain network. When any node in the blockchain network executes the second update transaction, it modifies the type information of any consensus node by calling the system contract, thereby updating the consensus node to a read-only node.

6. A node update method, applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the method comprising: If it is determined that no consensus node can participate in the consensus and the number of consensus nodes that can participate in the consensus at the current moment is equal to the minimum number of consensus nodes in the blockchain network, a target read-only node is selected from the read-only nodes. A first update transaction is initiated to the blockchain network for the target read-only node. The first update transaction is a transaction that does not require consensus. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to determine the type information of the target read-only node in the contract state of the system contract maintained by itself, and modify the read-only identifier in the determined type information to the consensus identifier, so as to update the target read-only node to a consensus node.

7. The method according to claim 6, 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, a second update transaction is initiated to the blockchain network for any consensus node. When the second update transaction is executed by any node in the blockchain network, it is used to trigger any node to modify the type information of any consensus node by calling the system contract, so as to update any consensus node to a read-only node.

8. A node update device applied to a blockchain system, the blockchain system including a blockchain network and a management subsystem, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the device comprising: The node selection unit is used to enable the management subsystem to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus and the number of consensus nodes that can participate in the consensus at the current moment is equal to the minimum number of consensus nodes in the blockchain network. The first initiating unit is used to enable the management subsystem to initiate a first update transaction for the target read-only node to the blockchain network, wherein the first update transaction is a transaction that does not require consensus. The first update unit is used to enable any node in the blockchain network to determine the type information of the target read-only node by calling the system contract in the contract state of the system contract maintained by itself when executing the first update transaction, and to modify the read-only identifier in the determined type information to the consensus identifier, so as to update the target read-only node to a consensus node.

9. A node update device, applied to a management subsystem of a blockchain system, the blockchain system further comprising a blockchain network, the blockchain network including consensus nodes participating in consensus and read-only nodes not participating in consensus, the contract state of the system contract of the blockchain network recording type information of the consensus nodes and the read-only nodes, the type information of any node being used to characterize whether the node is a consensus node or a read-only node, the device comprising: The node selection unit is used to select a target read-only node from the read-only nodes when it is determined that any consensus node cannot participate in the consensus and the number of consensus nodes that can participate in the consensus at the current moment is equal to the minimum number of consensus nodes in the blockchain network. The first initiating unit is used to initiate a first update transaction for the target read-only node to the blockchain network. The first update transaction is a transaction that does not require consensus. When the first update transaction is executed by any node in the blockchain network, it is used to trigger the node to call the system contract to determine the type information of the target read-only node in the contract state of the system contract maintained by itself, and modify the read-only identifier in the determined type information to a consensus identifier, so as to update the target read-only node to a consensus node.

10. 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-7 by executing the executable instructions.

11. 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-7.

Images