Main node switching method and device of block chain cluster, equipment and storage medium

Abstract

The invention discloses a main node switching method and device of a block chain cluster, equipment and a storage medium, and can be applied to various scenes such as a block chain technology, a cloud technology, artificial intelligence and vehicle-mounted, in the method, a task target is configured for a main node of an Nth schedule in advance, when the task target of the Nth schedule is completed, an active main node switching process is triggered, and the task target of the Nth schedule is completed; therefore, active master change is carried out through the master node, the situation that a single node serves as the master node for a long time is avoided, the probability that the master node has an abnormal behavior but other slave nodes cannot find the abnormal behavior can be reduced, the reliability of the block chain is improved, namely, the behavior of the master node is restrained, and the reliability of the block chain is improved. The possibility of abnormal behaviors of the main node is reduced, and finally the reliability of the block chain is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and provides a method, apparatus, device, and storage medium for switching the primary node of a blockchain cluster. Background Art

[0002] The raft consensus algorithm belongs to a non-Byzantine fault tolerance (Crash Fault Tolerance, CFT) consensus algorithm and is a consistency algorithm based on log replication. In a blockchain cluster implemented based on the raft consensus algorithm, a primary node is elected from multiple nodes through an election mechanism. The primary node can also be called a leader, and other nodes are secondary nodes, which can also be called followers. The primary node is responsible for initiating block proposals, and the secondary nodes are responsible for verifying and submitting blocks to the blockchain.

[0003] Currently, in a blockchain cluster based on the raft consensus algorithm, as long as the cluster still meets the minimum block production conditions of the CFT consensus algorithm, that is, in a cluster of 2f + 1 nodes, there are greater than or equal to f + 1 nodes in a normal state, the primary node generally does not change. Only when the primary node fails, shuts down, or has network anomalies and other problems and cannot initiate block proposals, will the blockchain cluster replace the primary node. Otherwise, the primary node will always be in the role of the primary node and assume the proposal responsibility of the blockchain.

[0004] However, if the primary node has abnormal behaviors, such as execution logic errors or data tampering, other secondary nodes cannot detect such abnormal behaviors and still verify the data in the proposals sent by the primary node, which will seriously affect the reliability of the blockchain. Summary of the Invention

[0005] Embodiments of the present application provide a method, apparatus, device, and storage medium for switching the primary node of a blockchain cluster, which are used to implement the active primary node replacement function of the blockchain cluster and improve the reliability of the blockchain.

[0006] On the one hand, a method for switching the primary node of a blockchain cluster is provided, which is applied to the primary node included in the blockchain cluster. The blockchain cluster further includes multiple secondary nodes. The method includes:

[0007] Determine that the primary node has completed the task objectives of the Nth term according to the term information associated with the primary node. The term information is used to indicate that the primary node is the primary node of the Nth term and the task objectives to be completed within the Nth term, where N is an integer;

[0008] Determine M candidate nodes that meet the preset conditions from the multiple slave nodes according to the total number of blocks included in the blockchains corresponding to the respective slave nodes. The preset conditions include: the total number of blocks corresponding to the slave node is greater than or equal to the total number of blocks corresponding to the master node, and M is an integer;

[0009] If M is not zero, send an election instruction to each candidate node respectively. The election instruction is used to notify the corresponding candidate node to initiate the election process of the master node for the (N + 1)-th term;

[0010] If it is determined based on the received feedback information that the target candidate node among the M candidate nodes is successfully elected as the master node for the (N + 1)-th term, switch the role status of the master node to the slave node status. The feedback information is used to indicate the election result of the election process initiated by the corresponding candidate node.

[0011] On the one hand, a method for switching the master node of a blockchain cluster is provided, which is applied to the target slave node included in the blockchain cluster. The blockchain cluster includes a master node and multiple slave nodes, and the total number of blocks in the blockchain corresponding to the target slave node is greater than or equal to the total number of blocks in the blockchain corresponding to the master node. The method includes:

[0012] Receive the election instruction sent by the master node. The election instruction is sent by the master node after determining that the task target for the N-th term has been completed according to the associated tenure information. The election instruction is used to notify the target slave node to initiate the election process of the master node for the (N + 1)-th term. The tenure information is used to indicate that the master node is the master node for the N-th term and the task target to be completed during the N-th term, where N is an integer;

[0013] Based on the election instruction, broadcast an election request to enter the election process. The election request indicates that the target slave node requests to become the master node for the (N + 1)-th term;

[0014] When it is determined that the target slave node is successfully elected as the master node for the (N + 1)-th term according to the received voting results for the election process, broadcast feedback information. Among them, the voting results are used to indicate acceptance or rejection of the target slave node becoming the master node for the (N + 1)-th term, and the feedback information is used to indicate that the target slave node is successfully elected as the master node for the (N + 1)-th term;

[0015] Switch the role status of the target slave node to the master node status.

[0016] On the one hand, a device for switching the master node of a blockchain cluster is provided, which is applied to the master node included in the blockchain cluster. The blockchain cluster further includes multiple slave nodes. The device includes:

[0017] A determination unit, configured to determine, according to the term information associated with the master node, that the master node has completed the task objective of the Nth term, where the term information is used to indicate that the master node is the master node of the Nth term and the task objective to be completed during the Nth term, and N is an integer;

[0018] A node selection unit, configured to determine M candidate nodes that meet a preset condition from the multiple slave nodes according to the total number of blocks included in the blockchains respectively corresponding to the multiple slave nodes, where the preset condition includes that the total number of blocks corresponding to a slave node is greater than or equal to the total number of blocks corresponding to the master node, and M is an integer;

[0019] A notification unit, configured to, if M is not zero, send an election instruction to each candidate node respectively, where the election instruction is used to notify the corresponding candidate node to initiate the election process for the master node of the (N + 1)th term;

[0020] A status switching unit, configured to, if it is determined, based on the received feedback information, that the target candidate node among the M candidate nodes is successfully elected as the master node of the (N + 1)th term, switch the role status of the master node to the slave node status, where the feedback information is used to indicate the election result of the election process initiated by the corresponding candidate node.

[0021] On the one hand, a master node switching device for a blockchain cluster is provided, which is applied to a target slave node included in the blockchain cluster. The blockchain cluster includes a master node and multiple slave nodes, and the total number of blocks in the blockchain corresponding to the target slave node is greater than or equal to the total number of blocks in the blockchain corresponding to the master node; the device includes:

[0022] A receiving unit, configured to receive the election instruction sent by the master node, where the election instruction is sent by the master node after determining that it has completed the task objective of the Nth term according to the associated term information, and the election instruction is used to notify the target slave node to initiate the election process for the master node of the (N + 1)th term, and the term information is used to indicate that the master node is the master node of the Nth term and the task objective to be completed during the Nth term, and N is an integer;

[0023] A sending unit, configured to broadcast an election request based on the election instruction to enter the election process, where the election request indicates that the target slave node requests to become the master node of the (N + 1)th term; and, when it is determined, according to the received voting results for the election process, that the target slave node is successfully elected as the master node of the (N + 1)th term, broadcast feedback information; where the voting results are used to indicate acceptance or rejection of the target slave node becoming the master node of the (N + 1)th term, and the feedback information is used to indicate that the target slave node is successfully elected as the master node of the (N + 1)th term;

[0024] A status switching unit for switching the role status of the target slave node to the master node status.

[0025] On the one hand, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of any of the above methods are implemented.

[0026] On the one hand, a computer storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0027] On the one hand, a computer program product is provided. The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor of the computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the steps of any of the above methods.

[0028] In the embodiments of the present application, a task target is pre-configured for the master node of the Nth term. When it completes the task target of the Nth term, it will trigger an active master change process, that is, a slave node that meets the conditions can be selected as a candidate node for the master node, and the candidate node is notified to initiate an election process. When a candidate node is successfully elected as the master node of the (N + 1)th term, the role status of the master node of the Nth term is switched to the slave node status. By the master node actively changing the master, it is avoided that a single node acts as the master node for a long time, which can reduce the probability of the situation where the master node has abnormal behavior and other slave nodes cannot detect this abnormal behavior, and improves the reliability of the blockchain. On the other hand, due to the characteristics of the blockchain itself, the requirement for the continuity of block information is extremely high, and the master node will switch once it completes the task target. Then, once the master node has abnormal behavior, it is very easy to be detected, which is equivalent to forming a constraint on the behavior of the master node and reducing the possibility of the master node having abnormal behavior, ultimately improving the reliability of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0030] Figure 1 It is a system architecture diagram of the blockchain system provided by the embodiments of the present application;

[0031] Figure 2 Schematic diagram of the block structure provided by the embodiment of the present application;

[0032] Figure 3 Schematic diagram of the structure of the blockchain node provided by the embodiment of the present application;

[0033] Figure 4 Schematic flowchart of the main node switching method of the blockchain cluster provided by the embodiment of the present application;

[0034] Figure 5 Example diagram of the main node switching process provided by the embodiment of the present application;

[0035] Figure 6A and Figure 6B Schematic flowchart of a main node switching method provided by the embodiment of the present application;

[0036] Figure 7 Another schematic flowchart of the main node switching method provided by the embodiment of the present application;

[0037] Figure 8A and Figure 8B Another schematic flowchart of the main node switching method provided by the embodiment of the present application;

[0038] Figure 9 Another schematic flowchart of the main node switching method provided by the embodiment of the present application;

[0039] Figure 10A and Figure 10B Schematic flowchart of the process of the main node of the blockchain cluster uploading a block provided by the embodiment of the present application;

[0040] Figure 11 Schematic flowchart of the process of the slave node of the blockchain cluster uploading a block provided by the embodiment of the present application;

[0041] Figure 12 A schematic diagram of the structure of the main node switching device of the blockchain cluster provided by the embodiment of the present application;

[0042] Figure 13 Another schematic diagram of the structure of the main node switching device of the blockchain cluster provided by the embodiment of the present application;

[0043] Figure 14 Schematic diagram of the composition structure of the computer device provided by the embodiment of the present application. Detailed implementation manners

[0044] To make the objectives, technical solutions, and advantages of this application more clear and understandable, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of them. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts belong to the scope of protection of this application. Without conflict, the embodiments in this application and the features in the embodiments can be combined arbitrarily with each other. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0045] To facilitate the understanding of the technical solutions provided in the embodiments of this application, some key terms used in the embodiments of this application are explained here first:

