Consensus algorithm switching method and device, computer device and medium

Abstract

Embodiments of the present application are suitable for the field of blockchain technology, and provide a consensus algorithm switching method and device, a computer device and a medium. The method is applied to a node of a blockchain, and includes: if a to-be-consensed block obtained from a transaction pool is a configuration block, generating checkpoint information, the checkpoint information being used to record a current consensus state of the node; if a preset number of other nodes in the blockchain are consistent with the current consensus state of the node, storing the consensus state into on-chain data of the blockchain; obtaining a configuration transaction from the configuration block, the configuration transaction including a target consensus algorithm to be switched; switching a consensus algorithm currently used by the node to the target consensus algorithm; and initializing the node according to the target consensus algorithm and the consensus state, so as to complete switching of the consensus algorithm on the node. Through the above method, switching of the consensus algorithm of the blockchain can be performed in an online environment, and stability of the blockchain is ensured.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a method, device, computer equipment, and medium for switching consensus algorithms. Background Technology

[0002] Blockchain systems can maintain the consistency of the cluster state through consensus algorithms. Different consensus algorithms have their own characteristics, thus having their own optimal application scenarios. For example, in the simplest non-Byzantine scenario, we can consider using the non-Byzantine fault-tolerant consensus algorithm Raft; when considering the Byzantine scenario and the number of nodes is small, we can consider using the Practical Byzantine Fault-Tolerant consensus algorithm PBFT; when considering the Byzantine scenario and the number of nodes is large and network bandwidth resources are limited, we can consider using the improved PBFT algorithm, Hotstuff pipeline algorithm.

[0003] To enable blockchain systems to use different consensus algorithms for different scenarios, consensus algorithm switching can be performed within the blockchain system. Currently, there are generally two methods for switching consensus algorithms in blockchain.

[0004] The first method is an offline switch. This involves manually stopping the original algorithm and adding a configuration file for the new algorithm. The new consensus algorithm initializes by reading the manually modified configuration file, thus achieving the goal of switching algorithms. However, using this method for consensus algorithm switching can lead to the loss of some transactions when the original algorithm stops, thereby reducing the reliability of the blockchain system.

[0005] Another approach is to switch consensus algorithms in an online environment by running two algorithms in parallel. However, running two algorithms in parallel inevitably increases bandwidth usage and places higher demands on the network. Summary of the Invention

[0006] In view of this, embodiments of this application provide a method, apparatus, computer device, and medium for switching consensus algorithms in an online environment, thereby ensuring the reliability of the blockchain during the consensus algorithm switching process.

[0007] The first aspect of this application provides a method for switching consensus algorithms, applied to nodes in a blockchain, the method comprising:

[0008] If the block to be consensus obtained from the transaction pool is a configuration block, checkpoint information is generated, which is used to record the current consensus state of the node.

[0009] If a predetermined number of other nodes in the blockchain have the same consensus state as the current node, then the consensus state is stored in the on-chain data of the blockchain.

[0010] Obtain a configuration transaction from the configuration block, the configuration transaction including the target consensus algorithm to be switched;

[0011] Switch the consensus algorithm currently used by the node to the target consensus algorithm;

[0012] The node is initialized according to the target consensus algorithm and the consensus state to complete the switching of the consensus algorithm on the node.

[0013] A second aspect of this application provides a consensus algorithm switching device applied to a blockchain node, the device comprising:

[0014] The generation module is used to generate checkpoint information if the block to be reached for consensus obtained from the transaction pool is a configuration block. The checkpoint information is used to record the current consensus state of the node.

[0015] The on-chain module is used to store the consensus state in the on-chain data of the blockchain if a preset number of other nodes in the blockchain have the same consensus state as the current node.

[0016] An acquisition module is used to acquire a configuration transaction from the configuration block, wherein the configuration transaction includes the target consensus algorithm to be switched.

[0017] A switching module is used to switch the consensus algorithm currently used by the node to the target consensus algorithm.

[0018] An initialization module is used to initialize the node according to the target consensus algorithm and the consensus state, so as to complete the switching of the consensus algorithm on the node.

[0019] A third aspect of this application provides a consensus algorithm switching module applied in a blockchain node, comprising a consensus layer, an algorithm layer, and a transaction pool; wherein,

[0020] The consensus layer is used to encapsulate specific consensus algorithms;

[0021] The algorithm layer is used to perform cluster consensus operations on blocks according to the current consensus algorithm in the blockchain, based on the corresponding algorithm logic.

[0022] The transaction pool is used to store the transactions received by the node.

[0023] A fourth aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0024] A fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0025] A sixth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the method described in the first aspect.

[0026] Compared with the prior art, the embodiments of this application have the following advantages:

