Consensus method and system based on rpbft improved alliance chain

Abstract

The application provides a consensus method and system for alliance chain based on RPBFT improvement, and belongs to the technical field of blockchain consensus. The method comprises the following steps: S1, constructing a node list; S2, initializing a blockchain, selecting n1 nodes from the node list to construct a consensus committee node list; S3, in the initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default; S4, performing an improved consensus algorithm on the consensus committee nodes, if an abnormal condition such as verification failure or transaction processing timeout occurs, switching to the PBFT algorithm and starting the consensus again; S5, scoring according to the performance of the participating consensus committee nodes; and S6, after generating n2 blocks, a verification node is randomly selected by using a VRF function to replace the consensus committee node with the lowest score, and the scores of all the consensus committee nodes are cleared. The method can improve the performance while ensuring the safety.

Description

Technical Field

[0001] This invention belongs to the field of blockchain consensus technology, and specifically relates to a consortium blockchain consensus method and system based on RPBFT improvement. Background Technology

[0002] Blockchain technology is a decentralized, distributed ledger technology that records transactions or data in a secure, transparent, and immutable manner. First proposed by Satoshi Nakamoto in 2008 to support Bitcoin, its applications have expanded far beyond cryptocurrencies. The data structure of a blockchain is a chain-like structure, composed of a series of sequentially linked blocks. Each block contains a block header and a block body. The block header contains the hash value of the previous block, used to link to previous blocks and ensure the integrity and order of the chain. It also includes information such as a timestamp, difficulty target, random number, and Merkle root. The block body contains a Merkle tree recording the specific transaction data, recursively ascending from the bottom leaf nodes by pairwise hashes to form the parent node's hash value until a Merkle root is generated. Block generation relies on multiple technologies, including cryptography, distributed storage, P2P networks, and consensus algorithms. Among these, the consensus algorithm, as one of the core technologies of blockchain, plays a crucial role.

[0003] Consensus algorithms ensure that all participating nodes can reach an agreement on the authenticity of data and the validity of transactions without a central authority. Through consensus algorithms, blockchain networks can maintain data consistency and integrity, resist malicious attacks and node failures, thereby achieving a secure and reliable distributed ledger. With the rise of blockchain technology, various types of consensus algorithms have emerged. Based on different blockchain deployment types, existing blockchain consensus algorithms can be broadly divided into two categories: competitive consensus algorithms and election consensus algorithms. Competitive consensus algorithms nominate ledger nodes based on the amount of resources each node possesses (such as assets or computing power). This type of algorithm is represented by Bitcoin's Proof of Work (PoW), and derived from it are Proof of Stake (PoS), etc. Election consensus algorithms, on the other hand, elect consensus nodes through voting, and these consensus nodes take turns being elected as master nodes. This type of algorithm is represented by BFT-based consensus algorithms, such as Practical Byzantine Fault Tolerance (PBFT). In addition, there are CFT-based algorithms, such as Raft (Replication and Fault Tolerant).

[0004] Both competitive and election-based consensus algorithms have inherent flaws. Proof-of-Work (PoW) and Proof-of-Stake (PoS) suffer from high resource consumption, high transaction latency, and low throughput, while Raft is vulnerable to malicious attacks. In contrast, PBFT can tolerate a certain proportion of Byzantine nodes (malicious or downtime nodes) and boasts high throughput and low transaction latency, making it widely used in consortium blockchains. Despite its many strengths, PBFT also has significant drawbacks. The most notable is its consensus time complexity of O(N²), where N is the total number of nodes in the network. As the number of nodes increases, consensus efficiency drops dramatically.

