Blockchain Consensus Method and Computer-Readable Storage Medium

Abstract

The present invention provides a blockchain consensus method and computer-readable storage medium, wherein the blockchain consensus method includes: determining multiple consensus nodes from authorized nodes through POA election; determining a PBFT master node from the multiple consensus nodes using a preset priority algorithm, and designating the remaining consensus nodes as PBFT verification nodes; performing PBFT consensus operations using the PBFT master node and PBFT verification nodes; and, if consensus is reached, broadcasting the consensus result to all nodes in the blockchain to synchronize the ledger status and form a new block. The solution of the present invention combines the Byzantine fault-tolerant consensus mechanism of PBFT master-slave nodes with the consensus of POA, avoiding malicious attacks caused by the severe centralization of the POA consensus mechanism.

Description

Technical Field

[0001] The present invention relates to network information technology, and in particular to a blockchain consensus method and a computer-readable storage medium. Background Art

[0002] POA (Proof of Authority) is a mechanism where a group of authorized nodes are responsible for generating and verifying new blocks. Authorized nodes are sorted in ascending order by their addresses and then take turns obtaining the right to record the account. POA nodes include regular nodes and authorized nodes (signers). Regular nodes do not have the right to generate blocks. Authorized nodes are responsible for generating blocks.

[0003] The authorized nodes that perform ledger operations are called masternodes (or miners). During the block generation process, masternodes serve as the central authority on the network, and other nodes cannot monitor their behavior. A malicious attack by a masternode against the network is highly likely to succeed. Furthermore, because consortium chains perform identity authentication, the information of validating nodes is public, making them vulnerable to external network attacks, resulting in single points of failure or the Byzantine problem.

[0004] Therefore, as a consensus mechanism with obvious centralization, POA lacks security against malicious attacks, and the security risks brought about by centralization need to be addressed. Summary of the Invention

[0005] An object of the present invention is to provide a method for improving the security of blockchain consensus.

[0006] A further purpose of the present invention is to combine the PBFT consensus to weaken the power of the central node and avoid malicious attacks from the central node.

[0007] According to one aspect of the present invention, a blockchain consensus method is provided, comprising:

[0008] Determine multiple consensus nodes from authorized nodes through POA election;

[0009] Use the preset priority algorithm to determine the PBFT master node from multiple consensus nodes, and use the remaining consensus nodes as PBFT verification nodes;

[0010] Use PBFT master nodes and PBFT verification nodes to perform PBFT consensus operations;

[0011] If consensus is reached, the consensus result will be broadcast to all nodes of the blockchain to synchronize the ledger status and form a new block.

[0012] Optionally, after the step of performing PBFT consensus calculation using the PBFT master node and the PBFT verification node, if consensus cannot be reached, a new round of POA election is conducted to re-determine multiple consensus nodes.

[0013] Optionally, after the step of conducting a new round of POA election, the following steps are also included:

[0014] Identify the behavior of the PBFT master node in the consensus operation and determine whether the PBFT master node is a malicious node or a down node;

[0015] If the PBFT master node is a malicious node, the address of the PBFT master node will be deleted from the POA committee set;

[0016] If the PBFT master node is down, the address of the PBFT master node is retained in the POA committee set.

[0017] Optionally, the POA committee set is used to store the addresses of the authorized nodes, the authorized nodes are arranged according to the address size, and the POA committee set is stored in an additional field of the block header.

[0018] Optionally, the step of determining a PBFT master node from multiple consensus nodes using a preset priority algorithm includes:

[0019] Obtain the serial numbers of multiple consensus nodes in the POA committee set and the total number of authorized nodes in the POA committee set;

[0020] Use the block number of the block to be generated to perform a remainder operation on the total number of authorized nodes to obtain the remainder;

[0021] The PBFT master node is determined based on the relative size of the sequence number and the remainder.

[0022] Optionally, the above blockchain consensus method also includes:

[0023] Obtain the joining proposal initiated by the new node through the API (Application Programming Interface), and broadcast the proposal by reusing the nominating node address and nomination category fields in the block header;

[0024] Authorized nodes vote on the proposal. When the percentage of votes in favor exceeds the set threshold, new nodes will be added to the authorized nodes.

[0025] Optionally, before determining multiple consensus nodes through POA election, the following steps are also included:

[0026] Monitor the number of authorized nodes;