[0027] In this embodiment, when nodes in the blockchain reach a consensus on a configuration block, it can be determined that a consensus algorithm switch is needed. Therefore, checkpoint information can be generated to record the current consensus state of the node. When a node determines that a preset number of other nodes in the blockchain have the same consensus state as its own, it can be determined that the current consensus state has been reached in the blockchain. At this time, the current consensus state can be uploaded to the blockchain. After the consensus state is uploaded, the node can stop the current consensus algorithm and switch to the target consensus algorithm included in the configuration block. Then, it retrieves the consensus state previously stored by the node from the on-chain data, initializes the node using the target consensus algorithm and the consensus state, thereby completing the consensus algorithm switch for the node. This embodiment can achieve online consensus algorithm switching based on the configuration block and the configuration transactions in the configuration block. This embodiment performs consensus algorithm switching in an online environment, which can avoid transaction loss during the algorithm switching process, thereby ensuring the reliability of the blockchain. At the same time, in this embodiment, two consensus algorithms will not run simultaneously in the node, thus reducing the network bandwidth consumption during the consensus algorithm switching process. Attached Figure Description

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

[0029] Figure 1 This is a flowchart illustrating the steps of a consensus algorithm switching method provided in an embodiment of this application;

[0030] Figure 2 This is a flowchart illustrating an exception handling process during consensus algorithm switching, as provided in an embodiment of this application.

[0031] Figure 3 This is a flowchart illustrating the steps of another consensus algorithm switching method provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of a consensus algorithm switching module provided in an embodiment of this application;

[0033] Figure 5 This is a flowchart illustrating another consensus algorithm switching method provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the node state after a consensus algorithm switch provided in an embodiment of this application;

[0035] Figure 7 This is a schematic diagram of a consensus algorithm switching device provided in an embodiment of this application;

[0036] Figure 8 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0037] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0038] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0039] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0040] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0041] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0042] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0043] Currently, when switching consensus algorithms, if the offline switching method is used, it is necessary to manually stop the original algorithm and manually add a configuration file to start the new algorithm. On the one hand, manually adding a configuration file will reduce the flexibility and verifiability of the blockchain system; on the other hand, there is a period without a consensus algorithm during the consensus algorithm switching period, which can easily lead to transaction loss.

[0044] Therefore, online switching can be achieved by running the two algorithms in parallel. This method can integrate all consensus algorithms using a single switcher. During consensus algorithm reconfiguration, nodes in the blockchain can run both algorithms in parallel, forwarding all consensus messages received by the node to both protocols simultaneously. Once the original algorithm stops, messages that were not reached through the original algorithm will be resolved by the new algorithm. However, this method leads to a significant increase in bandwidth usage during reconfiguration because all messages are resolved using both protocols. Therefore, this optimization is only applicable to systems without network bottlenecks.

[0045] Based on this, this application proposes an online consensus algorithm switching scheme based on configuration transactions, which can achieve online switching of consensus algorithms without consuming a large amount of network bandwidth. The technical solution of this application is illustrated below through specific embodiments.

[0046] Reference Figure 1 This illustration shows a flowchart of a consensus algorithm switching method provided in an embodiment of this application, which may specifically include the following steps:

[0047] S101, if the block to be reached for consensus obtained from the transaction pool is a configuration block, then checkpoint information is generated, and the checkpoint information is used to record the current consensus state of the node.

[0048] In this embodiment, the execution entity is a node in the blockchain. A blockchain node can be a computer device deploying a blockchain network, such as a computer or server. A blockchain can include multiple nodes, among which there may be a master node. When switching the consensus algorithm of the blockchain, the blockchain administrator can send a configuration transaction to the master node. This configuration transaction can include information about the consensus algorithm to be switched. After receiving the transaction sent by the blockchain administrator, the master node can identify the transaction type. If the master node identifies the transaction as a configuration transaction, it can package the transaction into a configuration block and then broadcast the configuration block to all nodes in the blockchain, including the master node. Each node can then switch the consensus algorithm based on the received configuration block. In this embodiment, the execution entity can be any node in the blockchain; this node may or may not be a master node.

[0049] In one possible implementation, if a node is the master node, it can receive configuration transactions sent by the blockchain administrator, package these transactions into a configuration block, and then store the configuration block in the transaction pool. The master node can also broadcast the configuration block to other nodes in the blockchain. If a node is not the master node, it can receive configuration blocks broadcast from the master node and then store the configuration block in the transaction pool.

[0050] After receiving a configuration block, each node can store it in its own transaction pool. A node's transaction pool can store multiple blocks that require consensus. Nodes can retrieve these blocks from the pool in a specific order and then reach a consensus on them. For example, nodes can retrieve blocks from the pool in the order they were received.