[0005] To address this issue, FISCO BCOS (a domestic consortium blockchain platform) proposed RPBFT, which divides nodes into two categories: consensus committees are responsible for executing the consensus process, and verification nodes are responsible for verifying the legitimacy of consensus nodes and verifying blocks. The number of consensus nodes is a fixed value set initially. While retaining the high performance, high throughput, high consistency, and security of BFT-type consensus algorithms, it minimizes the impact of node size on the consensus algorithm. Although it improves upon the shortcomings of PBFT to some extent, there is still room for optimization. The algorithm has three main problems: First, the selection of master nodes is arbitrary. The election of master nodes is based on a formula-based sequential selection, without considering factors such as node performance, reliability, or historical behavior. Even nodes with poor performance or insufficient reliability may be selected as master nodes, thus affecting the efficiency and stability of the entire system. Second, the dynamic replacement process lacks security. The selection and replacement of consensus committee members are based on node numbers in sequence. Although this method is simple, it is insufficient in terms of security. Due to the lack of randomness and dynamic evaluation in the selection process, the system may be more susceptible to prediction and exploitation by attackers. Third, the communication complexity is high. Although RPBFT solves the time complexity problem to some extent by setting a fixed number of consensus committee members, when the number of nodes is large, it is impossible to set only a few nodes to participate in consensus. Its communication complexity is still quadratic, and there is still room for reduction. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a consortium blockchain consensus method based on an improved RPBFT, comprising the following steps:

[0007] Step S1: Sort and number the consensus nodes and verification nodes to build a node list;

[0008] Step S2: Initialize the blockchain and select n1 nodes from the node list to construct a consensus committee node list;

[0009] Step S3: In the overall initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default, and subsequent master nodes are selected based on the highest score according to the points reward mechanism;

[0010] Step S4: Execute the improved consensus algorithm on the consensus committee node. If an abnormal situation such as verification failure or transaction processing timeout occurs, switch to the PBFT algorithm and restart the consensus process.

[0011] Step S5: Evaluate the performance of the participating consensus committee nodes, and add corresponding points to the consensus committee nodes using the point reward formula and time decay function;

[0012] Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A VRF function is used to randomly select a verification node and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero.

[0013] Beneficial effects:

[0014] 1. This invention provides a consortium blockchain consensus method based on an improved RPBFT, introducing a points-based reward mechanism and a time decay function. The points-based reward mechanism incentivizes nodes to participate in the consensus process, especially in consortium blockchains, encouraging nodes to actively provide computing resources and verify transactions, thus maintaining network activity and stability. Adjusting a node's weight based on its historical behavior allows for a fairer distribution of consensus power and rewards, preventing poorly performing nodes from being elected as master nodes due to fixed election rules (such as round-robin election). The time decay function dynamically balances the growth of node points, preventing some nodes from excessively concentrating power due to excessively high points.

[0015] 2. This invention introduces the VRF algorithm to select consensus committee members. VRF provides verifiable randomness, ensuring that the selection process for consensus committee members is completely random, and that all nodes can independently verify the election results. This makes the election process more transparent, avoids malicious manipulation or centralization among nodes, and ensures the fairness of the system. Compared to traditional election methods based on fixed rules (such as round-robin elections), VRF can randomly and fairly select consensus committee members, preventing certain nodes from obtaining election opportunities for extended periods or excessively frequent periods.

[0016] 3. This invention implements a two-level consensus mechanism. In a consortium blockchain environment with an introductory reward mechanism and identity authentication, the probability of master node errors is low. Therefore, the prepare and commit phases of the PBFT algorithm are simplified in the consensus process. Even if the master node fails, it can switch to PBFT to re-establish consensus. This reduces system communication overhead and latency while ensuring system stability, thereby improving system processing efficiency. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a consortium blockchain consensus method based on RPBFT improvement according to the present invention.

[0018] Figure 2 A detailed flowchart illustrating the consensus method for consortium blockchains based on RPBFT;

[0019] Figure 3 A flowchart illustrating the improvement of the consensus algorithm;

[0020] Figure 4 A comparison chart showing the number of communications between the two algorithms under different numbers of nodes;

[0021] Figure 5 This is a structural block diagram of a consortium blockchain consensus system based on an improved RPBFT according to the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0023] Example 1