[0027] When the number of authorized nodes is less than the set threshold, consensus calculation is performed according to the POA method;

[0028] When the number of authorized nodes exceeds the set threshold, the consensus switching process is triggered.

[0029] Optionally, the consensus switching process includes:

[0030] Calculate the authorized nodes that participate in the consensus of the next block and record them as participating nodes;

[0031] Determine whether the participating nodes include the master node currently performing consensus calculations in the POA mode;

[0032] If yes, recalculate the participating nodes until the participating nodes do not include the master node;

[0033] Send switching instructions to participating nodes to enable them to switch the consensus mechanism.

[0034] Optionally, after the participating nodes switch the consensus mechanism, all authorized nodes are enabled to switch the consensus mechanism after the master node completes the block on-chain.

[0035] In particular, according to another aspect of the present invention, a computer-readable storage medium is provided, on which a machine executable program is stored. When the machine executable program is executed by a processor, any of the above-mentioned blockchain consensus methods is implemented.

[0036] The blockchain consensus method of the present invention improves upon the existing POA consensus algorithm by determining multiple consensus nodes from authorized nodes through POA elections. A preset priority algorithm is then used to determine a PBFT (Practical Byzantine Fault Tolerance) master node from among the consensus nodes. This method leverages the inherent advantages of the PBFT consensus mechanism, a weakly centralized consensus mechanism, in resisting Byzantine problems, weakening the risk of malicious master nodes and achieving relative equality among all nodes. Specifically, the blockchain consensus method of the present invention combines the Byzantine fault-tolerant consensus mechanism of the PBFT master and slave nodes with the POA consensus when generating blocks. The PBFT three-phase consensus protocol improves upon the existing POA consensus mechanism, preventing malicious attacks caused by the severe centralization of the POA consensus mechanism.

[0037] Furthermore, the blockchain consensus method of the present invention also designs a process for switching the consensus mechanism from traditional POA to an improved consensus mechanism combining PBFT and POA. When the number of authorized nodes exceeds a set threshold, the consensus switching process is triggered, and the authorized nodes participating in the next block consensus are quickly switched to the improved consensus mechanism combining PBFT and POA. This not only does not affect the ongoing block consensus, but also improves the efficiency of the next block.

[0038] Furthermore, the blockchain consensus method of the present invention is applicable to consortium chains and is controlled by authorized nodes, thereby improving security while ensuring block generation efficiency.

[0039] Based on the following detailed description of specific embodiments of the present invention in conjunction with the accompanying drawings, those skilled in the art will become more aware of the above and other objects, advantages and features of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Hereinafter, some specific embodiments of the present invention will be described in detail in an exemplary and non-limiting manner with reference to the accompanying drawings. The same reference numerals in the accompanying drawings indicate the same or similar components or parts. It should be understood by those skilled in the art that these drawings are not necessarily drawn to scale. In the accompanying drawings:

[0041] Figure 1 is a schematic diagram of a blockchain consensus method according to one embodiment of the present invention;

[0042] Figure 2 1 is a schematic diagram of a consensus process in a blockchain consensus method according to an embodiment of the present invention;

[0043] Figure 3 is a flowchart of switching consensus mechanisms in a blockchain consensus method according to an embodiment of the present invention; and

[0044] Figure 4 is a schematic block diagram of a machine-readable storage medium according to an embodiment of the present invention. DETAILED DESCRIPTION

[0045] Figure 1 FIG. 1 is a schematic diagram of a blockchain consensus method according to one embodiment of the present invention. The blockchain consensus method may generally include:

[0046] In step S102, multiple consensus nodes are determined from the authorized nodes through POA election. The addresses of the authorized nodes are stored in the extra field of the block header. For example, the extra field of the block header can store the POA committee set (Signers), which is used to store the addresses of the authorized nodes, where the authorized nodes are arranged according to the address size.

[0047] An initial set of authorized nodes is specified in the genesis block. Authorized nodes may be added or removed later, so the authorized nodes stored in blocks of different heights may differ.

[0048] In step S104, a pre-set priority algorithm is used to determine the PBFT master node from the multiple consensus nodes, and the remaining consensus nodes are designated as PBFT verification nodes. The priority algorithm prioritizes the multiple consensus nodes, selecting the consensus node with the highest priority as the PBFT master node. In this embodiment, four consensus nodes can be used, i.e., one PBFT master node and three PBFT verification nodes are determined.