[0046] 1. Blockchain

[0047] Or known as a distributed data record ledger or block ledger, it is a chain-like data structure formed by combining data blocks in a sequential and connected manner according to time order, and is guaranteed to be tamper-proof and forgery-proof by cryptographic means, realizing a decentralized distributed ledger. Generally, it consists of content such as consensus, blocks, state data storage, and cryptographic identity security. Since the ledger is distributedly stored and the blocks are consensus-based, it has features such as being tamper-proof, traceable, and jointly maintained.

[0048] 2. Blockchain cluster

[0049] It can also be called a blockchain network. A blockchain cluster consists of multiple distributed devices. In blockchain technology, any device in the network can be a node of the blockchain cluster and can participate in the recording and storage of the blockchain. Based on the consensus mechanism among nodes, the entire blockchain is jointly maintained, such as based on the raft consensus algorithm. Since any node can have a complete copy of the blockchain data, if any node fails, the remaining nodes can still work normally, so the reliability based on the blockchain storage method is high.

[0050] In addition, in blockchain technology, the entire blockchain is jointly maintained by numerous nodes. Each node can have the same permissions, and all data information in the blockchain is publicly transparent. Modifications made by a single node or even multiple nodes to their own data cannot affect the data of other nodes, unless more than half of the nodes in the entire blockchain network can be controlled to make modifications. However, this method is extremely difficult. Moreover, each block in the blockchain is associated with the two adjacent blocks. To tamper with the data of a block, it is necessary to tamper with the data of multiple related blocks, which is quite difficult. Therefore, the data stored based on the blockchain is immutable.

[0051] 3. Primary Node Switching

[0052] Primary node switching refers to switching from the old primary node to the new primary node, and the term of the primary node is incremented by one, that is, switching from the Nth term to the (N + 1)th term. One term of the primary node can be called a view. Therefore, primary node switching can also be called view switching, that is, the process of entering the next view from one view.

[0053] 4. Raft Consensus Algorithm

[0054] The Raft consensus algorithm belongs to the CFT consensus algorithm and is a consistency algorithm based on log replication.

[0055] In the Raft consensus algorithm, the consensus problem can be decomposed into three sub-problems:

[0056] (1) Leader election: In a blockchain cluster based on the Raft consensus algorithm, there is exactly one leader node, that is, the primary node. If the primary node fails, such as crashing and being unable to serve as the primary node, a new primary node is elected through the election mechanism.

[0057] (2) Log replication: The primary node receives external data update or deletion requests, and then replicates the log entries to the follower nodes, that is, the secondary nodes, to ensure the consistency of the cluster data.

[0058] (3) Safety: The Raft consensus algorithm processes some special cases through safety principles to ensure the completeness of the Raft algorithm.

[0059] Therefore, in a blockchain cluster based on the Raft consensus algorithm, only when the primary node fails, such as crashing and being unable to serve as the primary node, will a new primary node be elected through an election mechanism. In this way, if the primary node has abnormal behaviors, such as execution logic errors or data tampering, other secondary nodes cannot detect such abnormal behaviors and still verify the data in the proposals sent by the primary node, which will seriously affect the reliability of the blockchain. In addition to the Raft consensus algorithm, in other blockchain consensus algorithms, usually only when the primary node is detected as a malicious node will the primary node be replaced. However, the malicious detection of the primary node is usually lagged and inaccurate, so there is still a problem of low reliability of the blockchain.

[0060] Based on this, the embodiment of the present application provides a method for switching the primary node of a blockchain cluster. In this method, a mechanism for actively changing the primary node is provided. By actively changing the primary node, it is possible to prevent a single node from serving as the primary node for a long time and reduce the possibility of abnormal behaviors of the primary node.

[0061] Specifically, a task target is pre-configured for the primary node in the Nth term. When it completes the task target of the Nth term, it will trigger an active primary node switching process, that is, a secondary node that meets the conditions can be selected as a candidate node for the primary node, and the candidate node is notified to initiate an election process. When a candidate node is successfully elected as the primary node in the (N + 1)th term, the role status of the primary node in the Nth term switches to the secondary node status. By actively switching the primary node by the primary node itself, it is possible to prevent a single node from serving as the primary node for a long time, reduce the probability of a situation where the primary node has abnormal behaviors but other secondary nodes cannot detect such abnormal behaviors, and improve the reliability of the blockchain. On the other hand, due to the characteristics of the blockchain itself, there is a very high requirement for the continuity of block information, and the primary node will switch once it completes the task target. Then, once the primary node has abnormal behaviors, it is very easy to be detected, which is equivalent to imposing a constraint on the behavior of the primary node and reducing the possibility of abnormal behaviors of the primary node, ultimately improving the reliability of the blockchain.

[0062] Moreover, only when the primary node continuously tampers with each block sent to the secondary nodes can it ensure the self-consistency of the data of the secondary nodes and finally pass the verification and submit the block. After the primary node is actively switched, if the new primary node has no abnormal behaviors, it will be incompatible with the blocks submitted by the old primary node, causing the cluster nodes to suspend the consensus process because they cannot process the block proposals sent by the new primary node. If the number of nodes suspending the consensus process exceeds half, the entire blockchain system will stop working. Therefore, through active primary node switching, it is more convenient to detect whether the old primary node has abnormal behaviors.

[0063] The following briefly introduces the application scenarios applicable to the technical solutions of the embodiments of the present application. It should be noted that the application scenarios introduced below are only used to illustrate the embodiments of the present application rather than to limit them. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0064] The solution provided by the embodiments of the present application can be applicable to a blockchain cluster. For example, it can be applicable to a blockchain cluster based on the raft consensus algorithm. Of course, it can also be applied to a blockchain cluster with other consensus algorithms, and no limitation is made thereto.

[0065] See Figure 1 , which is a system architecture diagram of a blockchain system applicable to the embodiments of the present application. The blockchain system at least includes a client 10 and a blockchain cluster 20. The blockchain cluster 20 includes a plurality of blockchain nodes 201. Among them, the blockchain node 201 can be any form of computing device accessing the network, such as a server, a user terminal, etc. The blockchain nodes 201 can be directly or indirectly connected through wired or wireless communication methods, and no limitation is made thereto in the embodiments of the present application.

[0066] In the embodiments of the present application, the blockchain nodes 201 can be divided into master nodes and slave nodes according to their roles. For example, when the raft consensus algorithm is adopted, one blockchain node 201 in the blockchain cluster 20 is the master node, and the remaining blockchain nodes 201 are slave nodes. Of course, they can also be divided according to functions. For example, they can be divided into proposal nodes, consensus nodes, verification nodes, etc., and no specific limitation is made.

[0067] For each blockchain node 201, it can include a hardware layer, an intermediate layer, an operating system layer, and an application layer. The functions involved in the blockchain node 201 include:

[0068] (1) Routing, which is a basic function of the blockchain node and is used to support communication between blockchain nodes.

[0069] In addition to the routing function, the blockchain node can also have the following functions:

[0070] (2) Application, which is used to be deployed in the blockchain, implement specific services according to actual business needs, record the data related to the implemented functions to form record data, carry a digital signature in the record data to indicate the source of the task data, and send the record data to other blockchain nodes in the blockchain system. When other blockchain nodes verify the source and integrity of the record data successfully, the record data is added to the temporary block.

[0071] For example, the services implemented by the application include:

[0072] 2.1) Wallet, which is used to provide the function of conducting electronic currency transactions, including initiating a transaction (i.e., sending the transaction record of the current transaction to other blockchain nodes in the blockchain system. After successful verification by other blockchain nodes, as a response to acknowledging the validity of the transaction, the record data of the transaction is deposited into the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address.

[0073] 2.2) Shared ledger, which is used to provide functions such as storage, query, and modification of account data, sending the record data of operations on account data to other blockchain nodes in the blockchain system. After other blockchain nodes verify its validity, as a response to acknowledging the validity of the account data, the record data is deposited into the temporary block, and can also send a confirmation to the blockchain node that initiated the operation.

[0074] 2.3) Smart contract, a computerized protocol that can execute the terms of a certain contract, implemented through code deployed on the shared ledger and executed when certain conditions are met. According to actual business requirements, the code is used to complete automated transactions, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods; of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0075] (3) Blockchain, including a series of blocks that are sequentially connected in the order of generation. Once a new block is added to the blockchain, it will not be removed again. The block records the record data submitted by blockchain nodes in the blockchain system. As Figure 2 shown, it is an optional schematic diagram of the block structure provided by the embodiment of this application. The block ledger is organized in a chain structure. Each block contains a set of transactions, a block header (including metadata such as the hash value of the previous block and the timestamp), and other information. The block ledger provides a public and immutable transaction history record for the blockchain system, ensuring the transparency and consistency of the system.

[0076] The block is used to record the data set and status result divided according to certain conditions, and is formed after consensus is reached among each node. The status result refers to the data structure used to represent the current state of the blockchain system in the blockchain system. The status result includes: the balance of all accounts, the status of smart contracts, and other relevant information, etc. The status result is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a certain point in time. In the blockchain system, status data is usually stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security. Please refer to Figure 2As shown, each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected through the hash value to form a blockchain. In addition, the block may also include information such as the timestamp when the block is generated. A blockchain, in essence, is a decentralized database, a series of data blocks generated by using cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0077] See Figure 3 , which is a schematic structural diagram of a blockchain node provided by an embodiment of the present application. In the embodiment of the present application, the structures of different blockchain nodes 201 may be the same or different. Here, the case where the structures of different blockchain nodes 201 are the same is specifically taken as an example for introduction. Then each blockchain node 201 includes: a network module 2011, a validator module 2012, a proposer module 2013, a submitter module 2014, a transaction pool 2015, a consensus module 2016, a blockchain engine 2017, a state engine 2018, and a storage module 2019.

[0078] The network module 2011 is used to implement communication between blockchain nodes. For example, it is used to send and receive consensus messages exchanged between blockchain nodes, and is responsible for functions such as connection management, data transmission encryption, and data broadcasting between blockchain nodes.

[0079] The validator module 2012 is used to verify transactions and blocks to ensure the legality and correctness of transactions and blocks. For example, it may include certificate verification and permission verification, etc. Certificate verification refers to verifying the certificate signature of transactions and blocks to ensure that transactions and blocks are initiated by legitimate participants. Permission verification refers to checking whether the initiator of the transaction and block has the corresponding permission to operate.