[0051] After a node obtains a block to be reached for consensus from the transaction pool, it needs to parse the block to retrieve the transaction information that requires consensus. A typical block to be reached for consensus contains batch transaction information, meaning it includes multiple transactions awaiting consensus; a configuration block, however, contains only one configuration transaction. If a node identifies that a block to be reached for consensus contains only one transaction, and that transaction is a configuration transaction, then it can determine that the block to be reached for consensus is a configuration block.

[0052] In one possible implementation, the configuration block can carry identification information. After a node obtains a block to be reached for consensus, if it recognizes that the block to be reached for consensus carries the identification information of the configuration block, it can determine that the block to be reached for consensus is a configuration block.

[0053] If a node recognizes a configuration block, it indicates that the node has entered a state of switching consensus algorithms. To ensure the cluster consistency of the blockchain system before and after the consensus algorithm switch, the node can generate checkpoint information to record the node's current consensus state. This checkpoint information is then broadcast to every node in the blockchain.

[0054] Each node in the blockchain can broadcast checkpoint information to other nodes and receive other checkpoint information from other nodes. S102, if a preset number of other nodes in the blockchain have the same consensus state as the current node, then the consensus state is stored in the on-chain data of the blockchain.

[0055] Since checkpoint information can record the current consensus state of a node, it can be used to determine whether the consensus state of different nodes on the blockchain is consistent.

[0056] This node can receive checkpoint information from multiple other nodes, and then count the number of other checkpoints whose consensus state matches this node's checkpoint information. If this number is greater than a preset value, it indicates that there are a preset number of other nodes whose consensus state is consistent with this node's current state. That is, the cluster consistency check of the blockchain system can be considered to have passed.

[0057] Afterwards, stable checkpoint information can be generated based on the checkpoint information. The stable checkpoint information can record the consensus state that is consistent with other nodes. Then, the node can upload the stable checkpoint information to the blockchain, so that the consensus state of the node before switching consensus algorithms can be stored in the on-chain data.

[0058] S103, Obtain a configuration transaction from the configuration block, the configuration transaction including the target consensus algorithm to be switched.

[0059] The configuration block may include configuration transactions, which may carry configuration information, and the configuration information may include the target consensus algorithm to be switched.

[0060] In one possible implementation, the consensus algorithm in each node has version information; for example, the target consensus algorithm's version is higher than the version of the consensus algorithm currently used by the node. Upon receiving a configuration transaction, the master node can determine its own current consensus algorithm version, then set the version of the consensus algorithm in the configuration transaction to a higher version than the currently used consensus algorithm, and generate a corresponding version number. Each node, upon receiving the configuration transaction, can determine whether its current consensus algorithm version is behind the version corresponding to the configuration transaction based on the version number. If the node's current consensus algorithm version is behind the version corresponding to the configuration transaction, it can determine that a consensus algorithm switch is needed based on the configuration transaction; otherwise, no switch is required.

[0061] S104, switch the consensus algorithm currently used by the node to the target consensus algorithm.

[0062] A node can stop the original algorithm and then switch its consensus engine, changing the node's consensus algorithm to the target consensus algorithm. A consensus engine can include multiple consensus algorithms, each based on different consensus logics. Switching the consensus engine changes the node's consensus logic to the target consensus algorithm's logic, allowing the node to reach consensus according to the new logic.

[0063] S105, the node is initialized according to the target consensus algorithm and the consensus state to complete the switching of the consensus algorithm on the node.

[0064] Since stability checkpoint information is stored on the blockchain, the consensus state of a node before switching consensus algorithms can be obtained from the chain. Based on this consensus state before switching, the node can initialize using the target consensus algorithm, bringing it back to the consensus state before the algorithm switch. This allows the node to complete the consensus algorithm switch on the node, and then use the target consensus algorithm to reach consensus on the blocks following the configuration block. Therefore, in this embodiment, a consensus block will only be reached through one consensus algorithm, and two consensus algorithms will not run simultaneously on a blockchain node.

[0065] After identifying a configuration block, a node can block the consensus process following the configuration block, thus preventing algorithm conflicts during consensus algorithm switching. After the consensus algorithm switch is complete, the node can continue the consensus process, retrieve the next consensus block from the transaction pool, and use the target consensus algorithm to reach consensus on that block. In one possible implementation, the node can include a flag to indicate whether it is switching consensus algorithms. For example, during the consensus process, if a configuration block is identified, the flag can be set to a first preset value; after the configuration block consensus is complete, the flag can be set to a second preset value. During the consensus process, if the node identifies the flag as the first preset value, it can determine that consensus on the configuration block and consensus algorithm switching are currently underway, and can stop the consensus process following the configuration block; if the flag is identified as the second preset value, it can determine that the consensus algorithm switch has been completed or is not currently underway, and can then retrieve the next consensus block from the transaction pool for consensus. Due to network latency and differences in efficiency between nodes, all nodes in the cluster may not be able to complete the consensus algorithm switch simultaneously. Therefore, a node may receive consensus messages that do not match the consensus algorithm in its own node, thus requiring exception handling.