[0024] like Figure 1 As shown in the figure, an embodiment of the present invention provides a consortium blockchain consensus method based on RPBFT improvement, which includes the following steps:

[0025] Step S1: Sort and number the consensus nodes and verification nodes to build a node list;

[0026] Step S2: Initialize the blockchain and select n1 nodes from the node list to build a consensus committee node list;

[0027] Step S3: In the overall initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default, and subsequent master nodes are selected based on the highest score according to the points reward mechanism;

[0028] Step S4: Execute the improved consensus algorithm on the consensus committee node. If an abnormal situation such as verification failure or transaction processing timeout occurs, switch to the PBFT algorithm and restart the consensus process.

[0029] Step S5: Evaluate the performance of the participating consensus committee nodes, and add corresponding points to the consensus committee nodes using the point reward formula and time decay function;

[0030] Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A validator node is randomly selected using the VRF function and replaced with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero.

[0031] In one embodiment, step S1 above, which involves sorting and numbering consensus nodes and verification nodes to construct a node list, specifically includes:

[0032] All consensus nodes and verification nodes are randomly sorted. Each sorted node is assigned an index based on its position in the node list. This index is the node's number.

[0033] In one embodiment, step S2 above: initializing the blockchain and selecting n1 nodes from the node list to construct a consensus committee node list, specifically includes:

[0034] The blockchain is initialized by selecting nodes from index 0 to n1-1 from the node list to build a consensus committee node list, which is responsible for the consensus work of the first n2 blocks. Here, n1 and n2 are set according to the total number of nodes in the node list.

[0035] In one embodiment, step S3 above: In the overall initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default, and subsequent master nodes are selected based on the highest score according to the points reward mechanism, specifically including:

[0036] Step S31: Determine whether the current round is the overall initial consensus round or the initial consensus round after dynamic replacement. If it is, select the first node in the consensus committee node list as the master node and jump to step S4. If not, jump to step S32.

[0037] Step S32: Determine if there are multiple nodes with the highest and same score. If not, select the node with the highest score as the master node and jump to step S4. If so, jump to step S33.

[0038] Step S33: Determine whether multiple nodes with the highest and same scores have been elected as master nodes the same number of times. If they are different, select the node with the fewest elections as master node. If they are the same, select the node with the highest ranking in the consensus node list as master node. Proceed to step S4.

[0039] In one embodiment, step S4 above: Execute the improved consensus algorithm on the consensus committee node. If an abnormal situation such as verification failure or transaction processing timeout occurs, switch to the PBFT algorithm and restart the consensus process. Specifically, this includes:

[0040] Step S41: In the request phase, the client prepares a request message with the following format:<REQUEST, o, t, c> Where o represents the request operation, t represents the timestamp, and c represents the client; the client digitally signs the request to ensure the integrity of the message and the verifiability of its source, and then sends the request message to the current master node;

[0041] Step S42: In the pre-prepare phase, after receiving the client's request and verifying its validity, the master node generates a pre-prepare message << PRE-PREPARE, v, n, d> ,m>, where v represents the current view number, n represents the unique sequence number assigned to the request, d represents the request digest, i.e., the hash value of the request, and m represents the request message; then, the master node broadcasts the pre-prepare message to all backup nodes; where the view is the term identifier of the master node, and master node rotation is achieved by incrementing it;

[0042] Step S43: In the prepare phase, each backup node receives a prepare message from the master node and verifies the message's signature and request digest. If verification is successful, the node enters the preparation phase and generates a prepare message <PREPATE, v, n, d, i>, where i represents the node ID. The backup node broadcasts this message to the master node. The master node verifies the prepare messages received from other nodes. If the master node receives prepare messages from at least 2f different nodes, and the view number, sequence number, and request digest of these messages are consistent with the prepare message, the node's preparation phase is complete. If verification fails or the transaction times out, the process switches to the PBFT consensus process and consensus is re-established. Here, f is the maximum number of Byzantine nodes the system can tolerate, i.e., the number of malicious or faulty nodes.