[0080] The proposer module 2013 is used to take out a batch of transactions from the transaction pool 2015, package them into a block, and call relevant modules to execute the transactions in the block. After obtaining the transaction execution results, they will also be attached to the block.

[0081] The submitter module 2014 is used to submit the block to the blockchain.

[0082] The transaction pool 2015 is used to manage transactions to be processed, including functions such as receiving, storing, and sorting transactions. Each transaction corresponds to a unique identifier.

[0083] The consensus module 2016 is used to implement the consensus algorithm of the blockchain system. The blockchain engine 2017, such as the raft consensus algorithm engine, is encapsulated in the consensus module 2016. And the consensus module 2016 can interact with other functional modules to implement functions, such as interacting with the network module 2011, the proposer module 2013, the validator module 2012, the committer module 2014, etc. And the consensus module 2016 can also be used to perform some consensus operations related to the blockchain. Among them, the blockchain engine 2017 can be regarded as the lower-level module of the consensus module. The blockchain engine is responsible for the processing related to the consensus algorithm, such as implementing specific elections, processing proposals, and voting in the raft consensus algorithm, and performing two-round consensus on the encapsulated log entries, etc. However, the interaction between the blockchain engine and the outside needs to be forwarded through the consensus module.

[0084] The status engine 2018 is used to regularly collect the status information such as the block height of all slave nodes when the blockchain node is the master node, as the reference information for the master node handover. The status engine 2018 can be independent of the consensus module 2016 and be called by the consensus module 2016.

[0085] The storage module 2019 is used to store blockchain data, and the blockchain data includes block ledgers, status data, etc. The block ledger includes block data in the blockchain; the status data includes status information in the blockchain system, such as account balances, the status of smart contracts, etc.

[0086] In practical applications, each blockchain node 201 can include the above functional modules. However, since the role status of different blockchain nodes 201 in the blockchain cluster 20 is different, the functions of the above functional modules may not be fully utilized. For example, for the master node, it is responsible for initiating block proposals, so the proposer module 2013 of the master node needs to play a role. While the slave node does not need to initiate block proposals, when the blockchain node 201 is in the slave node state, the proposer module 2013 does not need to be enabled. Through the master node switching method in the embodiments of the present application, when the task goals of a term are met, the master node in the blockchain cluster 20 can be actively switched, avoiding a single blockchain node 201 acting as the master node for a long time, and being able to reduce the probability of the situation where the master node has abnormal behavior and other slave nodes cannot detect this abnormal behavior, thus improving the reliability of the blockchain.

[0087] Next, in combination with the above-described application scenarios and system architectures, the method provided by the exemplary embodiments of the present application will be described with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown for the convenience of understanding the spirit and principle of the present application, and the embodiments of the present application are not limited in this regard.

[0088] SeeFigure 4 As shown in the figure, it is a schematic flowchart of the master node switching method for the blockchain cluster provided by the embodiments of the present application. This method can be executed by a blockchain node of the blockchain cluster. The blockchain cluster includes a master node and multiple slave nodes. The blockchain node executing the master node switching method can be, for example, the master node or a slave node in the blockchain cluster, or it can also be executed by a functional module included in the master node or the slave node. For example, it can be executed by the consensus module in the master node or the slave node. Since the master node switching method involves the interaction process between the master node and the slave nodes, in the following description, the master node switching method will be introduced in the way of their interaction. The specific implementation process of this method is as follows:

[0089] Step 401: The master node (in the Nth term) records the term information.

[0090] In the embodiments of the present application, after a node becomes the master node, it can record the term information of itself becoming the master node this time. Among them, the term information is used to indicate that the current master node that the node becomes is the master node in the Nth term, and the task objectives that the node needs to complete in the Nth term. N is an integer. Among them, the task objective is the task that the node needs to complete in the Nth term. And after the node completes the task objective, the master node replacement process can be carried out.

[0091] Specifically, the task objective can include at least one of the following contents:

[0092] (1) The task objective indicates the number of target blocks newly added to the blockchain corresponding to the master node. In other words, the task objective specifies that the number of blocks that need to be consensus in the Nth term is the number of target blocks.

[0093] In a possible implementation manner, the task objective can be indicated by a specific number of blocks. For example, directly specify the number of target blocks. Then, in the Nth term, the master node can record the actual number of blocks in the blockchain corresponding to the master node and detect whether the actual number of blocks is greater than or equal to the number of target blocks.

[0094] Exemplarily, it can be specified that 100 blocks need to be consensus in the Nth term. Then, in the master node, the value of the actual number of blocks can be maintained. That is, after completing the consensus and uploading of one block, the master node can increment the value of the actual number of blocks by one and detect whether the value of the actual number of blocks is greater than or equal to the number of target blocks, that is, detect whether the task objective of the master node has been completed.

[0095] In another possible implementation, the task objective can also be indicated by a block height range. For example, at the beginning of the Nth term, the block height of the blockchain is P. Then the task objective indicates that within the Nth term, the consensus and on-chain of the block heights from P to P + 100 need to be completed. Then the primary node can, within the Nth term, detect whether the block height in the current blockchain is greater than or equal to P + 100.

[0096] Exemplarily, at the beginning of the Nth term, the block height of the blockchain is 1000. Then it can be specified that within the Nth term, the consensus and on-chain of the blocks in the height range from 10001 to 10100 need to be completed. Then the primary node can detect whether the block height in the current blockchain is greater than or equal to 10100, that is, detect whether the task objective of the primary node has been completed.

[0097] (2) The task objective indicates the target term duration. In other words, the task objective specifies the duration of the Nth term. For example, the target term duration is one day or one week, and the specific value is not limited.

[0098] Of course, the task objective can also include other content, and the embodiments of the present application do not limit this.

[0099] In one possible implementation, the term information can be stored and maintained in the blockchain engine, and this information is transparent to the consensus module. The consensus module can obtain the term information through the blockchain engine. For example, if the blockchain engine is a raft engine, the term information of the primary node itself can be maintained in the raft engine.

[0100] In another possible implementation, considering the specific content of the consensus, such as information like block height, etc., is also transparent to the raft engine. The raft engine usually only takes care of the consensus data and does not care what the data specifically is. Therefore, for example, the active primary node replacement function determined by the block height can be controlled by the consensus module. That is to say, the term information can be recorded within the consensus module, such as specifying the block height range or term duration to be completed within the Nth term, etc.

[0101] Of course, the above two methods can also be combined for execution. For example, both the blockchain engine and the consensus module can record and maintain the term information, or part of the term information can be stored in the blockchain engine and another part in the consensus module.

[0102] Step 402: The primary node (in the Nth term) determines that the primary node has completed the task objective of the Nth term according to the term information associated with the primary node.

[0103] Specifically, corresponding to the above two implementation manners, that is, if the task objective indicates the number of target blocks newly added to the blockchain corresponding to the master node, then within the Nth term, when the actual number of blocks newly added to the blockchain corresponding to the master node is greater than or equal to the number of target blocks, it is determined that the master node has completed the task objective of the Nth term. Exemplarily, continuing with the above example, when the master node detects that the value of the actual number of blocks it maintains is greater than or equal to the number of target blocks, it is determined that the master node has completed the task objective of the Nth term; or, when the master node detects that the block height in the current blockchain is greater than or equal to 10100, it is determined that the master node has completed the task objective of the Nth term, that is, the master node replacement needs to be performed.

[0104] If the task objective indicates the target term duration, then when the actual term duration of the master node is greater than or equal to the target term duration, it is determined that the master node has completed the task objective of the Nth term, that is, the master node replacement needs to be performed.

[0105] In actual application, the master node can determine whether the term objective has been completed after each block is submitted to the blockchain, or can periodically determine whether the term objective has been completed. Of course, other possible methods can also be adopted, and the embodiments of the present application do not limit this.

[0106] Step 403: The master node (in the Nth term) stops initiating new block proposals based on the fact that the master node has completed the task objective.

[0107] Exemplarily, taking a blockchain cluster based on the raft consensus algorithm as an example, the initiation of block proposals is carried out by the proposer module. When it is determined that the master node has completed the task objective, an active master replacement process will be performed. During the active master replacement, there is no stable master node in the blockchain cluster. To maintain the stable operation and data consistency of the blockchain cluster, the proposer module of the master node can be notified to stop initiating new block proposals.

[0108] It can be understood that the process of step 403 is an optional step and can be executed or not executed in actual application. Therefore, step 403 is Figure 4 shown by a dashed line.

[0109] Step 404: The master node (in the Nth term) determines M candidate nodes that meet the preset conditions from multiple slave nodes according to the total number of blocks included in the blockchains corresponding to the multiple slave nodes respectively, where M is an integer.

[0110] In the embodiments of the present application, the master node may cache the total number of blocks included in the blockchains corresponding to each slave node respectively as reference information for the master node's term change. For example, the total number of blocks corresponding to each slave node can be obtained and cached through the status engine in the master node. Generally speaking, the blocks in the blockchain are continuously numbered starting from the first block. Therefore, the total number of blocks is essentially the block number, and this number can also be called the block height.

[0111] When the master node determines that the above-mentioned term change conditions are met, the active master change process will be triggered. The master node needs to select a slave node that meets the preset conditions as the candidate node for the master node in the next term. Among them, the preset conditions may include at least one of the following conditions:

[0112] (1) The total number of blocks corresponding to the slave node is greater than or equal to the total number of blocks corresponding to the master node.

[0113] When the master node is changed, the block height of the slave node that can be the master node cannot be less than the block height of the master node.

[0114] In an actual scenario, the master node is responsible for initiating block proposals. Therefore, the complete blockchain is usually stored in the master node, and this information is collected by the current master node. Therefore, the block height of the slave node usually will not be higher than the block height of the master node. Thus, the preset condition can also be understood as the total number of blocks corresponding to the slave node being equal to the total number of blocks corresponding to the master node.

[0115] (2) The connection status of the slave node is normal.

[0116] When the master node is changed, a slave node with an abnormal connection status may not be able to receive messages normally. Therefore, such a slave node cannot be used as a candidate node.

[0117] In the embodiments of the present application, the status information of each slave node, such as the total number of blocks corresponding to each slave node or the connection status, etc., can be cached through the status engine.