[0066] Nodes can receive consensus messages from other nodes. Each consensus message has a corresponding source node and a first version, which indicates the version of the consensus algorithm used. If the first version does not match the node's second version, consensus algorithm switching exception handling can be performed. The second version is the consensus algorithm currently used by the node. If the first version matches the node's second version, the consensus message is reached using the consensus algorithm corresponding to the second version. For example, the first consensus algorithm used in the blockchain might be version 1, the second version version 2, and so on, with numerical values ​​used to identify the currently used consensus algorithm version. When a node wants to broadcast a consensus message to other nodes, it can encapsulate the version of the consensus algorithm it is using within the consensus message.

[0067] A mismatch between version 1 and version 2 can include two scenarios: version 1 is lower than version 2, and version 1 is higher than version 2. If version 1 is lower than version 2, it indicates that the source node's consensus algorithm has not been switched. In this case, the source node can return the configuration information of the consensus algorithm corresponding to version 2 to the source node, which can then switch its current consensus algorithm to the one corresponding to version 2 based on the received configuration information. If version 1 is higher than version 2, it indicates that the current node's consensus algorithm has not been switched. In this case, the node can return a consensus message to the source node and receive the configuration information of the consensus algorithm for version 1 returned by the source node in response to the consensus message. Based on the configuration information, the node can then switch its consensus algorithm to the one corresponding to version 1.

[0068] In one possible implementation, a consensus algorithm switching module can be deployed in the node. This switching module may include a consensus layer and an algorithm layer. The consensus layer encapsulates the specific consensus algorithm. A consensus state management component can be installed in the consensus layer to handle abnormal situations during consensus algorithm switching. Figure 2 This is a flowchart illustrating an exception handling process during consensus algorithm switching, as provided in an embodiment of this application. Figure 2 As shown, the message processor in a node can process received messages to determine the version of the consensus algorithm used by the message; then it checks whether the version of the consensus algorithm matches the current consensus algorithm in the node. If they match, consensus is continued using the algorithm layer; if they do not match, the message can be forwarded to the consensus state management program in the consensus state management component for exception handling. The consensus state management component can determine whether the version of the consensus algorithm used by the message is lower than the version of the consensus algorithm currently used by the node. If the version of the consensus algorithm used by the message is lower than the version of the consensus algorithm currently used by the node, it indicates that the remote node that sent the message has not completed the consensus algorithm switch. This node can send all consensus state verification information from the remote node's lagging state to the current node's state to the remote node; after receiving all consensus state verification information from the remote node's lagging state to the current node's state, the lagging remote node can switch the consensus algorithm after completing the relevant verification and synchronization work. If the consensus algorithm version used in the message is higher than the version currently used by this node, it indicates that this node has not completed the consensus algorithm switch. In this case, a consensus state synchronization request message can be sent to other nodes through the consensus state management program of the consensus layer, and then a consensus state synchronization proof message returned from other nodes can be received. This consensus state synchronization proof message can include all consensus state verification-related information from the lagging state of this node to the states of other nodes. After receiving the consensus configuration message, this node can switch the consensus algorithm engine after completing the relevant verification and synchronization work, thereby updating the node's consensus algorithm to a higher version.

[0069] In this embodiment, the consensus algorithm can be switched based on configuration transactions. Packaging the configuration transaction into a separate configuration block ensures that consensus on this configuration transaction is not affected by other transactions, preventing the consensus of other transactions from being missed during the consensus algorithm switch. This embodiment generates checkpoint information upon identifying a configuration block and confirms that the current node's consensus state is consistent with other nodes based on the received checkpoint information, thus ensuring cluster consistency and maintaining the reliability of the blockchain system. This embodiment also provides an anomaly handling method for consensus algorithm switching, allowing lagging nodes in the blockchain to switch consensus algorithms promptly, thereby ensuring the security and flexibility of the blockchain system during consensus algorithm switching.

[0070] Reference Figure 3 This illustration shows a flowchart of another consensus algorithm switching method provided in an embodiment of this application, which may specifically include the following steps:

[0071] S301, if a configuration transaction for switching the consensus algorithm in the blockchain is received, the configuration transaction is packaged into the configuration block.

[0072] In this embodiment, the execution entity is the blockchain master node, which can package the data awaiting consensus into blocks. When the master node receives a configuration transaction, it can package that transaction into a separate block, called a configuration block. This configuration block can have a corresponding identifier, which can be used to identify the block as a configuration block.

[0073] S302, Stop packaging new blocks awaiting consensus.

[0074] Once the master node recognizes the configuration transaction, it can stop packaging subsequent data awaiting consensus.