[0043] Step S44: Commit phase. When the master node determines that the request is ready, it generates a commit message <commit,v,n,d,i> and broadcasts the message to all other backup nodes. Each backup node verifies the commit message received from the master node. If the verification is successful, it jumps to step S45; otherwise, it switches to the PBFT consensus process.

[0044] Step S45: Reply Phase. After the confirmation phase, the backup node has confirmed that the request has reached consensus. At this time, the node executes the operation in the request and generates a reply message < REPLY, v, t, c, r, i >, where r represents the result after executing the request. The backup node sends the reply message to the client. If the client receives valid reply messages from at least f + 1 different nodes, it can confirm that the request has been correctly processed and consensus has been reached, and the transaction is completed. Otherwise, it switches to the PBFT consensus process and re-achieves consensus.

[0045] In one embodiment, step S5 above, which evaluates the performance of participating consensus committee nodes and adds corresponding points to them using a point reward formula and a time decay function, specifically includes:

[0046] Step S51: Execute the time decay function, which is as follows:

[0047] ;

[0048] ;

[0049] Where n represents the number of times node i participates in consensus, λ represents the decay rate, and α and β are weight parameters;

[0050] Step S52: Implement point rewards. After each round of consensus is completed, the nodes that participated in the consensus will receive corresponding point adjustments based on their contributions and performance. The adjustment formula is as follows:

[0051] ;

[0052] in, Let i be the integral of node i. For the historical integral of node i, This represents an evaluation of the master node's performance. This represents an evaluation of the backup node's performance.

[0053] Step S53: Determine if the current block is a multiple of n2. If it is, proceed to step S6. If not, determine if there are any unpackaged transactions. If so, proceed to step S3 to begin a new round of master node selection and secondary consensus.

[0054] In one embodiment, step S6 above: After every n² blocks are generated, the consensus committee list is dynamically adjusted. A VRF function is used to randomly select a verification node and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero. Specifically, this includes:

[0055] Step S61: Use the VRF_Hash function to generate a pseudo-random output value using the master node's private key and the current block ID. The VRF_Hash function is shown below:

[0056] ;

[0057] in, This is the private key of the current master node. Let this be the ID of the current block. The obtained pseudo-random output value;

[0058] Step S62: The pseudo-random output value is processed using a modulo function, and the remainder after taking the remainder from the total number of validator nodes determines the sequence number of a validator node. This node is then selected as the new consensus committee node. The modulo function is shown below:

[0059] ;

[0060] Where N is the total number of nodes in the node list, epoch_sealer_num is the total number of nodes in the consensus committee node list, and Consensus_Committee_New is the new consensus committee node;

[0061] Step S63: Replace the new consensus committee node with the node with the lowest score in the consensus committee node list;

[0062] Step S64: Clear the scores of all nodes in the consensus committee node list to zero.

[0063] Figure 2 A flowchart illustrating the consortium blockchain consensus method based on the improved RPBFT of this invention is shown.

[0064] The communication transmission cost of a consensus algorithm refers to the network communication resources consumed in a distributed system during message passing and data synchronization to ensure that multiple nodes reach an agreement (consensus) on a certain state or transaction. To evaluate the algorithm's performance, this embodiment of the invention assumes a total of N consensus nodes (N≥3f+1), a probability of p for triggering the view switching protocol, and no node downtime.

[0065] The following is a comparative analysis of the communication volume between the traditional RPBFT consensus algorithm and the consensus algorithm based on the improved RPBFT of this invention:

[0066] 1. Traffic Analysis of Traditional RPBFT Consensus Algorithm

