Alliance chain consensus method and system based on RPBFT improvement

Abstract

The invention provides an alliance chain consensus method and system based on RPBFT improvement, and belongs to the technical field of block chain consensus. Comprising the following steps: S1, constructing a node list; s2, initializing the block chain, and selecting n1 nodes from the node list to construct a consensus delegate node list; s3, in an overall initial consensus round or an initial consensus round after dynamic replacement, default selection of a first node in a consensus delegate node list is carried out as a main node; s4, executing an improved consensus algorithm on the consensus delegate node, if abnormal conditions such as verification failure or transaction processing timeout occur, switching to a PBFT algorithm, and restarting consensus; s5, scoring according to the performance of the participated consensus delegate nodes; and S6, after every n2 blocks are generated, a verification node is randomly selected by using a VRF function to replace the consensus delegate node with the lowest integral, and the integral of all the consensus delegate nodes is reset. According to the method, the performance is improved while the safety is ensured.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain consensus technology, and in particular relates to an improved alliance chain consensus method and system based on RPBFT. Background Art

[0002] Blockchain technology is a decentralized, distributed ledger that records transactions and data in a secure, transparent, and immutable manner. It was first proposed by Satoshi Nakamoto in 2008 to power Bitcoin, but its applications extend far beyond cryptocurrencies. The blockchain data structure is a chain, consisting of a series of sequentially linked blocks. Each block consists of a header and a body. The header contains the hash of the previous block, linking it to the previous block and ensuring the integrity and order of the chain. It also includes information such as a timestamp, difficulty target, nonce, and Merkle root. The body consists of a Merkle tree that records specific transaction data. Starting from the bottom leaf node, the tree is recursively constructed upwards by hashing each pair of nodes to form the parent node's hash value until the Merkle root is generated. Block generation relies on multiple technologies, including cryptography, distributed storage, peer-to-peer networks, and consensus algorithms. Consensus algorithms, as one of the core technologies of blockchain, play a crucial role.

[0003] Consensus algorithms ensure that all participating nodes can reach 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, and thus achieve a secure and reliable distributed ledger. With the rise of blockchain technology, various consensus algorithms have emerged. Existing blockchain consensus algorithms can be broadly categorized into two types, depending on the type of blockchain deployment. One type is competitive consensus algorithms, in which ledger nodes are nominated based on the amount of resources each node possesses (such as assets or computing power). This type of algorithm is exemplified by Bitcoin's Proof of Work (PoW), from which Proof of Stake (PoS) and other derivatives have emerged. The other type is electoral consensus algorithms, in which all nodes elect consensus nodes through voting, and these nodes rotate as the master node. This type of algorithm is exemplified by BFT consensus algorithms, such as Practical Byzantine Fault Tolerance (PBFT). There are also CFT algorithms, such as Raft (Replication and Fault Tolerant).

[0004] Both competitive and electoral consensus algorithms have certain flaws. PoW and PoS consume large amounts of resources, experience high transaction latency, and have low throughput. Raft is also vulnerable to malicious attacks. In contrast, PBFT can tolerate a certain percentage of Byzantine nodes (malicious or down nodes) and offers high throughput and low transaction latency, making it widely used in consortium chains. While PBFT excels in many areas, it also has some significant flaws. The most significant issue is that its consensus time complexity is O(N²), where N is the total number of nodes in the network. Consensus efficiency decreases significantly as the number of nodes increases.

[0005] To address this issue, FISCO BCOS (a domestic consortium blockchain platform) proposed RPBFT, which divides nodes into two categories. Consensus committee members 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 an initially set fixed value. 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 this improves the shortcomings of PBFT to a certain extent, there is still room for optimization. There are three main problems with this algorithm: First, the selection of master nodes is arbitrary. The election of master nodes is based on a formula-based sequence, without taking into account factors such as node performance, reliability, or historical behavior. Even nodes with poor performance or unreliability 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 the node number in sequence. Although this method is simple, it has shortcomings in security. Due to the lack of randomness and dynamic evaluation in the selection process, this may make the system more vulnerable to prediction and exploitation by attackers; Third, the communication complexity is high. Although RPBFT solves the problem of time complexity to a certain extent by setting a fixed number of consensus committee members, when the number of nodes is relatively large, it is impossible for consensus committee members to set only a few nodes to participate in the consensus. Its communication complexity is still quadratic, and there is still room for improvement. Summary of the Invention