[0075] After each node in the blockchain identifies a configuration block, it needs to switch the consensus algorithm based on the configuration block. When switching the consensus algorithm, the consensus process after the configuration block needs to be blocked.

[0076] After the master node configures the block, it no longer packages the consensus block. Therefore, after receiving the configuration block, each node in the blockchain will not receive a new consensus block before the consensus algorithm is switched. This is equivalent to the node blocking the consensus process after the configuration block, so that there will be no algorithm conflict during the consensus algorithm switch.

[0077] S303, if the block to be reached for consensus obtained from the transaction pool is a configuration block, then checkpoint information is generated, and the checkpoint information is used to record the current consensus state of the node.

[0078] S304, if a preset number of other nodes in the blockchain have the same consensus state as the current node, then the consensus state is stored in the on-chain data of the blockchain.

[0079] S305, Obtain a configuration transaction from the configuration block, the configuration transaction including the target consensus algorithm to be switched.

[0080] S306, switch the consensus algorithm currently used by the node to the target consensus algorithm.

[0081] S307, Initialize the node according to the target consensus algorithm and the consensus state to complete the switching of the consensus algorithm on the node.

[0082] S303-S307 in this embodiment are similar to S101-S105 in the previous embodiment and can be referred to each other, so they will not be described in detail here.

[0083] S308, after the consensus algorithm in the blockchain is switched, a new block to be consensus is packaged and broadcast to each node in the blockchain. The node is used to reach consensus on the received block to be consensus using the switched consensus algorithm.

[0084] If consensus is reached on the configuration block in the blockchain, the blockchain has completed the switch to the consensus algorithm, and the consensus process can continue. The master node can continue to package the data to be agreed upon into blocks and broadcast these blocks to all nodes, allowing each node to continue the consensus process.

[0085] In one possible implementation, after identifying a configuration transaction, the master node can set a preset flag to a first preset value; after consensus on the configuration block is completed, it can set the flag to a second preset value. Before the master node packages the block to be consensused, it can first determine the value of the flag. If the flag value is the first preset value, it indicates that consensus on the configuration block is not yet complete, and it can continue to wait for the flag value to change to the second preset value. If the flag value is the second preset value, it indicates that consensus on the configuration block is complete, meaning the blockchain has completed the consensus algorithm switch. At this point, it can continue to package the block to be consensused and broadcast it to all nodes. After receiving the block, each node can continue to use the switched consensus algorithm to reach consensus on the block.

[0086] In this embodiment, the consensus process after the configuration block can be blocked by blocking the master node's packaging process, thereby ensuring that there will be no algorithm conflict due to the consensus of subsequent blocks during the consensus algorithm switching, thus guaranteeing the reliability of the blockchain system.

[0087] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0088] Figure 4 This is a schematic diagram of a consensus algorithm switching module provided in an embodiment of this application; as shown... Figure 4 As shown, the consensus algorithm switching module can include a consensus layer, an algorithm layer, and a transaction pool (txpool layer). The consensus layer can encapsulate and isolate the specific consensus algorithm. The algorithm layer can contain the specific consensus algorithm logic, decoupling transaction distribution from transaction consensus, ensuring that the cluster has completed the distribution and local storage of a transaction before consensus is reached. The transaction pool can be used by nodes to store all received transactions. The consensus layer can also include a consensus state management component, which can include a consensus state management program. The consensus state management component can handle abnormal situations during consensus algorithm switching through the consensus state management program.

[0089] Figure 4 The consensus algorithm switching module shown can be deployed on each node of the cluster to complete the switching of consensus algorithms. Figure 5 This is a flowchart illustrating another consensus algorithm switching method provided in an embodiment of this application. Figure 5 As shown, the specific process of algorithm switching can be as follows: An algorithm switching configuration transaction sTx enters the consensus algorithm switching module, is first received by the consensus layer and then passed to the algorithm layer. The type of the transaction is first detected at the algorithm layer. The master node will package the configuration transaction into a separate configuration block s-Batch for algorithm switching, and then broadcast the s-Batch to each node in the blockchain. After receiving the s-Batch, each node can store the s-Batch in the transaction pool.

[0090] Once consensus has been reached on all blocks prior to the s-Batch, the cluster can begin consensus on the s-Batch. At this point, nodes can recognize that this block is a special block representing a configuration change, and initiate a switching state. Once a node enters the switching state, it will block the consensus process following this s-Batch.

[0091] In this embodiment, to facilitate periodic cleanup of consensus blocks and periodic checks on cluster consistency, a checkpoint is generated every K blocks reached or every configuration block reached to record the current node's consensus state. Therefore, when a node identifies a special configuration block that changes the consensus algorithm, a checkpoint also needs to be generated. After the algorithm layer completes the configuration block commit, the node can broadcast its own checkpoint and collect quorum checkpoints with the same consensus state, thereby generating a stable checkpoint. Subsequently, the execution layer can upload the stable checkpoint to the blockchain so that the switched consensus algorithm can obtain the original algorithm's execution state for initialization and perform any subsequent verification operations.