[0067] Since RPBFT's consensus protocol still uses the PBFT protocol, the communication throughput is calculated according to the PBFT protocol. The communication throughput of the PBFT protocol is mainly determined by its phased communication structure, including the pre-prepare, prepare, and commit phases. In the pre-prepare phase, the master node sends the proposal to all backup nodes, requiring a total of N-1 messages to be sent. In the prepare phase, all backup nodes need to broadcast preparation messages to each other, with each node broadcasting N-1 messages, for a total of (N-1) messages. 2 The total number of messages is N(N-1). During the commit phase, all backup nodes broadcast commit messages to each other again, with each node broadcasting N-1 messages, for a total of N(N-1) messages. The total communication volume across the three phases is 2N. 2 -2N. When the view switching protocol is triggered, after a node detects a failure of the master node, it sends a View-Change message to all other nodes. Each node sends the message to N-1 nodes, resulting in a total communication volume of N(N-1). After receiving 2f+1 View-Change messages, the new master node sends a New-View message to all nodes and broadcasts the New-View message to N-1 nodes, resulting in a communication volume of N-1. The total communication volume for view switching is N. 2 -N. Assuming the view switching probability is p, the number of communications in the RPBFT consensus algorithm is as follows:

[0068] .

[0069] 2. Traffic Analysis of the Consensus Algorithm Based on Improved RPBFT in this Invention

[0070] In real-world environments, the probability of Byzantine nodes appearing is extremely low, and this invention achieves the election of trusted master nodes through a points-based reward mechanism. Because the trustworthiness of the master nodes is guaranteed, the traditional PBFT consensus process can be reasonably simplified. For example... Figure 3 As shown, by simplifying the prepare and commit phases of the traditional PBFT consensus algorithm, the algorithm's complexity is reduced, and its efficiency is improved. According to theoretical calculations, the total number of communications for the RPBFT-based improved consensus algorithm in one round of consensus is 3(N-1). If a view switch is triggered, the protocol switches to the PBFT protocol, and the total number of communications becomes 3N(N-1). Assuming the view switch probability is p, the number of communications for the RPBFT-based improved consensus algorithm will be as shown in the following formula:

[0071] ;

[0072] The communication volume of the two consensus algorithms mentioned above is compared as follows:

[0073] Assuming the view switching probability is p, and the communication ratio between the two consensus algorithms is R, as shown in the following formula:

[0074] ;

[0075] Set different view switching probability values ​​of 0, 0.25, 0.33, and 0.5, and calculate the communication volume ratio of the two consensus algorithms under different numbers of nodes. For example... Figure 4 As shown, when p=0, the communication frequency of the consensus algorithm based on RPBFT is significantly lower than that of the traditional PBFT consensus protocol. This is because the algorithm simplifies the prepare and commit phases, greatly reducing message interaction between nodes during the consensus process without triggering view switching. In contrast, the traditional PBFT has higher communication complexity, so the optimization effect of this algorithm is particularly significant in this case. When p>0, as the view switching probability p increases, the communication frequency of this algorithm gradually approaches that of PBFT. This is because when view switching is triggered, the algorithm reverts to the standard PBFT process, introducing higher communication overhead. However, since view switching is only triggered under specific conditions, this algorithm can still maintain good communication efficiency even at lower p. Overall, as p increases, the communication frequency ratio of the two algorithms gradually decreases, but this algorithm is still superior to PBFT. Furthermore, as the number of nodes N increases, the communication frequency of both algorithms shows an increasing trend with the node size, with PBFT showing a higher growth rate than this algorithm. Specifically, when the number of nodes is small, the communication ratio increases rapidly; as the number of nodes further increases, the growth rate gradually slows down and eventually stabilizes. This indicates that in large-scale distributed networks with Byzantine nodes, the growth rate of the algorithm's optimization effect gradually weakens with the increase in the number of nodes, but it can still maintain good performance, especially when the probability of view switching is low.

[0076] Example 2

[0077] like Figure 5 As shown, this embodiment of the invention provides a consortium blockchain consensus system based on an improved RPBFT, comprising the following modules:

[0078] The node list construction module 71 is used to sort and number consensus nodes and verification nodes to construct a node list;

[0079] The consensus committee node list construction module 72 is used to initialize the blockchain and select n1 nodes from the node list to construct the consensus committee node list;