[0006] To solve the above technical problems, the present invention provides an improved consortium chain consensus method based on 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 based on the point reward mechanism;

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

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

[0012] Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A verification 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 reset to zero.

[0013] Beneficial effects:

[0014] 1. This invention provides an improved consortium chain consensus method based on RPBFT, introducing a points reward mechanism and a time decay function. The points reward mechanism incentivizes node participation in the consensus process. This mechanism, particularly in consortium chains, encourages nodes to actively contribute computing resources, validate transactions, and maintain network activity and stability. Adjusting node weights based on their historical behavior allows for a more equitable distribution of consensus power and rewards, avoiding the situation where fixed election rules (such as round-robin elections) result in poorly performing nodes being elected as master nodes. The time decay function dynamically balances node points growth, preventing excessive concentration of power in certain nodes due to excessively high points.

[0015] 2. This invention introduces the VRF algorithm to select consensus members. VRF provides verifiable randomness, ensuring that the selection process 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 system fairness. Compared to traditional election methods based on fixed rules (such as round-robin elections), VRF can select consensus members randomly and fairly, preventing certain nodes from receiving election opportunities for a long period of time or excessively frequently.

[0016] 3. This invention implements a two-level consensus. In a consortium chain environment with a points reward mechanism and identity authentication, the probability of master node errors is low. Therefore, the consensus process simplifies the prepare and commit phases of the PBFT algorithm. Even if a master node fails, consensus can be re-established using PBFT. This reduces system communication overhead and latency, while ensuring system stability, and improves system processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of an improved consortium chain consensus method based on RPBFT according to the present invention;

[0018] Figure 2 This is a detailed flowchart of the improved consortium chain consensus method based on RPBFT;

[0019] Figure 3 A flowchart diagram for improving the consensus algorithm;

[0020] Figure 4 This is a comparison chart of the communication times of the two algorithms under different numbers of nodes;

[0021] Figure 5 This is a structural block diagram of the alliance chain consensus system improved based on RPBFT in the present invention. DETAILED DESCRIPTION

[0022] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only intended to illustrate the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0023] Example 1

[0024] like Figure 1 As shown, an embodiment of the present invention provides an improved consortium chain consensus method based on RPBFT, comprising 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 the 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 based on the point reward mechanism;

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

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

[0030] Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A verification 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 points of all nodes in the consensus committee node list are reset to zero.

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

[0032] All consensus nodes and verification nodes are randomly sorted. The sorted nodes are assigned an index according to their position in the node list. This index is the node number.

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

[0034] Initialize the blockchain and select nodes with indexes from 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, where 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 based on the point 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 so, 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 whether there are multiple nodes with the same highest 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 least number of times elected as master node as the master node. If they are the same, select the node with the highest ranking in the consensus node list as the master node, and jump to step S4.

[0039] In one embodiment, the above step S4: executing the improved consensus algorithm on the consensus committee nodes. If an abnormal situation such as verification failure or transaction processing timeout occurs, switching to the PBFT algorithm and restarting the consensus specifically includes:

[0040] Step S41: In the request phase, the client prepares a request message in the 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 the 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 number of the current view, n represents the unique sequence number assigned to the request, d represents the digest of the request, i.e., the hash value of the request, and m represents the request message. The master node then broadcasts the pre-prepare message to all backup nodes. 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, after receiving the prepare message from the master node, each backup node verifies the signature and request digest of the message. If the verification is successful, the node enters the prepare phase and generates a prepare message <PREPARE,v,n,d,i>, where i represents the node ID number. The backup node broadcasts this message to the master node. After receiving prepare messages from other nodes, the master node verifies the prepare message. 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 prepare phase is completed. If the verification fails or the transaction times out, the node switches to the PBFT consensus process and re-consensus. Where f is the maximum number of Byzantine nodes that the system can tolerate, that is, the number of malicious or faulty nodes.