[0092] Once a node completes its checkpoint on-chain setup, the consensus layer will immediately perform a switchover operation, stopping the original algorithm and switching to a new consensus algorithm engine. The new algorithm will then read on-chain information for initialization. The switchover is now complete.

[0093] The consensus mechanism for s-Batch ensures that the algorithm's configuration switching transactions are verified by the cluster's consistency; the consensus process for checkpoints ensures that the final state is verified by the cluster's consistency when the original algorithm stops.

[0094] After the algorithm switch is completed, the state of each node can be as follows: Figure 6 As shown. Figure 6 As shown, nodes can continuously obtain batches of transactions from the transaction pool for consensus. Once a configuration block (s-batch) is identified, the consensus algorithm can be switched based on the s-batch. The s-batch is the last block of the old consensus algorithm before the switch; after the switch, the new algorithm can continue to be used for consensus on subsequent batches of transactions after the s-batch.

[0095] In this embodiment, all received transactions can be cached in the transaction pool, and the received transactions are stored in the transaction pool, so that the received transactions and consensus transactions can be processed asynchronously, ensuring the reliability of the blockchain.

[0096] The above describes the ideal process for a single node to successfully switch consensus algorithms. However, due to network latency and efficiency differences between nodes, it is difficult to achieve simultaneous algorithm switching across all nodes in the cluster. Therefore, when an algorithm switching event occurs, two scenarios may occur: a node using the new algorithm receives messages from other nodes using the old algorithm; or a node using the old algorithm receives messages from other nodes using the new algorithm.

[0097] Therefore, exception handling is necessary. Exception handling can be handled by the consensus layer.

[0098] The consensus layer is responsible for further encapsulating consensus messages and distributing them to the corresponding algorithms. In this embodiment, only one algorithm is running on the current node at any given time. The consensus layer will forward the message to the algorithm layer only if the encapsulated consensus message type matches the current consensus algorithm type. In this embodiment, the epoch can be used to identify the current consensus configuration version.

[0099] When the algorithm type of the consensus message received by the consensus layer does not match that of the current node, the epochs of the two can be compared to determine the lagging node. The state management component of the node's consensus layer can handle the lag synchronization operations related to the switching of consensus algorithms. For example, if the local state is lagging, the consensus layer initiates a synchronization operation, and the entire synchronization process can be completed by the consensus state management component of the consensus layer until the synchronization is complete, at which point the switching operation is performed to complete the algorithm switch. If the peer node is lagging, the consensus state management component can send a help synchronization message to the peer node so that the cluster can quickly reach a consistent state. The switching method in this embodiment ensures the reliability of the blockchain. This embodiment does not lose transactions during the consensus algorithm switching process, thus ensuring the reliability of the blockchain system, and does not require manual configuration of the new algorithm, ensuring the flexibility of the blockchain system.

[0100] The switching method in this embodiment has no additional message overhead, does not require running two algorithms simultaneously, does not require a new protocol, and does not affect the overall consensus process.

[0101] The switching method in this embodiment ensures cluster state consistency. Since the nodes have already reached consensus on the configuration transactions and the checkpoint containing the cluster consistency state before the consensus algorithm switch, it can be guaranteed that the cluster state is consistent after the switch.

[0102] Reference Figure 7 The diagram illustrates a consensus algorithm switching device provided in an embodiment of this application. This device can be applied to blockchain nodes and specifically includes a generation module 71, an on-chain module 72, an acquisition module 73, a switching module 74, and an initialization module 75, wherein:

[0103] The generation module 71 is used to generate checkpoint information if the block to be reached for consensus obtained from the transaction pool is a configuration block. The checkpoint information is used to record the current consensus state of the node.

[0104] The on-chain module 72 is used to store the consensus state in the on-chain data of the blockchain if there are a preset number of other nodes in the blockchain that are consistent with the current consensus state of the node.

[0105] The acquisition module 73 is used to acquire a configuration transaction from the configuration block, wherein the configuration transaction includes the target consensus algorithm to be switched.

[0106] The switching module 74 is used to switch the consensus algorithm currently used by the node to the target consensus algorithm.

[0107] The initialization module 75 is used to initialize the node according to the target consensus algorithm and the consensus state, so as to complete the switching of the consensus algorithm on the node.

[0108] In one possible implementation, if the node is the master node, the device further includes:

[0109] The packaging module is used to package the configuration transaction into the configuration block if a configuration transaction for switching the consensus algorithm in the blockchain is received.