[0080] The master node selection module 73 is used to select the first node in the consensus committee node list as the master node by default in the overall initial consensus round or the initial consensus round after dynamic replacement. Subsequent master nodes are selected based on the highest score according to the points reward mechanism.

[0081] The improved consensus algorithm module 74 is executed to perform the improved consensus algorithm on the consensus committee nodes. If an abnormal situation such as verification failure or transaction processing timeout occurs, it switches to the PBFT algorithm and restarts the consensus process.

[0082] The scoring module 75 is used to evaluate the performance of participating consensus committee nodes, and uses a point reward formula and a time decay function to add corresponding points to the consensus committee nodes.

[0083] The consensus committee node adjustment module 76 is used to dynamically adjust the consensus committee list after every n2 blocks are generated. It uses the VRF function to randomly select a verification node and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero.

[0084] A consortium blockchain consensus device based on RPBFT improvement includes one or more electronic devices, wherein the one or more electronic devices are used to implement the consortium blockchain consensus method, system and device based on RPBFT improvement.

[0085] An electronic device includes: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors enable the one or more processors to implement a consortium blockchain consensus method, system, and apparatus based on RPBFT.

[0086] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A consortium blockchain consensus method based on an improved RPBFT, characterized in that, include: Step S1: Sort and number the consensus nodes and verification nodes to build a node list; Step S2: Initialize the blockchain and select n1 nodes from the node list to construct a consensus committee node list; Step S3: In the overall initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default, and subsequent master nodes are selected based on the highest score according to the points reward mechanism; Step S4: Execute the improved consensus algorithm on the consensus committee nodes. If verification failures or transaction processing timeouts occur, switch to the PBFT algorithm and restart the consensus process. This includes: Step S41: In the request phase, the client prepares a request message with the following format:<REQUEST, o, t, c> Where o represents the request operation, t represents the timestamp, and c represents the client; the client digitally signs the request to ensure the integrity of the message and the verifiability of its source, and then sends the request message to the current master node; Step S42: In the pre-prepare phase, after receiving the client's request and verifying its validity, the master node generates a pre-prepare message << PRE-PREPARE, v, n, d> ,m>, where v represents the current view number, n represents the unique sequence number assigned to the request, d represents the request digest, i.e., the hash value of the request, and m represents the request message; then, the master node broadcasts the pre-prepare message to all backup nodes; wherein, the view is the term identifier of the master node, and master node rotation is achieved by incrementing it; Step S43: In the prepare phase, each backup node receives a pre-prepare message from the master node and verifies the message's signature and request digest. If verification is successful, the node enters the preparation phase and generates a preparation message < PREPARE, v, n, d, i>, where i represents the node ID. The backup node broadcasts this message to the master node. The master node verifies the preparation messages received from other nodes. If the master node receives preparation messages from at least 2f different nodes, and the view number, sequence number, and request digest of these messages are consistent with the pre-prepare message, the node's preparation phase is complete. If verification fails or the transaction times out, the process switches to the PBFT consensus process and consensus is re-established. Here, f is the maximum number of Byzantine nodes the system can tolerate, i.e., the number of malicious or faulty nodes. Step S44: Commit phase. When the master node determines that the request is ready, it generates a commit message <commit, v, n, d, i> and broadcasts the message to all other backup nodes. Each backup node verifies the commit message received from the master node. If the verification is successful, it proceeds to step S45; otherwise, it switches to the PBFT consensus process. Step S45: Reply Phase. After the confirmation phase, the backup node has confirmed that the request has reached consensus. At this time, the node executes the operation in the request and generates a reply message < REPLY, v, t, c, r, i >, where r represents the result after executing the request. The backup node sends the reply message to the client. If the client receives valid reply messages from at least f + 1 different nodes, it can confirm that the request has been correctly processed and consensus has been reached, and the transaction is completed. Otherwise, it switches to the PBFT consensus process and re-achieves consensus. Step S5: Evaluate the performance of the participating consensus committee nodes, and add corresponding points to the consensus committee nodes using the point reward formula and time decay function. Specifically, this includes: Step S51: Execute the time decay function, which is as follows: ； ； Where n represents the number of times node i participates in consensus, λ represents the decay rate, and α and β are weight parameters; Step S52: Implement point rewards. After each round of consensus is completed, the nodes that participated in the consensus will receive corresponding point adjustments based on their contributions and performance. The adjustment formula is as follows: ； in, Let i be the integral of node i. For the historical integral of node i, This represents an evaluation of the master node's performance. This represents an evaluation of the backup node's performance. Step S53: Determine if the current block is a multiple of n2. If it is, proceed to step S6. If not, determine if there are any unpackaged transactions. If so, proceed to step S3 and begin a new round of master node selection and secondary consensus. Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A VRF function is used to randomly select a verification node and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero.