[0118] In a possible implementation manner, the status information of all current slave nodes can be obtained from the status engine, and then according to the status information of the slave nodes, a slave node that meets the preset conditions can be selected as the candidate node.

[0119] Taking the status information as the total number of blocks as an example, the current total number of blocks of each slave node can be obtained from the status engine and compared with the total number of blocks of the master node to select a slave node with the same total number of blocks as the master node as the candidate node.

[0120] In another possible implementation, considering the status information maintained by the status engine, due to the timeliness issue of the status engine, the status information may not be updated in a timely manner to a certain extent. Then, in the status information of the slave nodes collected, due to information lag, some slave nodes with normal status may be misjudged as having a lagging block height, so they are not selected when determining the candidate nodes. However, as long as the master change can be finally completed, it has no impact on the blockchain cluster itself. But if no slave node can be selected as a candidate node due to these reasons, the rotation of the master will fail.

[0121] To improve the success rate of master node switching, after obtaining the total number of blocks corresponding to each of the multiple slave nodes cached from the status engine, when it is determined that the number of candidate nodes meeting the preset conditions is zero, the master node can send block number acquisition requests to the multiple slave nodes respectively, triggering a round of collection of status information, that is, for re-collecting the status information of the slave nodes, and then determining M candidate nodes from the multiple slave nodes again according to the total number of blocks respectively fed back by the multiple slave nodes.

[0122] Specifically, the consensus module can call the interface of the status engine to promote the status engine to actively initiate a process of collecting the status information of all slave nodes, and then re-select candidate nodes once according to the updated status information, reducing the probability of the situation where the number of candidate nodes is zero and improving the success rate of master node switching.

[0123] Step 405: If M is not zero, the master node (in the Nth term) sends election instructions to each candidate node respectively. Correspondingly, the candidate nodes (i.e., the target slave nodes) receive the election instructions from the master node.

[0124] Among them, the election instructions are used to notify the corresponding candidate nodes to initiate the election process of the master node in the (N + 1)th term.

[0125] Specifically, during the active leader change, the leader node can record leader change information in its own cache. For example, the leader change information may include the current term identifier, the next term identifier, the candidate node list, and the current leader change status. The candidate node list is used to record the aforementioned M candidate nodes. The order of the candidate nodes in the candidate node list can be sorted by name; alternatively, it can also be sorted by node performance, with better performance ranked higher, so that nodes with better performance can be preferentially selected as the leader node; or, it can also be sorted by the communication efficiency between the candidate node and the leader node, with higher communication efficiency ranked higher, so that the candidate node with higher communication efficiency can be notified first to improve the efficiency of leader node switching. The current leader change status is used to indicate whether the leader node switching process has been successfully completed. For example, the leader change status may include "executing the leader change policy" or "normal status", etc. Among them, "executing the leader change policy" indicates that the leader node switching process is in progress, and "normal status" indicates that the leader node switching process has ended and the leader node is not executing the leader change policy.

[0126] In the embodiment of the present application, the active leader change process triggered by the leader node is asynchronous. After the leader node triggers the active leader change, the leader node only needs to forward network messages to the blockchain engine (such as the raft engine), and then wait for the blockchain engine to return the leader node switching result.

[0127] Specifically, the consensus module in the leader node is responsible for the process control of the entire leader change process, and the blockchain engine is used to execute the specific leader change policy. For example, for any one of the M candidate nodes, when sending an election instruction to it, the consensus module can call the blockchain engine interface with this candidate node as the target node to initiate the leader change process. Then, for the blockchain engine, it can send an election instruction to the target node to instruct the target node to initiate the leader change process. It should be noted that when the blockchain engine sends an election instruction to the target node, it can call the network module through the consensus module to send the election instruction to the network module of the target node.

[0128] In a possible implementation manner, the leader node can send election instructions to each candidate node simultaneously, that is, the leader node sends election instructions to each candidate node separately at the same time. Then, the candidate nodes that receive the election instructions can each initiate an election request to apply to be the leader node of the (N + 1)th term until one of the candidate nodes is successfully elected as the leader node of the (N + 1)th term, or no candidate node is successfully elected as the leader node of the (N + 1)th term.

[0129] In a possible implementation manner, refer to Figure 5As shown, the main node switching process can also be iterative. In each main node switching process, the main node determines a candidate node from a candidate node list containing M candidate nodes, and sends an election instruction to this candidate node, waiting for the election result of this candidate node. If this candidate node is successfully elected as the main node for the (N + 1)-th term, then this term change is successful, the iteration stops, and the main node change information is cleared. If this candidate node fails to be successfully elected as the main node for the (N + 1)-th term, then it enters the next main node switching process, that is, selects the next candidate node from the remaining candidate nodes again, and sends an election instruction to this candidate node, waiting for the election result of this candidate node, until the term change is successful or the candidate node list is empty. Finally, if the number of remaining candidate nodes is zero, that is, none of the M candidate nodes is successfully elected, then this term change fails and the iteration stops.

[0130] Among them, when selecting candidate nodes for the first time, it is selected from M candidate nodes, and when it is not the first selection, it is selected from the remaining candidate nodes among M candidate nodes. Exemplarily, as shown in Figure 5 it can first select candidate node 1, and send an election instruction to it, waiting for the election result of candidate node 1. If candidate node 1 is successfully elected as the main node for the (N + 1)-th term, then this term change is successful and the iteration stops. If candidate node 1 fails to be successfully elected, then continue to select candidate node 2, continue the above process, and so on, until the term change is successful or the candidate node list is empty.

[0131] Step 406: The target slave node broadcasts an election request based on the election instruction to enter the election process. The election request indicates that the target slave node requests to become the main node for the (N + 1)-th term. Correspondingly, the main node (of the N-th term) receives the election request from the target slave node, and the slave nodes other than the target slave node can also receive the election request from the target slave node.

[0132] It should be noted that here, for the sake of distinction, the slave node serving as a candidate node is called the target slave node. It can be understood that the target slave node is a node that meets the preset conditions, that is, the slave node with the same total number of blocks as the main node.

[0133] For the target slave node (i.e., the candidate node), after receiving the election instruction through the network module, the election instruction is sent to the blockchain engine through the consensus module of the target slave node. The blockchain engine triggers the election process based on the election instruction, that is, broadcasts an election request to other nodes in the blockchain cluster, that is, sends an election request to the main node and the slave nodes. This election request is sent to other nodes by calling the network module through the consensus module, and this election request is used to request the nodes in the blockchain cluster to vote on the target slave node becoming the main node.

[0134] Step 407: The master node (in the Nth term) responds to the election request, votes for the target slave node (e.g., the target candidate node), and obtains the voting result.

[0135] Step 408: The master node (in the Nth term) returns the voting result to the target slave node.

[0136] Step 409: Other slave nodes respond to the election request, vote for the target slave node (e.g., the target candidate node), and obtain the voting result.

[0137] Step 410: Other slave nodes return the voting result to the target slave node.

[0138] Other nodes in the blockchain cluster, including the master node and slave nodes other than the target slave node, can vote on whether the target slave node becomes the master node in the (N + 1)th term and return the voting result to the target slave node. Among them, the voting result is used to indicate acceptance or rejection of the target slave node becoming the master node in the (N + 1)th term.

[0139] Specifically, when multiple slave nodes initiate the election process, the nodes that vote can vote in favor of the target slave node that first receives the election request, and vote against subsequent received election requests. Or, when using the iterative method for master node switching, only one election request from a slave node will be received in each iteration process, and then vote for the slave node in this round of iteration according to the voting rules, and the specific voting rules are not restricted.

[0140] Step 411: The target slave node determines that the target slave node is successfully elected as the master node in the (N + 1)th term according to the received voting results for the election process.

[0141] After the target slave node sends the election request, it can receive the voting results returned by other nodes. The voting result indicates whether to support the target slave node becoming the master node in the (N + 1)th term. Then the target slave node can count the number of votes in favor according to the voting results. When the number of votes meets the election success condition, such as exceeding half of the number of blockchain nodes, and no feedback information indicating successful election is received from any node at present, it can be determined that the target slave node is successfully elected as the master node in the (N + 1)th term.

[0142] It should be noted that for each target slave node that receives the election instruction, an election process can be initiated, but there is only one master node. Therefore, a selection strategy can be configured for constraint. For example, the target slave node that is successfully elected first can be configured as the master node.

[0143] Step 412: The target slave node switches the role status of the target slave node to the master node status.

[0144] Specifically, the election-related process can be implemented through the blockchain engine. After successfully being elected as the master node for the (N + 1)-th term, the blockchain engine can send an indication message to the consensus module, indicating that a new term has started and it has become the master node for this term. Then, the consensus module can clear the previous master change information recorded in the memory, and switch the role status of this node to the master node status. For example, mark the type of this node as the master node, and update the current status to the normal status, which means that the master change policy is not being executed currently and the master change process has ended.

[0145] Since the current target slave node has become the master node for the (N + 1)-th term, it needs to perform the duties of the master node to initiate a block proposal. That is, the consensus module can notify its own proposer module to start the block proposal. In addition, for the smooth progress of the subsequent master change process, the target slave node can also record the term information for the (N + 1)-th term. The term information for the (N + 1)-th term can be the same as or different from the term information for the N-th term. Exemplarily, the term information for the (N + 1)-th term can also specify that the master node for the (N + 1)-th term completes the consensus and on-chain of a specified number of blocks. In addition, the target slave node can also record logs, that is, it is elected as the master node, record the new term and the block height at the start of this term.

[0146] Step 413: The target slave node broadcasts feedback information, where the feedback information is used to indicate that the target slave node has been successfully elected as the master node for the (N + 1)-th term.

[0147] Step 414: The master node (for the N-th term) determines, based on the received feedback information, that the target candidate node (i.e., the target slave node) has been successfully elected as the master node for the (N + 1)-th term among the M candidate nodes.

[0148] In the embodiments of this application, when the master node sends election instructions to multiple candidate nodes simultaneously, the master node may receive feedback information sent by multiple candidate nodes. Among them, the feedback information is used to indicate the election results of the election processes initiated by the corresponding candidate nodes. For example, if the target slave node is elected as the master node for the (N + 1)-th term, the feedback information it sends indicates that its own election result is a successful election. Generally speaking, the feedback information sent by other slave nodes is an unsuccessful election. And if there are multiple successful elections, the master node can determine the target candidate node as the master node for the (N + 1)-th term according to the pre-configured election strategy. For example, the candidate node corresponding to the feedback information received first can be used as the target candidate node, that is, the master node for the (N + 1)-th term.