[0049] A specific priority algorithm is as follows: obtain the sequence numbers of multiple consensus nodes in the POA committee set and the total number of authorized nodes in the POA committee set; use the block number of the block to be generated to perform a modulo operation on the total number of authorized nodes to obtain the remainder; and determine the PBFT master node based on the relative size of the sequence number and the remainder. For example, the block number of the block to be generated is recorded as Number, and Signers is the committee set, which is arranged in ascending order according to the address of the authorized node. Then (len(signers)) is the total number of authorized nodes; the sequence number (or position) of the consensus node in the POA committee set is recorded as Offset. The formula for performing the modulo operation is: number % uint64(len(signers)).

[0050] If (number%uint64(len(signers)))==uint64(offset), that is, the sequence number and the remainder are equal, then the authorization node has the highest priority. The priority of the authorized node can be identified as header.Difficulty=1, and the node address is automatically mapped to the address of PBFT1 to serve as the master node of this round of PBFT consensus; the three nodes (number%uint64(len(signers)))==uint64(offset)+1, (number%uint64(len(signers)))==uint64(offset)+2, and (number%uint64(len(signers)))==uint64(offset)+3) serve as PBFT verification nodes, and their priority is recorded as header.Difficulty=2. Among these three nodes, the three nodes mapped to the PBFT node address serve as PBFT verification nodes in this round and perform PBFT secondary consensus.

[0051] In this embodiment, the genesis block pre-configured smart contract uses the aforementioned priority algorithm to determine the PBFT master and slave nodes (master node and validator node). Since all nodes must execute according to the smart contract, four PBFT master and slave node addresses that agree on the algorithm are calculated. When a new block is generated, the four PBFT master and slave nodes automatically perform a Byzantine Fault Tolerance consensus mechanism. Other nodes wait for the secondary consensus result to synchronize block data.

[0052] In step S106, PBFT consensus is performed using the PBFT master node and PBFT validator nodes. PBFT is a state machine replication algorithm, where services are modeled as state machines, which are replicated across different nodes in a distributed system. Each state machine replica stores the service state and implements service operations. PBFT maintains a shared state, ensuring consistent actions across all nodes. To achieve this, PBFT requires running three basic protocols: a consensus protocol, a checkpoint protocol, and a view change protocol. We will focus on the consensus protocol that supports daily system operations. The consensus protocol consists of at least several phases: request, sequence number allocation (pre-prepare), mutual interaction (prepare), sequence number confirmation (commit), and reply. Each client request goes through five phases, with two pairwise interactions used to execute the client request only after the nodes reach consensus. Because clients cannot obtain any information about the node's operating status from the nodes, PBFT master node failures can only be monitored by the nodes themselves.

[0053] The basic process of a PBFT consensus operation involves a client sending a request, which activates the PBFT masternode's service operation. Upon receiving the request, the PBFT masternode initiates a three-phase protocol to broadcast the request to all PBFT validating nodes. The client then waits for responses from different nodes. If more than a preset number of responses are identical, that response becomes the result of the operation.

[0054] The three-phase protocol consists of the following: the sequence number assignment phase, in which the PBFT master node assigns a sequence number n to the request, broadcasts the sequence number assignment message and the client's request message m, and constructs a pre-prepare message to each PBFT validator node; the interaction phase, in which the PBFT validator node receives the pre-prepare message and broadcasts the prepare message to other nodes; and the sequence number confirmation phase, in which each node verifies the request and order within the view, broadcasts a commit message, executes the received client request, and responds to the client. The addition of the commit phase to the three-phase protocol ensures that no messages are submitted that conflict with already committed messages. This ensures both liveness and security of the algorithm, even in the presence of a malicious master node.

[0055] In step S108, if a consensus is reached, the consensus result is broadcast to all nodes of the blockchain to synchronize the ledger status and form a new block.

[0056] If consensus cannot be reached, a new round of POA elections is conducted to re-determine multiple consensus nodes. That is, the system initiates a proposal for a new round of POA to elect four new primary and secondary nodes for PBFT consensus. Following the new round of POA elections, the following steps may also be performed: identifying the behavior of the PBFT master node in the consensus operation to determine whether the PBFT master node is a malicious node or a down node; if the PBFT master node is a malicious node, deleting the PBFT master node's address from the POA committee set; if the PBFT master node is a down node, retaining the PBFT master node's address in the POA committee set. That is, for malicious nodes, the voting rights of the node are removed and the node address is deleted from the Extra field. If the node is a down node, the status quo is maintained.