[0110] The broadcast module is used to broadcast the configuration block to each node in the blockchain. Each node is used to switch the consensus algorithm according to the configuration block. Each node includes the master node.

[0111] In one possible implementation, the master node is used to package the block to be reached for consensus, and the apparatus further includes:

[0112] The blocking and packaging module is used to stop packaging new blocks awaiting consensus.

[0113] The continuous packaging module is used to continue packaging new blocks to be consensused after the consensus algorithm in the blockchain has been switched, and to broadcast the blocks to be consensused to each node in the blockchain. The nodes are used to reach consensus on the received blocks to be consensused using the switched consensus algorithm.

[0114] In one possible implementation, the on-chain module 72 includes:

[0115] The broadcast submodule is used to broadcast the checkpoint information to other nodes in the blockchain;

[0116] The receiving submodule is used to receive other checkpoint information broadcast by other nodes in the blockchain;

[0117] A determining submodule is used to determine a first number of other checkpoint information received that are consistent with the checkpoint information status;

[0118] The judgment submodule is used to determine that if the first quantity is greater than or equal to a preset value, there are a preset number of other nodes in the blockchain that are consistent with the current consensus state of the node.

[0119] A generation submodule is used to generate stable checkpoint information based on the checkpoint information;

[0120] The on-chain submodule is used to upload the stability checkpoint information to the blockchain.

[0121] In one possible implementation, the device further includes:

[0122] A consensus message receiving module is used to receive consensus messages, wherein the consensus message has a corresponding source node and a first version, and the first version is the version of the consensus algorithm used by the consensus message;

[0123] An exception handling module is used to handle consensus algorithm switching exceptions if the first version does not match the second version corresponding to the node; the second version is the version of the consensus algorithm currently used by the node.

[0124] The consensus module is used to reach a consensus on the consensus message by using the consensus algorithm corresponding to the second version if the first version matches the second version corresponding to the node.

[0125] In one possible implementation, the above-mentioned exception handling module includes:

[0126] The first synchronization module is used to return the configuration information of the consensus algorithm corresponding to the second version to the source node if the first version is lower than the second version. The source node is used to switch the currently used consensus algorithm to the consensus algorithm corresponding to the second version according to the configuration information.

[0127] The second synchronization module is configured to return a consensus message to the source node if the first version is higher than the second version, and receive configuration information of the consensus algorithm of the first version returned by the source node for the consensus message; and switch the consensus algorithm of the node to the consensus algorithm corresponding to the first version according to the configuration information.

[0128] In one possible implementation, the above-mentioned device further includes:

[0129] The continuing acquisition module is used to continue acquiring consensus blocks after the configuration block from the transaction pool;

[0130] The consensus module is used to reach consensus on the block to be reached using the target consensus algorithm.

[0131] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0132] Figure 8This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 8 As shown, the computer device 8 of this embodiment includes: at least one processor 80 ( Figure 8 (Only one is shown) a processor, a memory 81, and a computer program 82 stored in the memory 81 and executable on the at least one processor 80, which, when executing the computer program 82, implements the steps in any of the above method embodiments.

[0133] The computer device 8 may be a desktop computer, laptop, handheld computer, or cloud server, etc. This computer device may include, but is not limited to, a processor 80 and a memory 81. Those skilled in the art will understand that... Figure 8 The computer device 8 is merely an example and does not constitute a limitation on the computer device 8. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0134] The processor 80 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0135] In some embodiments, the memory 81 may be an internal storage unit of the computer device 8, such as a hard disk or memory of the computer device 8. In other embodiments, the memory 81 may be an external storage device of the computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Furthermore, the memory 81 may include both internal and external storage units of the computer device 8. The memory 81 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 81 can also be used to temporarily store data that has been output or will be output.

[0136] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0137] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0138] When the consensus algorithm switching method is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above-described embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0139] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0140] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0141] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and 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 displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0142] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for switching consensus algorithms, characterized in that, A node applied to a blockchain, wherein the blockchain comprises multiple nodes, the nodes being master nodes or non-master nodes, the method comprising: If the block to be consensus obtained from the transaction pool is a configuration block, checkpoint information is generated. The checkpoint information is used to record the current consensus state of the node. The configuration block is obtained by the master node of the blockchain by packaging the configuration transaction separately. The configuration transaction is sent to the master node by the blockchain administrator. The master node is used to broadcast the configuration block to each of the non-master nodes. If a predetermined number of other nodes in the blockchain have the same consensus state as the current node, then the consensus state is stored in the on-chain data of the blockchain. Obtain a configuration transaction from the configuration block, the configuration transaction including the target consensus algorithm to be switched; Switch the consensus algorithm currently used by the node to the target consensus algorithm; The node is initialized according to the target consensus algorithm and the consensus state to complete the switching of the consensus algorithm on the node.