[0149] If the method of iteratively switching the primary node is adopted, only the feedback information sent by one slave node will be received, that is, only the election process for one target slave node will be carried out simultaneously. Correspondingly, there will be only one election result at the same time. Then, it is determined whether the target slave node is successfully elected as the primary node in the (N + 1)-th term according to the feedback information.

[0150] Step 415: The (N-th term) primary node switches the role status of the primary node to the slave node status.

[0151] Specifically, the election-related process can be implemented by the blockchain engine. After the blockchain engine determines that the target slave node is successfully elected as the primary node in the (N + 1)-th term, it can send an indication message to the consensus module, indicating that a new term has been entered and the primary node of this term has been generated. Then, the consensus module can clear the previous master change information recorded in the memory and switch the role status of this node to the slave node status. For example, mark the type of this node as the primary node and update the current status to the normal status, that is, indicate that the master change policy is not being executed currently and the master change process has ended. In addition, the primary node can also record a log, that is, the primary node switch is successful, record the new term and the node identifier of the primary node in the (N + 1)-th term, such as the node ID (identity).

[0152] In the embodiment of this application, if the (N-th term) primary node determines that M is zero, that is, no candidate node is selected, the primary node cannot be switched. To ensure the normal operation of the blockchain cluster, the (N-th term) primary node can continue to be the primary node and continue to initiate a new block proposal. For example, the (N-th term) primary node extends the term of the N-th term, or the (N-th term) primary node can directly become the primary node in the (N + 1)-th term.

[0153] Or, when none of the M candidate nodes is successfully elected as the primary node in the (N + 1)-th term, that is, none of the M candidate nodes is successfully elected as the primary node in the (N + 1)-th term, then the current primary node switch fails. To ensure the normal operation of the blockchain cluster, the (N-th term) primary node can continue to be the primary node and continue to initiate a new block proposal. For example, the (N-th term) primary node extends the term of the N-th term, or the (N-th term) primary node can directly become the primary node in the (N + 1)-th term.

[0154] In the embodiments of the present application, after the main node switching process ends, each node in the blockchain cluster can record the current main node switching process. Taking the main node as an example, if the target candidate node is successfully elected as the main node in the (N + 1)-th term, the main node can obtain the first result log according to the device identifier and term identifier of the target candidate node, and store the first result log; or, if the main node continues to be the main node, the second result log is obtained according to the reason for the failure of the main node switching, for example, the target node meeting the main node switching condition cannot be found, and the second result log is stored.

[0155] It should be noted that the above serial numbers are only used to distinguish different steps, and do not limit the sequence of execution between each step. For example, the above steps 412 and 413 can be executed in sequence, for example, step 412 is executed first, or step 413 is executed first, or they can be executed simultaneously.

[0156] In the foregoing embodiments, the interaction between the main node and the slave node is introduced. Next, the introduction will be made from the perspectives of the main node and the slave node respectively.

[0157] See Figure 6A As shown, it is a schematic flowchart of a method for switching the main node of a blockchain cluster provided by an embodiment of the present application. This method can be executed by the main node or by the consensus module in the main node. It should be noted that the main node in the blockchain cluster will change, so the main node here is not limited to a fixed node, but refers to the main node in the current term. This method can be compatible with the existing execution logic of the blockchain, or it can be understood that the execution logic of this method is added to the existing execution logic of the blockchain. This method may include the following steps:

[0158] Step 601: Verify and submit a block. See Figure 6B As shown, the main node initiates a block proposal. After consensus is reached through the consensus algorithm deployed on the blockchain, the block can be submitted to the chain.

[0159] Step 602: Determine whether the term goal of the current term is completed. See Figure 6B As shown, whether the block height after the submission of step 601 reaches the main node switching condition of the current term, that is, whether the block height is greater than or equal to the upper limit value of the block height range to be consensus-completed within this term. If the block height reaches the main node switching condition, then

[0160] If the result of step 602 is no, the main node switching condition is not triggered, and the current main node continues to be the main node in the N-th term and continues to perform the duties of the main node.

[0161] Step 603: If the result of step 602 is yes, notify the proposer module to stop proposing.

[0162] Step 604: Obtain the total number of blocks of all slave nodes from the status engine, which is the current block height.

[0163] Step 605: According to the total number of blocks, select M candidate nodes with normal connection status and the same total number of blocks as the master node to form a candidate node list, which serves as the alternative node list for the master node switch in this term. Refer to Figure 6B As shown, if the block height reaches the master-switching condition, eligible slave nodes can be selected to form a candidate node list.

[0164] Step 606: Check whether the candidate node list is empty, or equivalently, whether the length of the candidate node list is zero.

[0165] Step 607: If the result of step 602 is yes, indicating that no slave node can be selected as a candidate node, i.e., M is zero and the master node cannot be successfully switched this time, then this node continues to be the master node, and it can notify the proposer module to start proposing.

[0166] Step 608: Record the log that the master node switch fails this time, and record the reason for this failure, such as that no target node meeting the master-switching condition can be found.

[0167] Step 609: If the result of step 602 is no, record the master-switching situation in the cache. For example, the current term identifier, the candidate node list, and the current node status, i.e., the master-switching policy is being executed, can be recorded.

[0168] Step 610: Call the interface of the blockchain engine (such as the raft engine), and initiate the master-switching process with the first candidate node in the candidate node list as the target node. For example, if the starting serial number of the candidate nodes in the candidate node list is 0, then initiate the master-switching process with the 0th candidate node as the target node. Refer to Figure 6B As shown, if the number of nodes M included in the candidate node list is not 0, then initiate the master-switching process starting from the first node.

[0169] In the embodiments of this application, the master-switching process is an asynchronous process. After initiating the master-switching, the master node only needs to forward network messages to the blockchain engine and then wait for the master-switching result notified by the blockchain engine.

[0170] For the blockchain engine, after being called, the election process in the blockchain cluster can be triggered. Refer to Figure 7 As shown, it is another process schematic diagram of the master node switching method for the blockchain cluster provided by the embodiments of this application. This method can be executed by the master node and the slave nodes, or can be executed by the blockchain engines in the master node and the slave nodes. This method includes the following steps:

[0171] Step 701: The master node (blockchain engine) sends an election instruction to the candidate node to instruct the candidate node to initiate the election process. Correspondingly, the candidate node receives the election instruction from the master node.

[0172] For example, the blockchain engine can call the network module through the consensus module to send the election instruction to the candidate node.

[0173] Step 702: The candidate node (blockchain engine) broadcasts an election request in the blockchain cluster to request to become the master node in the (N + 1)-th term.

[0174] For example, after generating the election request, the blockchain engine can send the election request to the consensus module, and the consensus module broadcasts the election request to other nodes in the blockchain cluster through the network module.

[0175] Step 703: The candidate node (blockchain engine) receives the voting results from each node, including the voting results from the master node and other slave nodes.

[0176] For example, after the network module of the candidate node receives the voting results, it sends the voting results to the consensus module, and the consensus module sends the voting results to the blockchain engine.

[0177] Step 704: The candidate node (blockchain engine) tallies the voting results.

[0178] Step 705: The candidate node (blockchain engine) determines the master node elected in the (N + 1)-th term.

[0179] Step 706: The candidate node (blockchain engine) broadcasts feedback information in the blockchain cluster to indicate that it has been elected as the master node in the (N + 1)-th term.

[0180] For example, the blockchain engine sends the feedback information to the consensus module, and the consensus module broadcasts the feedback information to other nodes in the blockchain cluster through the network module. Correspondingly, the master node and other slave nodes (blockchain engine) can receive the feedback information from the candidate node.

[0181] After the master node receives the feedback information, it can determine that the candidate node has been successfully elected as the master node in the (N + 1)-th term according to the feedback information. See Figure 8A As shown, it is another flowchart of the master node switching method for the blockchain cluster provided by the embodiment of the present application. This method can be executed by the master node or by the consensus module of the master node. The method includes the following steps:

[0182] Step 801: Receive the response message (i.e., feedback information or information containing feedback information) from the blockchain engine.

[0183] Step 802: Determine whether the current node status is in the process of executing the master change strategy. If it is not in the process of executing the master change strategy, the master node executes according to the original logic.

[0184] Step 803: If the judgment result of Step 802 is yes, determine whether a new term has been entered and generate a new master node.

[0185] For example, the response message returned by the blockchain engine can carry whether the candidate node has been successfully elected as the master node, so it can be determined whether the response message has successfully entered the (N + 1)-th term. In practical applications, when the candidate node is successfully elected as the master node of the (N + 1)-th term, the candidate node can broadcast in the blockchain cluster to notify the blockchain nodes that it has been successfully elected as the master node of the (N + 1)-th term.

[0186] Step 804: If the result of Step 803 is yes, indicating that a new master node has been elected and the master node switch is successful this time, the master change information involved in this master change process stored in the memory can be cleared, the type of the local node can be marked as a slave node, and the current status can be changed to the normal status, that is, not executing the master change strategy.

[0187] Step 805: Record the log that the master change is successful this time, record the new term identifier, that is, the (N + 1)-th term, and record the master node ID. And this node can continue to execute according to the original logic.

[0188] Step 806: If the result of Step 803 is no, determine whether the master change process times out. If it has timed out, the master change fails this time, and this node can continue to execute according to the original logic.

[0189] Step 807: If the master change process has not timed out yet, read the master change information of the current term from the memory.

[0190] Step 808: Determine whether there are subsequent candidate nodes in the candidate node list. If not, indicating that none of the M candidate nodes have been successfully elected, jump to Step 811 for execution.

[0191] Step 809: Call the blockchain engine interface to initiate the master change process with the next candidate node in the candidate node list as the target node. For example, if the starting serial number of the previously selected candidate node is 0, then initiate the master change process with the first candidate node as the target node this time.

[0192] Step 810: Update the master change information of the current term recorded in the cache, such as updating the current target node, that is, the next node after the previous master change failure, and the start time of this master change, etc.