[0057] The blockchain consensus method of this embodiment also improves the process of adding authorized nodes. If a new node needs to be added, the system can obtain the joining proposal initiated by the new node through the API. The proposal is broadcast by reusing the nominating node address (Coinbase) and nomination classification field (Nonce) in the block header. The authorized nodes vote on the proposal. If the proportion of votes in favor exceeds a set threshold, the new node is added to the authorized nodes. The threshold can be adjusted, for example, to 50%, 60%, or other values.

[0058] The block header includes the following fields: Coinbase, which records the node address of the nominated node; Nonce, which identifies the nomination category, including additions and deletions; Extra, which stores the POA committee set; and Difficulty, which identifies the node priority. When a new node needs to join, it can be broadcast to other nodes using the Coinbase and Nonce ("0xffffffffffffffff") fields. Authorized nodes vote on the new node's "join." If the number of votes in favor reaches 50% of the total number of signers (the total number of nodes in the committee), the new node is approved.

[0059] Similarly, when removing an authorized node, the authorized nodes will also vote. If the proportion of affirmative votes exceeds the set proportion, the deletion of the authorized node is agreed.

[0060] Figure 2 This diagram illustrates the consensus process in a blockchain consensus method according to one embodiment of the present invention. This consensus process specifies a group of initial authorized nodes in the genesis block. These initial authorized nodes are located in the genesis block's Extra field. After the system is booted, the initial authorized nodes are activated, and this group of nodes begins signing and broadcasting generated blocks.

[0061] The subsequent block consensus process includes:

[0062] In step S201, four nodes are elected at each block height as PBFT nodes 211 based on the system's built-in priority algorithm. The node with the highest priority serves as the PBFT master node PBFT1 for this block, and the remaining three serve as PBFT verification nodes PBFT2, PBFT3, and PBFT4. The system's genesis block uses a built-in PBFT consensus mapping algorithm. The address of the node with the highest priority in the election is mapped to PBFT1 as the master node, and the remaining nodes are mapped to PBFT2, PBFT3, and PBFT4 according to the priority in the priority algorithm. PBFT node 211 performs a three-phase consensus. If a problem with the PBFT1 master node prevents consensus from being reached, the system first initiates a proposal for a new round of POA to elect four new master and slave nodes for PBFT consensus.

[0063] The priority calculation formula is: (number%uint64(len(signers)))==uint64(offset). For the highest priority, header.Difficulty=1, and the node address is automatically mapped to the address of PBFT1 to serve as the master node for this round of PBFT consensus. For the three nodes (number%uint64(len(signers)))==uint64(offset)+1, (number%uint64(len(signers)))==uint64(offset)+2, and (number%uint64(len(signers)))==uint64(offset)+3), header.Difficulty=2. At the same time, the three nodes mapped to the PBFT node addresses serve as slave nodes for this round of PBFT secondary consensus. In the above formula, Number is the block number of the block to be generated; Signers is the committee set, sorted in ascending order by the node address; and Offset is the node's position in the Signers set.

[0064] In step S202, the consensus result is broadcast to all nodes to synchronize the local ledger 213 status.

[0065] In step S203, if a problem occurs with the PBFT1 master node and consensus cannot be reached, determine whether the master node is a malicious node or a down node based on its behavior. In step S203, if it is a malicious node, initiate a vote to remove the node, and delete the node address from the Extra field through consensus voting, that is, remove the PBFT1 node from the authorized node 211. If it is a down node, maintain the status quo.

[0066] In step S204, when a new node needs to be added, the new node initiates a proposal through the API interface. This proposal is broadcast to other nodes by reusing the Coinbase (new node address) and Nonce ("0xffffffffffffff") fields in the block header. All authorized nodes 211 vote on the new node to join. If the number of votes in favor exceeds 50% (the specific ratio can be adjusted), it means that the new node agrees to join.

[0067] During this process, a smart contract is pre-set in the genesis block to determine the PBFT master and slave nodes. All nodes must execute the smart contract and calculate the addresses of four consistent PBFT master and slave nodes. When a new block is generated, the four PBFT master and slave nodes automatically perform a Byzantine Fault Tolerance consensus. Other nodes wait for the secondary consensus result to synchronize the block data.