2. The consortium blockchain consensus method based on RPBFT improvement according to claim 1, characterized in that, Step S1: Sort and number the consensus nodes and verification nodes to construct a node list, specifically including: All consensus nodes and verification nodes are randomly sorted. Each sorted node is assigned an index based on its position in the node list. This index is the node's number.

3. The consortium blockchain consensus method based on RPBFT improvement according to claim 2, characterized in that, Step S2: Initialize the blockchain by selecting n1 nodes from the node list to construct a consensus committee node list, specifically including: The blockchain is initialized by selecting nodes with indices from 0 to n1-1 from the node list to construct a consensus committee node list, which is responsible for the consensus work of the first n2 blocks, where n1 and n2 are set according to the total number of nodes in the node list.

4. The consortium blockchain consensus method based on RPBFT improvement according to claim 3, characterized in that, Step S3: In the overall initial consensus round or the initial consensus round after dynamic replacement, the first node in the consensus committee node list is selected as the master node by default. Subsequent master nodes are selected based on the highest score according to the points reward mechanism, specifically including: Step S31: Determine whether the current round is the overall initial consensus round or the initial consensus round after dynamic replacement. If it is, select the first node in the consensus committee node list as the master node and jump to step S4. If not, jump to step S32. Step S32: Determine if there are multiple nodes with the highest and same score. If not, select the node with the highest score as the master node and jump to step S4. If so, jump to step S33. Step S33: Determine whether multiple nodes with the highest and same scores have been elected as master nodes the same number of times. If they are different, select the node with the fewest elections as master node. If they are the same, select the node with the highest ranking in the consensus node list as master node. Proceed to step S4.

5. The consortium blockchain consensus method based on RPBFT improvement according to claim 4, characterized in that, Step S6: After every n² blocks are generated, the consensus committee list is dynamically adjusted. A VRF function is used to randomly select a verification node and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero. Specifically, this includes: Step S61: Use the VRF_Hash function to generate a pseudo-random output value using the master node's private key and the current block ID. The VRF_Hash function is shown below: ； in, This is the private key of the current master node. Let this be the ID of the current block. The obtained pseudo-random output value; Step S62: The pseudo-random output value is calculated using a modulo function, and the remainder after taking the total number of verification nodes determines the sequence number of a verification node. This node is then selected as a new consensus committee node. The modulo function is shown below: ； Where N is the total number of nodes in the node list, epoch_sealer_num is the total number of nodes in the consensus committee node list, and Consensus_Committee_New is the new consensus committee node; Step S63: Replace the new consensus committee node with the node with the lowest score in the consensus committee node list; Step S64: Clear the scores of all nodes in the consensus committee node list to zero.