[0193] Step 811: If the result of step 808 is negative, indicating that none of the candidate nodes have been successfully elected, then this node continues to be the primary node, that is, it can notify the proposer module to start proposing.

[0194] Step 812: Record the log that the primary node switch fails this time, and record the reason for this failure, such as that no target node meeting the primary node switch condition can be found.

[0195] See Figure 8B As shown, for an example of the primary node switch process, the primary node can start from the first candidate node, that is, initiate the primary node switch process to candidate node 1 and wait for the primary node switch result of candidate node 1. If the primary node switch is successful, candidate node 1 becomes the primary node. If the primary node switch fails, then continue to initiate the primary node switch process to the next candidate node, that is, candidate node 2, and wait for the primary node switch result of candidate node 2. If the primary node switch is successful, candidate node 2 becomes the primary node. If the primary node switch fails, then continue to initiate the primary node switch process to the next candidate node, that is, candidate node 3, and so on, until the primary node switch is successful or there are no optional candidate nodes.

[0196] In the embodiments of the present application, through the above-mentioned active primary node switch process, the primary node can actively step down to be a secondary node, avoiding a single node serving as the primary node for a long time, reducing the possibility of the primary node acting maliciously, and improving the reliability of the blockchain.

[0197] See Figure 9 As shown, it is another schematic flowchart of the primary node switch method for the blockchain cluster provided by the embodiments of the present application. This method can be executed by a secondary node or by a consensus module in the secondary node. The following process is introduced from the perspective of the target secondary node that is used as a candidate node. For secondary nodes that are not used as candidate nodes, in the primary node switch stage, their main role is to vote for the election process initiated by the candidate node. This method can be compatible with the existing execution logic of the blockchain, or it can be understood that the execution logic of this method is added to the existing execution logic of the blockchain. The following method process can be executed after the Figure 7 embodiment shown, and this method may include the following steps:

[0198] Step 901: Receive a response message (i.e., feedback information or information containing feedback information) from the blockchain engine.

[0199] Step 902: Determine whether a new term has been entered and a new primary node has been generated.

[0200] For example, the response message returned by the blockchain engine may carry whether the candidate node has successfully been elected as the primary node, and thus it is possible to determine whether the response message has successfully entered the (N+1)-th term. In practical applications, after the candidate node has successfully been elected as the primary node of the (N+1)-th term, the candidate node may broadcast in the blockchain cluster to notify the blockchain nodes that it has successfully been elected as the primary node of the (N+1)-th term. Correspondingly, the blockchain engines of other nodes may receive this information.

[0201] Step 903: If the result of step 902 is yes, the master change information involved in the current master change process stored in the memory may be cleared, the type of the local node may be marked as the primary node, and the current status may be changed to the normal state, that is, the master change policy is not being executed.

[0202] Step 904: If itself is elected as the primary node, the proposer module of itself may be notified to start proposing.

[0203] Step 905: Record a log that itself has been elected as the primary node, and record the new term and the block height at the start of this term.

[0204] Through the above process, the primary node can actively change the master to change the primary node to a slave node that meets the preset conditions, thereby avoiding a single node serving as the primary node for a long time, reducing the possibility of the primary node acting maliciously, and improving the reliability of the blockchain. After the slave node is changed to the primary node, it can also execute according to the original logic of the blockchain cluster.

[0205] In the embodiments of the present application, when the blockchain cluster is initialized, after the consensus module in the primary node or the slave node is started, the consensus module may start the blockchain engine (such as the raft engine). Correspondingly, the blockchain engine is started. For each node, an election request may be initiated, and the election request is broadcast through the network module called by the consensus module. If a node is elected as the primary node, the consensus module will be notified that it has successfully been elected as the primary node. Furthermore, the consensus module of the primary node will notify the proposer module to start packing blocks. Also, after the slave node is elected as the primary node of the (N+1)-th term, it can also perform the duties of the primary node, that is, it can initiate a new block proposal.

[0206] Specifically, the primary node may initiate a new block proposal, encapsulate log entries based on the block proposal to obtain target log entries, and broadcast the target log entries in the blockchain cluster. When the number of slave nodes that have successfully received the target log entries meets the consensus condition, a consensus indication is broadcast. The consensus indication is used to indicate that the corresponding slave nodes perform consensus on the block proposal. See Figure 10AAs shown, between the master node and any slave node, the consensus and chain - up of blocks can be divided into two stages. The master node broadcasts the first - stage consensus message to each slave node, sending the target log entries to be consensus - ed to the slave nodes. After the slave nodes cache them, they send the first - stage response message to the master node. When the master node receives enough first - stage response messages, the master node broadcasts the second - stage consensus message to each slave node, indicating that everyone can verify and chain - up the target log entries.

[0207] Exemplarily, refer to Figure 10B As shown, it is a schematic flow diagram of the process of the master node (which can be the Nth or the (N + 1)th) for block chain - up.

[0208] Step 1001: The consensus module notifies the proposer module to start packing blocks.

[0209] Step 1002: The proposer module packs the block, that is, initiates a new block.

[0210] Step 1003: The proposer module sends the new block to the consensus module.

[0211] Step 1004: The consensus module encapsulates the block into a consensus proposal, that is, initiates a new block proposal.

[0212] Step 1005: The consensus module performs log entry encapsulation based on the block proposal to obtain the target log entries. For example, the consensus module encapsulates the consensus proposal into raft log entries.

[0213] Step 1006: The consensus module calls the blockchain engine interface and sends the target log entries to the blockchain engine for processing. Correspondingly, the blockchain engine receives the target log entries of the new proposal.

[0214] Step 1007: The blockchain engine puts the target log entries into the local cache and generates the first - stage consensus message, which can carry the target log entries.

[0215] Step 1008: The blockchain engine sends the first - stage consensus message to the consensus module. Correspondingly, the consensus module receives the first - stage consensus message from the local blockchain engine.

[0216] Step 1009: The consensus module saves the target log entries to a temporary cache file, such as a wal file.

[0217] Step 1010: The consensus module broadcasts the first - stage consensus message through the network module.

[0218] Step 1011: The consensus module receives the first - stage response message from the slave node through the network module.

[0219] Step 1012: The consensus module sends the first-phase response message to the blockchain engine.

[0220] Step 1013: The blockchain engine counts the received first-phase response messages.

[0221] Step 1014: If the blockchain engine receives the first-phase response messages from a majority of slave nodes, it generates a second-phase consensus message, which instructs the slave nodes to reach a consensus on the block proposal.

[0222] Step 1015: The blockchain engine sends the second-phase consensus message to the consensus module.

[0223] Step 1016: The consensus module parses the block information in the message, validates and submits the block.

[0224] Step 1017: The consensus module broadcasts the second-phase consensus message through the network module.

[0225] So far, the processing of a block proposal is completed, and then the block proposal and the above processing are repeated.

[0226] Exemplarily, see Figure 11 As shown, it is a flow diagram of the process of a slave node (which can be the Nth or the (N + 1)th) for the block to be chained to the blockchain.

[0227] Step 1101: The blockchain engine receives the first-phase consensus message from the master node. For a slave node, after initialization, if it receives the first-phase consensus message from the master node, it can determine that another node has been elected as the master node, and it itself retreats to a slave node and notifies the consensus module.

[0228] Step 1102: The blockchain engine sends the first-phase consensus message to the consensus module.

[0229] Step 1103: The consensus module parses the first-phase consensus message and saves the target log entry to a temporary cache file, such as a wal file.

[0230] Step 1104: After the consensus module finishes caching the target log entry, it notifies the blockchain engine that the target log entry has been successfully cached.

[0231] Step 1105: The blockchain engine generates a first-phase response message to be sent to the master node.

[0232] Step 1106: The blockchain engine sends the first-phase response message to the consensus module.

[0233] Step 1107: The consensus module sends the first-phase response message to the master node through the network module.

[0234] Step 1108: The consensus module receives, through the network module, a second-phase consensus message from the primary node, indicating that block consensus can start.

[0235] Step 1109: The consensus module sends the second-phase consensus message to the blockchain engine.

[0236] Step 1110: The blockchain engine sorts out the target log entries to be committed from the memory.

[0237] Step 1111: The blockchain engine returns the target log entries to the consensus module.

[0238] Step 1112: The consensus module parses the block information from the target log entries.

[0239] Step 1113: The consensus module validates and commits the block.

[0240] Thus, the verification and submission of a block are completed, and the above processing is repeated subsequently.

[0241] In the embodiments of the present application, a solution for the primary node to actively change leadership is proposed. Through this solution, blockchain clusters such as the raft consensus algorithm can, under the configuration of users, actively change the primary node to other nodes after each proposal completes a block within a specified height range, thereby shielding the risks existing in not changing the primary node for a long time and avoiding, to a certain extent, the negative impact on the blockchain caused by the primary node acting maliciously. This method can be implemented at the code level to optimize the underlying code of the blockchain.

[0242] Moreover, through the method of the embodiments of the present application, it is also easier to confirm whether the primary node is a malicious node. Because when the blockchain cluster validates and commits a block, there are requirements for the continuity of the block information. If the current block to be verified or committed conflicts with the previous block, or the current global state information of the blockchain after the previous block is committed and cannot be self-consistent, then the verification or submission of the block will fail. The node where the verification or submission of the block fails will suspend the consensus process and repeatedly verify the current block until the current block is successfully verified or manual intervention is carried out. Therefore, once the primary node acts maliciously, it will tamper with the data sent to some slave nodes, resulting in inconsistent data among the slave nodes and the blockchain fork phenomenon. Only when the primary node can continuously tamper with each block sent to the slave nodes can it ensure the data consistency of the slave nodes before and after and be able to pass the verification and commit the block.

[0243] Through the method of the embodiments of the present application, after the primary node actively changes the leadership, if the new primary node does not act maliciously, then the nodes that were previously inconsistent with the data of the new primary node will suspend the consensus process because they cannot process the proposals sent by the primary node. If the number of nodes that suspend the consensus process exceeds half, the entire blockchain cluster will stop working and will no longer be able to process transactions until manual intervention. Or, if there is an obvious abnormal pattern in the order of primary node leadership changes, such as only changing the primary node for certain nodes, it is also very easy for the operation and maintenance personnel to discover.