[0068] PBFT utilizes fewer nodes (e.g., four nodes in the above embodiment), runs very efficiently, is scalable, and utilizes a three-stage consensus to resolve the malicious node issue of the POA consensus. In other words, the method of this embodiment utilizes PBFT's weakly centralized consensus architecture to improve the existing POA consensus mechanism.

[0069] The method of this embodiment also provides a process for switching from traditional POA consensus to the above-mentioned POA and PBFT fusion consensus mechanism. Before executing the above-mentioned POA and PBFT fusion consensus mechanism process, that is, before the step of determining multiple consensus nodes through POA election, it can also include: monitoring the number of authorized nodes; when the number of authorized nodes is less than a set number threshold, performing consensus calculation according to the POA method; and triggering the consensus switching process after the number of authorized nodes exceeds the set number threshold.

[0070] The consensus switching process specifically includes: calculating the authorized nodes participating in the next block consensus, recorded as participating nodes; determining whether the participating nodes include the master node currently performing consensus calculations in the POA mode; if so, recalculating the participating nodes until the participating nodes do not include the master node; and sending a switch instruction to the participating nodes to switch the consensus mechanism. After the participating nodes switch the consensus mechanism, they can wait for the master node to complete the block on-chain before switching all authorized nodes to the consensus mechanism.

[0071] Figure 3 This is a flowchart of switching consensus mechanisms in a blockchain consensus method according to an embodiment of the present invention. The process of switching consensus mechanisms includes:

[0072] Step S302, monitoring the number of authorized nodes;

[0073] Step S304, determining whether the number of authorized nodes exceeds a set number threshold;

[0074] Step S306: After the number of authorized nodes exceeds the set threshold, the smart contract sends a consensus mechanism switching trigger instruction to the authorized nodes, instructing them to switch to the POA and PBFT fusion consensus mechanism starting from the next block;

[0075] Step S308: Calculate the nodes that will participate in the PBFT consensus for the next block based on the priority algorithm, that is, calculate the authorized nodes that will participate in the consensus for the next block, and obtain the participating nodes.

[0076] Step S310: Determine whether the calculated participating node is the master node of the POA consensus in this round of block formulation. If so, return to step S308 and recalculate the nodes participating in the PBFT consensus for the next block until it is determined that none of the participating nodes are the master nodes of the POA consensus for the current block.

[0077] Step S312: Send a consensus switching instruction to the nodes participating in the PBFT consensus of the next block, i.e., the participating nodes;

[0078] In step S314, after receiving the instruction, the nodes participating in the PBFT consensus for the next block, except for the module that receives the packaged block sent by the POA consensus mechanism and uploads it to the chain, all other modules quickly switch to the PBFT consensus mechanism module, thereby reducing the efficiency of the next block generation;

[0079] In step S316, after the current block is put on the chain, all modules that have not switched to the PBFT consensus mechanism will be switched to the PBFT consensus mechanism. After the current block is put on the chain, other authorized nodes will switch the consensus mechanism as a whole to the PBFT consensus mechanism, completing the switch from the POA consensus mechanism to the POA and PBFT fusion consensus mechanism.

[0080] The above process of switching the consensus mechanism from traditional POA to the improved consensus mechanism combining PBFT and POA triggers the consensus switching process when the number of authorized nodes exceeds the set threshold. The authorized nodes participating in the consensus of the next block will be quickly switched to the improved consensus mechanism combining PBFT and POA. On the one hand, it does not affect the ongoing block consensus, and on the other hand, it can improve the efficiency of the next block.

[0081] This embodiment also provides a computer-readable storage medium. Figure 4 4 is a schematic block diagram of a machine-readable storage medium 40 according to one embodiment of the present invention. The machine-readable storage medium 40 stores a machine-executable program 410, which, when executed by a processor, implements any of the above-mentioned blockchain consensus methods.

[0082] The technical solution of the present invention, or the portion that contributes to the prior art, or the portion of the technical solution, may be embodied in the form of a software product. This computer software product is stored in a storage medium and includes instructions for causing a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned readable storage medium 40 includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, ROM, RAM, a magnetic disk, or an optical disk.