6. A consortium blockchain consensus system based on an improved RPBFT, characterized in that, Includes the following modules: The node list construction module is used to sort and number consensus nodes and verification nodes to construct a node list; A consensus committee node list construction module is used to initialize the blockchain and select n1 nodes from the node list to construct the consensus committee node list; The master node selection module is used to select the first node in the consensus committee node list as the master node by default in the overall initial consensus round or the initial consensus round after dynamic replacement. Subsequent master nodes are selected based on the highest score according to the points reward mechanism. The improved consensus algorithm module executes the improved consensus algorithm on the consensus committee nodes. If an anomaly occurs, such as verification failure or transaction processing timeout, it switches to the PBFT algorithm and restarts the consensus process. Specifically, this includes: Step S41: In the request phase, the client prepares a request message with the following format:<REQUEST, o, t, c> Where o represents the request operation, t represents the timestamp, and c represents the client; the client digitally signs the request to ensure the integrity of the message and the verifiability of its source, and then sends the request message to the current master node; Step S42: In the pre-prepare phase, after receiving the client's request and verifying its validity, the master node generates a pre-prepare message << PRE-PREPARE, v, n, d> ,m>, where v represents the current view number, n represents the unique sequence number assigned to the request, d represents the request digest, i.e., the hash value of the request, and m represents the request message; then, the master node broadcasts the pre-prepare message to all backup nodes; wherein, the view is the term identifier of the master node, and master node rotation is achieved by incrementing it; Step S43: In the prepare phase, each backup node receives a pre-prepare message from the master node and verifies the message's signature and request digest. If verification is successful, the node enters the preparation phase and generates a preparation message < PREPARE, v, n, d, i>, where i represents the node ID. The backup node broadcasts this message to the master node. The master node verifies the preparation messages received from other nodes. If the master node receives preparation messages from at least 2f different nodes, and the view number, sequence number, and request digest of these messages are consistent with the pre-prepare message, the node's preparation phase is complete. If verification fails or the transaction times out, the process switches to the PBFT consensus process and consensus is re-established. Here, f is the maximum number of Byzantine nodes the system can tolerate, i.e., the number of malicious or faulty nodes. Step S44: Commit phase. When the master node determines that the request is ready, it generates a commit message <commit, v, n, d, i> and broadcasts the message to all other backup nodes. Each backup node verifies the commit message received from the master node. If the verification is successful, it proceeds to step S45; otherwise, it switches to the PBFT consensus process. Step S45: Reply Phase. After the confirmation phase, the backup node has confirmed that the request has reached consensus. At this time, the node executes the operation in the request and generates a reply message < REPLY, v, t, c, r, i >, where r represents the result after executing the request. The backup node sends the reply message to the client. If the client receives valid reply messages from at least f + 1 different nodes, it can confirm that the request has been correctly processed and consensus has been reached, and the transaction is completed. Otherwise, it switches to the PBFT consensus process and re-achieves consensus. The scoring module evaluates the performance of participating consensus committee nodes, using a point-based reward formula and a time decay function to award points to these nodes. Specifically, it includes: Step S51: Execute the time decay function, which is as follows: ； ； Where n represents the number of times node i participates in consensus, λ represents the decay rate, and α and β are weight parameters; Step S52: Implement point rewards. After each round of consensus is completed, the nodes that participated in the consensus will receive corresponding point adjustments based on their contributions and performance. The adjustment formula is as follows: ； in, Let i be the integral of node i. For the historical integral of node i, This represents an evaluation of the master node's performance. This represents an evaluation of the backup node's performance. Step S53: Determine if the current block is a multiple of n2. If it is, proceed to step S6. If not, determine if there are any unpackaged transactions. If so, proceed to step S3 and begin a new round of master node selection and secondary consensus. The consensus committee node adjustment module is used to dynamically adjust the consensus committee list after every n2 blocks are generated. It uses a VRF function to randomly select one of the verification nodes and replace it with the consensus committee node with the lowest score. After the replacement is completed, the scores of all nodes in the consensus committee node list are cleared to zero.

7. A consortium blockchain consensus device based on an improved RPBFT, characterized in that, It includes one or more electronic devices, wherein the one or more electronic devices are used to implement the method of any one of claims 1 to 5.

8. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1 to 5.

Images