[0244] Therefore, in the embodiments of the present application, after switching the role state of the target slave node to the primary node state, if it is determined that the following conditions are met, it can be determined that the primary node in the Nth term is a malicious node, or the probability that the primary node in the Nth term is a malicious node is relatively high:

[0245] (1) In the (N + 1)th term, the blockchain corresponding to at least one node includes multiple branches, that is, there is a fork phenomenon in the blockchain.

[0246] (2) In the (N + 1)th term, the block proposal newly initiated by the target slave node is incompatible with the block proposal in the Nth term. For example, the block information of a certain node is inconsistent with the block information initiated by the new primary node, such as the block sequence number is inconsistent.

[0247] (3) In the (N + 1)th term, the number of nodes that stop executing the consensus process is greater than or equal to a preset number threshold, such as exceeding half of the total number of nodes.

[0248] Of course, other arbitrary possible conditions can also be included, and the embodiments of the present application do not limit this.

[0249] It can be seen that in the embodiments of the present application, by adopting the method of the primary node actively changing the leadership, the malicious behavior of the primary node can be discovered in a timely manner to a certain extent, thereby reducing the possibility of the primary node acting maliciously and improving the reliability and security of the blockchain.

[0250] Please refer to Figure 12 , based on the same inventive concept, the embodiments of the present application also provide a primary node switching device 120 for a blockchain cluster. The device is applied to the primary node included in the blockchain cluster, and the blockchain cluster further includes multiple slave nodes. The device includes:

[0251] A determination unit 1201, configured to determine, according to the tenure information associated with the primary node, that the primary node has completed the task target in the Nth term. The tenure information is used to indicate that the primary node is the primary node in the Nth term and the task target to be completed in the Nth term, where N is an integer;

[0252] A node selection unit 1202, configured to determine M candidate nodes that meet a preset condition from multiple slave nodes according to the total number of blocks included in the blockchains respectively corresponding to the multiple slave nodes, where the preset condition includes: the total number of blocks corresponding to a slave node is greater than or equal to the total number of blocks corresponding to the master node, and M is an integer;

[0253] A notification unit 1203, configured to, if M is not zero, send an election instruction to each candidate node respectively, where the election instruction is used to notify the corresponding candidate node to initiate an election process for the master node in the (N + 1)-th term;

[0254] A status switching unit 1204, configured to, if it is determined based on the received feedback messages that a target candidate node among the M candidate nodes is successfully elected as the master node in the (N + 1)-th term, switch the role status of the master node to the slave node status, where the feedback messages are used to indicate the election results of the election processes initiated by the corresponding candidate nodes.

[0255] In a possible implementation manner, the determination unit 1201 is specifically configured to:

[0256] If the task target indicates the number of target blocks to be newly added to the blockchain corresponding to the master node, in the N-th term, when the actual number of blocks newly added to the blockchain corresponding to the master node is greater than or equal to the number of target blocks, it is determined that the master node has completed the task target of the N-th term; or,

[0257] If the task target indicates the target tenure duration, when the actual tenure duration of the master node is greater than or equal to the target tenure duration, it is determined that the master node has completed the task target of the N-th term.

[0258] In a possible implementation manner, the node selection unit 1202 is specifically configured to:

[0259] Obtain the total number of blocks respectively corresponding to multiple slave nodes cached in the master node;

[0260] When it is determined according to the obtained total number of blocks that the number of candidate nodes meeting the preset condition is zero, send a block number acquisition request to multiple slave nodes respectively;

[0261] Determine M candidate nodes from multiple slave nodes according to the total number of blocks respectively fed back by the multiple slave nodes in response to the block number acquisition request.

[0262] In a possible implementation manner, the notification unit 1203 is specifically configured to:

[0263] Determine one candidate node from the remaining candidate nodes of the M candidate nodes, and send an election instruction to the one candidate node;

[0264] If the one candidate node is successfully elected as the primary node for the (N + 1)-th term, or if the number of remaining candidate nodes is zero, stop the iteration;

[0265] If the one candidate node fails to be successfully elected as the primary node for the (N + 1)-th term, then enter the next primary node switching process.

[0266] In a possible implementation manner, the determining unit 1201 is specifically configured to:

[0267] Based on the fact that the primary node has completed the task objective, stop initiating new block proposals;

[0268] After determining M candidate nodes that meet the preset conditions from multiple slave nodes according to the total number of blocks included in the blockchains respectively corresponding to the multiple slave nodes, if M is zero or none of the M candidate nodes is successfully elected as the primary node for the (N + 1)-th term, then determine that the primary node continues to be the primary node and continue to initiate new block proposals.

[0269] In a possible implementation manner, the notification unit 1203 is further configured to:

[0270] Receive an election request sent by a target candidate node, where the election request is used to indicate that the target candidate node requests to become the primary node for the (N + 1)-th term;

[0271] In response to the election request, vote for the target candidate node, obtain a voting result, and return the voting result to the target candidate node;

[0272] Receive feedback information sent by the target candidate node, where the feedback information is sent when the target candidate node determines that it is successfully elected as the primary node for the (N + 1)-th term according to the received voting results.

[0273] In a possible implementation manner, the device further includes a storage unit 1205, which is used for:

[0274] If the target candidate node is successfully elected as the primary node for the (N + 1)-th term, then obtain a first result log according to the device identifier and term identifier of the target candidate node, and store the first result log;

[0275] If the primary node continues to be the primary node, then obtain a second result log according to the reason for the failure of the primary node switch, and store the second result log.

[0276] This device can be used to execute the method performed by the primary node in various embodiments of the present application. Therefore, for the functions that can be realized by each functional module of this device, reference can be made to the description of the foregoing embodiments, and details are not described herein again.

[0277] Please refer to Figure 13, Based on the same inventive concept, an embodiment of the present application further provides a main node switching device 130 for a blockchain cluster. This device is applied to a target slave node included in the blockchain cluster. The blockchain cluster includes a main node and multiple slave nodes, and the total number of blocks in the blockchain corresponding to the target slave node is greater than or equal to the total number of blocks in the blockchain corresponding to the main node. The device includes:

[0278] A receiving unit 1301, configured to receive an election instruction sent by the main node. The election instruction is sent by the main node after determining that the task objective of the Nth term has been completed according to the associated tenure information. The election instruction is used to notify the target slave node to initiate the election process for the main node of the (N + 1)th term. The tenure information is used to indicate that the main node is the main node of the Nth term and the task objective to be completed during the Nth term. N is an integer.

[0279] A sending unit 1302, configured to broadcast an election request based on the election instruction to enter the election process. The election request indicates that the target slave node requests to become the main node of the (N + 1)th term. And, when it is determined that the target slave node has been successfully elected as the main node of the (N + 1)th term according to the received voting results for the election process, broadcast feedback information. Wherein, the voting results are used to indicate acceptance or rejection of the target slave node becoming the main node of the (N + 1)th term, and the feedback information is used to indicate that the target slave node has been successfully elected as the main node of the (N + 1)th term.

[0280] A status switching unit 1303, configured to switch the role status of the target slave node to the main node status.

[0281] In a possible implementation manner, the device further includes a block processing unit 1304, configured to:

[0282] Initiate a new block proposal, and perform log entry encapsulation based on the block proposal to obtain a target log entry.

[0283] Broadcast the target log entry.

[0284] When the number of slave nodes that have successfully received the target log entry meets the consensus condition, broadcast a consensus instruction. The consensus instruction is used to indicate that the corresponding slave nodes perform consensus on the block proposal.

[0285] In a possible implementation manner, the device further includes a determination unit 1305, configured to:

[0286] When it is determined that the following conditions are met, determine that the main node of the Nth term is a malicious node:

[0287] During the (N + 1)th term, at least one node's corresponding blockchain includes multiple branches.

[0288] During the (N + 1)-th term, the block proposals newly initiated by the target slave node are incompatible with the block proposals during the N-th term;

[0289] During the (N + 1)-th term, the number of nodes that stop executing the consensus process is greater than or equal to a preset number threshold.

[0290] This device can be used to execute the methods performed by the slave nodes in the embodiments of the present application. Therefore, for the functions that can be realized by each functional module of this device, reference can be made to the descriptions of the foregoing embodiments, and details will not be repeated.

[0291] It should be noted that Figure 12 and Figure 13 the dotted lines in represent optional functional units.

[0292] Through the above device, it is possible to prevent a single node from acting as the master node for a long time, reduce the probability of the situation where the master node has abnormal behavior and other slave nodes cannot detect this abnormal behavior, and improve the reliability of the blockchain. It forms a constraint on the behavior of the master node, reduces the possibility of the master node having abnormal behavior, and ultimately improves the reliability of the blockchain.

[0293] Please refer to Figure 14 , based on the same technical concept, the embodiments of the present application also provide a computer device. In one embodiment, the computer device may be, for example, Figure 1 the blockchain node shown in, and the computer device is as shown in Figure 14 , including a memory 1401, a communication module 1403, and one or more processors 1402.

[0294] The memory 1401 is used to store the computer program executed by the processor 1402. The memory 1401 may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system and programs required to run the functions of the embodiments of the present application; the data storage area may store various function information and operation instruction sets, etc.

[0295] The memory 1401 can be a volatile memory, such as a random-access memory (RAM); the memory 1401 can also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or the memory 1401 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1401 can be a combination of the above memories.

[0296] The processor 1402 can include one or more central processing units (CPUs) or be a digital processing unit, etc. The processor 1402 is used to implement the master node switching method of the above blockchain cluster when calling the computer program stored in the memory 1401.

[0297] The communication module 1403 is used to communicate with terminal devices and other servers.

[0298] In the embodiments of the present application, the specific connection medium between the above memory 1401, communication module 1403, and processor 1402 is not limited. In the embodiments of the present application Figure 14 it is described that the memory 1401 and the processor 1402 are connected through a bus 1404. The bus 1404 is described in thick lines in Figure 14 The connection manners between other components are only for illustrative purposes and are not to be taken as limiting. The bus 1404 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Figure 14 only one thick line is used to describe it in

[0299] The memory 1401 stores a computer storage medium, and the computer storage medium stores computer-executable instructions. The computer-executable instructions are used to implement the master node switching method of the blockchain cluster in the embodiments of the present application. The processor 1402 is used to execute the master node switching methods of the above various embodiments.