[0083] In addition, it should be noted that, in the apparatus and method of the present invention, it is obvious that each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent schemes of the present invention. Moreover, the steps of performing the above-mentioned series of processing can naturally be performed in chronological order according to the order of description, but it is not necessary to perform them in chronological order, and some steps can be performed in parallel or independently of each other. For those of ordinary skill in the art, it will be understood that all or any steps or components of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or a network of computing devices in hardware, firmware, software or a combination thereof, which can be achieved by those of ordinary skill in the art using their basic programming skills after reading the description of the present invention.

[0084] Therefore, the purpose of the present invention can also be achieved by running a program or a group of programs on any computing device. The computing device can be a well-known general-purpose device. Therefore, the purpose of the present invention can also be achieved simply by providing a program product containing program code that implements the method or device. That is to say, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any well-known storage medium or any storage medium developed in the future. It should also be pointed out that in the device and method of the present invention, it is obvious that each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent schemes of the present invention. In addition, the steps of performing the above-mentioned series of processing can naturally be performed in chronological order according to the order of description, but do not necessarily need to be performed in chronological order. Certain steps can be performed in parallel or independently of each other.

[0085] Computing devices equipped with the above-mentioned readable storage medium 40 can be interconnected via a network, and can use any suitable interface or protocol (such as Internet Small Computer System Interface) to transmit data. The network can be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc., so that other computing devices can be connected through various networks.

[0086] At this point, those skilled in the art will recognize that, although a number of exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications consistent with the principles of the present invention may be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and deemed to cover all such other variations or modifications.

Claims

1. A blockchain consensus method, comprising: Determine multiple consensus nodes from authorized nodes through POA election; Determine the PBFT master node from the multiple consensus nodes using a preset priority algorithm, and use the remaining consensus nodes as PBFT verification nodes; Performing PBFT consensus calculations using the PBFT master node and the PBFT verification node; If consensus is reached, the consensus result will be broadcast to all nodes of the blockchain to synchronize the ledger status and form a new block; Before the step of determining a plurality of consensus nodes through POA election, the method further includes: monitoring the number of the authorized nodes; performing consensus calculation according to the POA method when the number of the authorized nodes is less than a set number threshold; and triggering a consensus switching process when the number of the authorized nodes exceeds the set number threshold; The consensus switching process includes: calculating the authorized nodes participating in the consensus of the next block, recorded as participating nodes; determining whether the participating nodes include the master node currently performing consensus calculation in the POA mode; if so, recalculating the participating nodes until the participating nodes do not include the master node; sending a switching instruction to the participating nodes to enable the participating nodes to switch the consensus mechanism.

2. The blockchain consensus method according to claim 1, wherein: After the step of performing PBFT consensus calculation using the PBFT master node and the PBFT verification node, if consensus cannot be reached, a new round of POA election is performed to re-determine multiple consensus nodes.

3. The blockchain consensus method according to claim 2, wherein: The steps for a new round of POA elections also include: Identify the behavior of the PBFT master node in the consensus operation and determine whether the PBFT master node is a malicious node or a down node; If the PBFT master node is a malicious node, the address of the PBFT master node is deleted from the POA committee set; If the PBFT master node is a down node, the address of the PBFT master node is retained in the POA committee set.

4. The blockchain consensus method according to claim 3, wherein: The POA committee set is used to store the addresses of the authorized nodes, the authorized nodes are arranged according to the address size, and the POA committee set is stored in an additional field of the block header.

5. The blockchain consensus method according to claim 4, wherein: The steps of determining a PBFT master node from the plurality of consensus nodes using a preset priority algorithm include: Obtaining the serial numbers of the plurality of consensus nodes in the POA committee set and the total number of authorized nodes in the POA committee set; Performing a remainder operation on the total number of authorized nodes using the block number of the block to be generated to obtain a remainder; The PBFT master node is determined according to the relative size of the sequence number and the remainder.

6. The blockchain consensus method according to claim 1, further comprising: Obtain the joining proposal initiated by the new node through the API. The proposal is broadcast by reusing the nominating node address and nomination category fields in the block header; The authorized node votes on the proposal, and when the approval ratio of the votes exceeds a set ratio threshold, the newly added node is added to the authorized node.

7. The blockchain consensus method according to claim 1, wherein After the participating nodes switch the consensus mechanism, wait for the master node to complete the block on-chain, and then make all authorized nodes switch the consensus mechanism.

8. A computer-readable storage medium having a machine-executable program stored thereon, wherein the machine-executable program, when executed by a processor, implements the blockchain consensus method according to any one of claims 1 to 7.

Images