2. The switching method as described in claim 1, characterized in that, If the node is the master node, the method further includes: If a configuration transaction for switching the consensus algorithm in the blockchain is received, the configuration transaction is packaged into the configuration block; The configuration block is broadcast to each node in the blockchain, and each node is used to switch the consensus algorithm according to the configuration block.

3. The switching method as described in claim 2, characterized in that, The master node is used to package the block to be agreed upon. If it receives a configuration transaction for switching the consensus algorithm in the blockchain, after packaging the configuration transaction into the configuration block, the method further includes: Stop packaging new blocks awaiting consensus; After the consensus algorithm in the blockchain is switched, a new block to be consensus is packaged and broadcast to each node in the blockchain. The node is used to reach a consensus on the received block to be consensus using the switched consensus algorithm.

4. The switching method as described in claim 1, characterized in that, If a predetermined number of other nodes in the blockchain have the same consensus state as the current node, then the consensus state is stored in the on-chain data of the blockchain, including: Broadcast the checkpoint information to other nodes in the blockchain; Receive other checkpoint information broadcast by other nodes in the blockchain; Determine a first number of other checkpoint information received that are consistent with the status of the checkpoint information; If the first quantity is greater than or equal to a preset value, then it is determined that there are a preset number of other nodes in the blockchain that are consistent with the current consensus state of the node. Generate stable checkpoint information based on the checkpoint information; The stability checkpoint information is uploaded to the blockchain.

5. The switching method according to any one of claims 1-4, characterized in that, The method further includes: Receive a consensus message, the consensus message having a corresponding source node and a first version, the first version being the version of the consensus algorithm used by the consensus message; If the first version does not match the second version corresponding to the node, consensus algorithm switching exception handling is performed; the second version is the version of the consensus algorithm currently used by the node. If the first version matches the second version corresponding to the node, then the consensus message is agreed upon using the consensus algorithm corresponding to the second version.

6. The switching method as described in claim 5, characterized in that, If the first version does not match the second version corresponding to the node, then consensus algorithm switching exception handling is performed; The second version is the version of the consensus algorithm currently used by the node, including: If the first version is lower than the second version, the configuration information of the consensus algorithm corresponding to the second version is returned to the source node. The source node is used to switch the currently used consensus algorithm to the consensus algorithm corresponding to the second version according to the configuration information. If the first version is higher than the second version, a consensus message is returned to the source node, and the configuration information of the consensus algorithm of the first version returned by the source node for the consensus message is received; the consensus algorithm of the node is switched to the consensus algorithm corresponding to the first version according to the configuration information.

7. The switching method according to any one of claims 1-4 or 6, characterized in that, After initializing the node according to the target consensus algorithm and the consensus state, the method further includes: Continue retrieving the consensus block following the configuration block from the transaction pool; The target consensus algorithm is used to reach a consensus on the block to be reached.

8. A consensus algorithm switching module, characterized in that, In a blockchain node, the blockchain comprises multiple nodes, which may be master nodes or non-master nodes, and includes a consensus layer, an algorithm layer, and a transaction pool; wherein, The consensus layer is used to package the configuration transaction into a configuration block when it receives a configuration transaction for switching the consensus algorithm in the blockchain. The configuration block is obtained by the master node by packaging the configuration transaction separately. The configuration transaction is sent to the master node by the blockchain administrator. The master node is used to broadcast the configuration block to each of the non-master nodes. The algorithm layer is used to broadcast the configuration block to the slave nodes in the blockchain; The transaction pool is used to store the transactions received by the node.

9. The consensus algorithm switching module as described in claim 8, characterized in that, The consensus layer includes a consensus management component, which is used to handle abnormal situations such as consensus algorithm switching.

10. A consensus algorithm switching device, characterized in that, A node applied to a blockchain, wherein the blockchain includes multiple nodes, the nodes being master nodes or non-master nodes, the device comprising: The generation module is used to generate checkpoint information if the block to be reached for consensus obtained from the transaction pool is a configuration block. The checkpoint information is used to record the current consensus state of the node. The configuration block is obtained by the master node of the blockchain by packaging the configuration transaction separately. The configuration transaction is sent to the master node by the blockchain administrator. The master node is used to broadcast the configuration block to each of the non-master nodes. The on-chain module is used to store the consensus state in the on-chain data of the blockchain if a preset number of other nodes in the blockchain have the same consensus state as the current node. An acquisition module is used to acquire a configuration transaction from the configuration block, wherein the configuration transaction includes the target consensus algorithm to be switched. A switching module is used to switch the consensus algorithm currently used by the node to the target consensus algorithm. An initialization module is used to initialize the node according to the target consensus algorithm and the consensus state, so as to complete the switching of the consensus algorithm on the node.

11. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-7.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images