[0043] Step S44: In the commit phase, when the master node determines that the request is ready, it generates a commit message <commit,v,n,d,i> and broadcasts it to all other backup nodes. After receiving the commit message from the master node, each backup node verifies it. If the verification passes, 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 confirms that the request has reached consensus. At this point, 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 be confirmed that the request has been correctly processed and consensus has been reached, and the transaction is complete. Otherwise, it switches to the PBFT consensus process and re-consensus.

[0045] In one embodiment, the above step S5: evaluating the performance of participating consensus committee nodes and applying the point reward formula and time decay function to increase corresponding points for the consensus committee nodes 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 β are weight parameters;

[0050] Step S52: Points are awarded. After each round of consensus is completed, the nodes participating in the consensus will receive corresponding points adjustments based on their contributions and performance. The adjustment formula is as follows:

[0051] ;

[0052] in, is the integral of node i, is the historical integral of node i, Represents the evaluation of the master node's work, Represents the evaluation of the backup node's work;

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

[0054] In one embodiment, the above step S6: after every n2 blocks are generated, the consensus committee list is dynamically adjusted. A verification 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 reset to zero. Specifically, the following steps are performed:

[0055] Step S61: Generate a pseudo-random output value using the master node’s private key and the current block ID through the VRF_Hash function ; The VRF_Hash function is as follows:

[0056] ;

[0057] in, is the private key of the current master node, is the ID of the current block, is the pseudo-random output value obtained;

[0058] Step S62: The pseudo-random output value is calculated by the remainder function to take the remainder of the total number of verification nodes, thereby determining the serial number of a verification node, and the node is selected as the new consensus committee node; the remainder function is as follows:

[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: The new consensus committee node will be replaced with the node with the lowest score in the consensus committee node list;

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

[0063] Figure 2 A flow chart of the improved alliance chain consensus method based on RPBFT of the present invention is shown.

[0064] The communication and transmission consumption of a consensus algorithm refers to the network communication resources consumed by message transmission and data synchronization in a distributed system, enabling multiple nodes to reach consensus on a particular state or transaction. To evaluate the algorithm's performance, this embodiment assumes that the total number of consensus nodes is N (N ≥ 3f + 1), the probability of triggering the view switching protocol is p, and there are no node downtime.

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

[0066] 1. Analysis of communication volume of traditional RPBFT consensus algorithm

[0067] Since the consensus protocol of RPBFT still uses the PBFT protocol, the communication volume is calculated according to the PBFT protocol. The communication volume 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. In the prepare phase, all backup nodes need to broadcast prepare messages to each other, with each node broadcasting N-1 messages, for a total of (N-1) 2 In the commit phase, all backup nodes broadcast commit messages to each other again, and each node broadcasts N-1 messages, for a total of N(N-1) messages. The communication volume in the three phases is 2N 2 -2N. When the view switching protocol is triggered, when a node detects a master node failure, it sends a View-Change message to all other nodes. Each node sends messages to N-1 nodes, and the total communication volume is N(N-1). After receiving 2f+1 View-Change messages, the new master node sends a New-View message to all nodes. The new master node broadcasts the New-View message to N-1 nodes, and the communication volume is N-1. The total view switching communication volume is N 2 -N. Assuming the view switching probability is p, the number of communications of the RPBFT consensus algorithm is shown in the following formula:

[0068] .

[0069] 2. Analysis of the communication volume of the consensus algorithm based on the RPBFT improvement of the present invention

[0070] In actual environments, the probability of Byzantine nodes appearing is very low, and the present invention realizes the election of trusted master nodes through the point reward mechanism. Since the credibility of the master node is guaranteed, the traditional PBFT consensus process can be reasonably simplified. Figure 3 As shown in the figure, 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 in a consensus round based on the improved RPBFT consensus algorithm is 3(N-1). If a view switch is triggered, the protocol switches to the PBFT protocol, and the total number of communications is 3N(N-1). Assuming the view switch probability is p, the number of communications of the improved RPBFT consensus algorithm is as follows:

[0071] ;

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

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

[0074] ;

[0075] Set different view switching probability values ​​0, 0.25, 0.33, and 0.5, and calculate the communication volume ratio of the two consensus algorithms under different numbers of nodes. Figure 4 As shown in the figure, when p = 0, the communication volume of the improved consensus algorithm based on RPBFT is significantly lower than that of the traditional PBFT consensus protocol. This is because the algorithm significantly reduces the number of messages exchanged between nodes during the consensus process by simplifying the prepare and commit phases without triggering view switches. In contrast, the communication complexity of traditional PBFT is higher, so the optimization effect of the improved algorithm is particularly significant in this scenario. When p > 0, as the view switch probability p increases, the communication volume of the improved algorithm gradually approaches that of PBFT. This is because when a view switch is triggered, the improved algorithm falls back to the standard PBFT process, which introduces higher communication overhead. However, since view switches are only triggered under specific conditions, the improved algorithm maintains good communication efficiency even at lower p. Overall, the communication volume ratio between the two algorithms decreases as p increases, but the improved algorithm still outperforms PBFT. Furthermore, as the number of nodes N increases, the communication volume of both algorithms increases with the node size, with PBFT increasing at a higher rate than the improved algorithm. Specifically, when the number of nodes is small, the communication volume ratio grows rapidly; as the number of nodes 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 optimization effect of this algorithm gradually decreases 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, the embodiment of the present invention provides an improved consortium chain consensus system based on RPBFT, including the following modules:

[0078] A node list building module 71 is used to sort and number consensus nodes and verification nodes and build a node list;

[0079] The consensus committee node list building module 72 is used to initialize the blockchain and select n1 nodes from the node list to build 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 initial consensus round or the initial consensus round after dynamic replacement. Subsequent master nodes are selected based on the highest score based on the point reward mechanism;

[0081] Execute the improved consensus algorithm module 74 to execute the improved consensus algorithm on the consensus committee nodes. If an abnormal situation such as verification failure or transaction processing timeout occurs, switch to the PBFT algorithm and restart the consensus;

[0082] Scoring module 75 is used to evaluate the performance of participating consensus committee nodes and increase corresponding points for consensus committee nodes using the point reward formula and time decay function;

[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 points of all nodes in the consensus committee node list are reset to zero.

[0084] A consortium chain 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 chain 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 implement an improved consortium chain consensus method, system, and device based on RPBFT.

[0086] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. 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 the present invention. Therefore, the present invention is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features of the present invention.

Claims

1. A consortium chain consensus method based on RPBFT improvement, characterized by: 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 based on the point reward mechanism; Step S4: Execute the improved consensus algorithm on the consensus committee nodes. If any abnormal situation occurs, such as verification failure or transaction processing timeout, switch to the PBFT algorithm and restart the consensus; Step S5: Evaluate the performance of the participating consensus committee nodes and apply the point reward formula and time decay function to increase the corresponding points for the consensus committee nodes; Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A verification 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 reset to zero.

2. The improved RPBFT-based alliance chain consensus method according to claim 1 is characterized in that: Step S1: sorting and numbering the consensus nodes and verification nodes to construct a node list, specifically including: All consensus nodes and verification nodes are randomly sorted. The sorted nodes are assigned an index according to their position in the node list. This index is the node number.

3. The improved RPBFT-based alliance chain consensus method according to claim 2 is characterized in that: Step S2: Initialize the blockchain and select n1 nodes from the node list to build a consensus committee node list, specifically including: Initialize the blockchain and select nodes with indexes from 0 to n1-1 from the node list to construct a consensus committee node list 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 improved RPBFT-based alliance chain consensus method according to claim 3 is 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, and subsequent master nodes are selected based on the highest score based on the point 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 so, 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 whether there are multiple nodes with the same highest 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 least number of times elected as master node as the master node. If they are the same, select the node with the highest ranking in the consensus node list as the master node, and jump to step S4.

5. The improved RPBFT-based alliance chain consensus method according to claim 4 is characterized in that: Step S4: Execute the improved consensus algorithm on the consensus committee nodes. If an abnormal situation such as verification failure or transaction processing timeout occurs, switch to the PBFT algorithm and restart the consensus, which specifically includes: Step S41: In the request phase, the client prepares a request message in the 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 the 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 number of the current view, n represents the unique sequence number assigned to the request, d represents the digest of the request, i.e., the hash value of the request, and m represents the request message. The master node then broadcasts the pre-prepare message to all backup nodes. The view is the term identifier of the master node, and master node rotation is achieved by incrementing the term. Step S43: In the prepare phase, after receiving the prepare message from the master node, each backup node verifies the signature and request digest of the message. If the verification is successful, the node enters the prepare phase and generates a prepare message <PREPARE, v,n, d, i>, where i represents the node ID number. The backup node broadcasts this message to the master node. After receiving prepare messages from other nodes, the master node verifies the prepare message. 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 prepare phase is completed. If the verification fails or the transaction times out, the node switches to the PBFT consensus process and re-consensus. Where f is the maximum number of Byzantine nodes that the system can tolerate, that is, the number of malicious or faulty nodes. Step S44: In the commit phase, when the master node determines that the request is ready, it generates a commit message <commit, v, n, d, i> and broadcasts it to all other backup nodes. After receiving the commit message from the master node, each backup node verifies it. If the verification passes, it jumps to step S45; otherwise, it switches to the PBFT consensus process. Step S45: Reply phase. After the confirmation phase, the backup node confirms that the request has reached consensus. At this point, 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 be confirmed that the request has been correctly processed and consensus has been reached, and the transaction is complete. Otherwise, it switches to the PBFT consensus process and re-consensus.

6. The improved RPBFT-based alliance chain consensus method according to claim 5 is characterized in that: Step S5: Evaluate the performance of the participating consensus committee nodes and use the point reward formula and time decay function to increase the corresponding points for the consensus committee nodes, specifically including: 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 β are weight parameters; Step S52: Points are awarded. After each round of consensus is completed, the nodes participating in the consensus will receive corresponding points adjustments based on their contributions and performance. The adjustment formula is as follows: ； in, is the integral of node i, is the historical integral of node i, Represents the evaluation of the master node's work, Represents the evaluation of the backup node's work; Step S53: Determine whether the current block is a multiple of n2. If so, jump to step S6. If not, determine whether there are any unpackaged transactions. If so, jump to step S3 and start a new round of master node selection and secondary consensus.

7. The improved RPBFT-based alliance chain consensus method according to claim 6 is characterized in that: Step S6: After every n2 blocks are generated, the consensus committee list is dynamically adjusted. A verification 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 reset to zero. Specifically, the following steps are performed: Step S61: Generate a pseudo-random output value using the master node’s private key and the current block ID through the VRF_Hash function ; The VRF_Hash function is as follows: ； in, is the private key of the current master node, is the ID of the current block, is the pseudo-random output value obtained; Step S62: The pseudo-random output value is calculated by a remainder function to obtain the remainder of the total number of verification nodes, thereby determining the serial number of a verification node. This node is selected as a new consensus committee node. The remainder function is as follows: ； 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: replacing the new consensus committee node with the node with the lowest score in the consensus committee node list; Step S64: clearing the points of all nodes in the consensus committee node list.

8. An improved alliance chain consensus system based on RPBFT, characterized by: Includes the following modules: Build a node list module, which is used to sort and number consensus nodes and verification nodes and build a node list; Construct a consensus committee node list module 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 initial consensus round or the initial consensus round after dynamic replacement. Subsequent master nodes are selected based on the highest score based on the point reward mechanism; Execute the improved consensus algorithm module and execute the improved consensus algorithm on the consensus committee nodes. If abnormal situations such as verification failure or transaction processing timeout occur, switch to the PBFT algorithm and restart the consensus; The scoring module is used to evaluate the performance of participating consensus committee nodes and increase the corresponding points for consensus committee nodes using the point reward formula and time decay function; The consensus committee node adjustment module is used to dynamically adjust the consensus committee list after each n2 block is generated. The 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 points of all nodes in the consensus committee node list are cleared.

9. An improved alliance chain consensus device based on RPBFT, characterized in that: The method comprises one or more electronic devices, wherein the one or more electronic devices are used to implement the method according to any one of claims 1 to 7.

10. 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 are enabled to implement the method according to any one of claims 1 to 7.

Images