[0300] Based on the same inventive concept, the embodiments of the present application also provide a computer storage medium. The computer storage medium stores a computer program. When the computer program runs on a computer device, it causes the computer device to execute the steps in the master node switching method of the blockchain cluster according to various exemplary embodiments of the present application described above in this specification.

[0301] In some possible embodiments, various aspects of the method for switching the master node of the blockchain cluster provided in this application can also be implemented in the form of a computer program product, which includes a computer program. When the computer program product runs on a computer device, the computer program is used to cause the computer device to execute the steps in the method for switching the master node of the blockchain cluster according to various exemplary embodiments of this application described above in this specification. For example, the computer device can execute the steps of each embodiment.

[0302] The computer program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0303] The computer program product of the embodiments of this application can adopt a portable compact disk read-only memory (CD-ROM) and include a computer program, and can run on a computer device. However, the computer program product of this application is not limited to this. In this application, the readable storage medium can be any tangible medium that contains or stores a program, and the computer program included therein can be used by or in combination with a command execution system, apparatus, or device.

[0304] The readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries the readable computer program. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable signal medium can also be any readable medium other than the readable storage medium, and this readable medium can send, propagate, or transmit a program for use by or in combination with a command execution system, apparatus, or device.

[0305] The computer program included on the readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0306] The computer program for performing the operations of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and also including conventional procedural programming languages such as the "C" language or similar programming languages.

[0307] It should be noted that although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of the two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0308] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.

[0309] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer programs.

[0310] Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications once they learn the basic creative concepts. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications falling within the scope of the present application.

[0311] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these changes and modifications.

Claims

1. A method for switching the primary node of a blockchain cluster, characterized in that, Applied to the master node included in the blockchain cluster, the blockchain cluster further includes a plurality of slave nodes, and the method includes: Determine that the master node has completed the task objective of the Nth term according to the term information associated with the master node, where the term information is used to indicate that the master node is the master node of the Nth term and the task objective to be completed within the Nth term, and N is an integer; Determine M candidate nodes that meet the preset conditions from the plurality of slave nodes according to the total number of blocks included in the blockchains corresponding to the plurality of slave nodes respectively, where the preset conditions include that the total number of blocks corresponding to the slave node is greater than or equal to the total number of blocks corresponding to the master node, and M is an integer; If M is not zero, send an election instruction to each candidate node respectively, where the election instruction is used to notify the corresponding candidate node to initiate the election process of the master node of the (N + 1)th term; If it is determined that the target candidate node among the M candidate nodes is successfully elected as the master node of the (N + 1)th term based on the received feedback information, switch the role status of the master node to the slave node status, where the feedback information is used to indicate the election result of the election process initiated by the corresponding candidate node.

2. The method according to claim 1, characterized in that, The determining that the master node has completed the task objective of the Nth term according to the term information associated with the master node includes: If the task objective indicates the number of target blocks to be newly added in the blockchain corresponding to the master node, within the Nth term, when the actual number of newly added blocks in the blockchain corresponding to the master node is greater than or equal to the number of target blocks, determine that the master node has completed the task objective of the Nth term; or, If the task objective indicates the target term duration, when the actual term duration of the master node is greater than or equal to the target term duration, determine that the master node has completed the task objective of the Nth term.

3. The method according to claim 1, characterized in that Before determining M candidate nodes that meet the preset conditions from the plurality of slave nodes according to the total number of blocks included in the blockchains corresponding to the plurality of slave nodes respectively, the method further includes: Obtain the total number of blocks corresponding to the plurality of slave nodes cached in the master node; When it is determined that the number of candidate nodes that meet the preset conditions is zero according to the obtained total number of blocks, send a block number acquisition request to the plurality of slave nodes respectively; Then the determining M candidate nodes that meet the preset conditions from the plurality of slave nodes according to the total number of blocks included in the blockchains corresponding to the plurality of slave nodes respectively includes: Determine the M candidate nodes from the plurality of slave nodes according to the total number of blocks fed back by the plurality of slave nodes respectively for the block number acquisition request.

4. The method according to any one of claims 1 to 3, characterized in that The sending an election instruction to each candidate node respectively includes: Iteratively execute the master node switching process, and in each master node switching process, perform the following steps: Determine a candidate node from the remaining candidate nodes of the M candidate nodes, and send the election instruction to the one candidate node; If the one candidate node is successfully elected as the master node of the (N + 1)th term, or the number of remaining candidate nodes is zero, stop the iteration; If the one candidate node fails to be successfully elected as the primary node for the (N + 1)-th term, enter the next primary node switching process.

5. The method according to claim 4, wherein After determining, according to the term information associated with the primary node, that the primary node has completed the task objectives for the N-th term, the method further includes: Based on the fact that the primary node has completed the task objectives, stop initiating new block proposals; Then, after determining, according to the total number of blocks included in the blockchains respectively corresponding to the multiple slave nodes, M candidate nodes that meet the preset conditions from the multiple slave nodes, the method further includes: If M is zero or none of the M candidate nodes is successfully elected as the primary node for the (N + 1)-th term, determine that the primary node continues to be the primary node and continue to initiate new block proposals.

6. The method according to any one of claims 1 to 3, characterized in that, After respectively sending election instructions to each candidate node, the method further includes: Receive an election request sent by the target candidate node, where the election request is used to indicate that the target candidate node requests to become the primary node for the (N + 1)-th term; In response to the election request, vote on the target candidate node, obtain a voting result, and return the voting result to the target candidate node; Receive feedback information sent by the target candidate node, where the feedback information is sent when the target candidate node determines that it is successfully elected as the primary node for the (N + 1)-th term according to the received voting results.

7. The method according to any one of claims 1 to 3, characterized in that After respectively sending election instructions to each candidate node, the method further includes: If the target candidate node is successfully elected as the primary node for the (N + 1)-th term, obtain a first result log according to the device identifier and term identifier of the target candidate node, and store the first result log; If the primary node continues to be the primary node, obtain a second result log according to the reason for the failure of the primary node switch, and store the second result log.

8. A method for switching the primary node of a blockchain cluster, characterized in that, Applied to a target slave node included in the blockchain cluster, the blockchain cluster includes a primary node and multiple slave nodes, and the total number of blocks in the blockchain corresponding to the target slave node is greater than or equal to the total number of blocks in the blockchain corresponding to the primary node; the method includes: Receive an election instruction sent by the primary node, where the election instruction is sent by the primary node after determining, according to the associated term information, that it has completed the task objectives for the N-th term, and the election instruction is used to notify the target slave node to initiate the election process for the primary node of the (N + 1)-th term, and the term information is used to indicate that the primary node is the primary node for the N-th term and the task objectives to be completed during the N-th term, and N is an integer; Based on the election instruction, broadcast an election request to enter the election process, where the election request indicates that the target slave node requests to become the primary node for the (N + 1)-th term; When determining that the target slave node is successfully elected as the master node in the (N + 1)-th term according to the received voting results for the election process, broadcast feedback information; wherein, the voting results are used to indicate acceptance or rejection of the target slave node becoming the master node in the (N + 1)-th term, and the feedback information is used to indicate that the target slave node is successfully elected as the master node in the (N + 1)-th term. Switch the role status of the target slave node to the master node status.

9. The method according to claim 8, wherein After the role status of the target slave node is switched to the master node status, the method further includes: Initiate a new block proposal, and encapsulate log entries based on the block proposal to obtain target log entries. Broadcast the target log entries. When the number of slave nodes that have successfully received the target log entries meets the consensus condition, broadcast a consensus indication, and the consensus indication is used to indicate that the corresponding slave nodes conduct consensus on the block proposal.

10. The method according to claim 8 or 9, characterized in that, After the role status of the target slave node is switched to the master node status, the method further includes: When determining that the following conditions are met, determine that the master node in the N-th term is a malicious node: In the (N + 1)-th term, the blockchain corresponding to at least one node includes multiple branches. In the (N + 1)-th term, the new block proposal initiated by the target slave node is incompatible with the block proposal in the N-th term. In the (N + 1)-th term, the number of nodes that stop executing the consensus process is greater than or equal to a preset number threshold.

11. A master node switching device for a blockchain cluster, characterized in that, Applied to the master node included in the blockchain cluster, the blockchain cluster further includes multiple slave nodes, and the device includes: A determination unit, configured to determine that the master node has completed the task objective in the N-th term according to the term information associated with the master node, and the term information is used to indicate that the master node is the master node in the N-th term and the task objective to be completed in the N-th term, where N is an integer. A node selection unit, configured to determine M candidate nodes that meet the preset conditions from the multiple slave nodes according to the total number of blocks included in the blockchains corresponding to the multiple slave nodes respectively, and the preset conditions include that the total number of blocks corresponding to the slave node is greater than or equal to the total number of blocks corresponding to the master node, and M is an integer. A notification unit, configured to, if M is not zero, send election instructions to each candidate node respectively, and the election instructions are used to notify the corresponding candidate nodes to initiate the election process for the master node in the (N + 1)-th term. A status switching unit, configured to, if it is determined based on the received feedback information that the target candidate node among the M candidate nodes is successfully elected as the master node in the (N + 1)-th term, switch the role status of the master node to the slave node status.

12. A master node switching device for a blockchain cluster, characterized in that, Applied to the target slave node included in the blockchain cluster, the blockchain cluster includes a master node and multiple slave nodes, and the total number of blocks in the blockchain corresponding to the target slave node is greater than or equal to the total number of blocks in the blockchain corresponding to the master node; the device includes: A receiving unit, configured to receive the election instruction sent by the master node, where the election instruction is sent by the master node after determining that the task objective of the Nth term has been completed according to the associated term information, and the election instruction is used to notify the target slave node to initiate the election process of the master node for the (N + 1)th term. The term information is used to indicate that the master node is the master node of the Nth term and the task objective to be completed during the Nth term, and N is an integer; A sending unit, configured to broadcast an election request based on the election instruction, where the election request indicates that the target slave node requests to become the master node for the (N + 1)th term; and, when determining that the target slave node is successfully elected as the master node for the (N + 1)th term according to the received voting results, broadcast feedback information, where the feedback information is used to indicate that the target slave node is successfully elected as the master node for the (N + 1)th term; A status switching unit, configured to switch the role status of the target slave node to the master node status.

13. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 or 8 to 10 are implemented.

14. A computer storage medium, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 or 8 to 10 are implemented.

15. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 or 8 to 10 are implemented.

Images