A double-primary-node PBFT consensus method based on a credit mechanism

Abstract

The application belongs to the technical field of block chain, and particularly relates to a double-master-node dynamic PBFT consensus method based on a credit mechanism. First, a node division scheme is designed, initial selection nodes are selected, and a consensus node set is obtained through screening; then, a double-master-node dynamic PBFT consensus protocol is designed, two master nodes supervise and cooperate with each other, consensus is performed on new transaction information, and a legal block is formed to be entered into a chain; finally, a node credit evaluation model is designed, the credit of a node is evaluated according to the consensus behavior of the node, the consensus node set is updated and the consensus master node is replaced, and preparation is made for transaction consensus in the next period. The application is suitable for the technical field of industrial internet and block chain, can reduce the probability of a byzantine node being selected as a consensus node, reduce the view replacement probability and the communication frequency between consensus nodes, improve the security and consensus efficiency of a block chain system, and improve the scalability and robustness of an industrial internet data storage system.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a dual-master node PBFT consensus method based on a credit mechanism. Background Technology

[0002] With the rapid development of electronics, communications, and network technologies, the Industrial Internet is emerging as an intelligent network characterized by widespread networking of large-scale industrial terminals and sensors, and data-driven decision-making. The intelligent evolution of the Industrial Internet exacerbates the demand for the generation, transmission, storage, and computation of massive amounts of industrial data. Traditional centralized cloud architectures struggle to handle such large-scale data processing needs and meet the low-latency constraints of devices. Distributed network architectures combining cloud and edge computing support data exchange and business processing at the network edge, effectively alleviating resource pressure on cloud centers and reducing service latency. However, distributed network architectures face numerous security risks, including difficulties in managing and coordinating terminal access, low security defense capabilities of edge clouds, and vulnerability to data theft and tampering. These challenges pose significant hurdles to the secure operation of the Industrial Internet.

[0003] Blockchain technology, based on consensus mechanisms, offers new solutions to data security issues in the distributed industrial internet due to its advantages such as decentralization, on-chain data immutability, and traceability. However, existing consensus algorithms, such as the classic PBFT algorithm, suffer from low efficiency and security in blockchain-integrated industrial internet applications, primarily including:

[0004] (1) A single consensus master node may abuse its power, which may lead to data consensus security risks;

[0005] (2) The lack of an effective consensus node credit assessment mechanism makes it difficult to deal with malicious nodes in a timely manner, resulting in a high risk to system security.

[0006] (3) The consensus protocol has many processes and high communication complexity, making it unsuitable for industrial internet scenarios with massive data.

[0007] Patent document CN114448980B discloses an improved method for the PBFT algorithm for the Internet of Things. Although it solves the problem of consensus failure caused by the master node being a Byzantine node, in which the master node is responsible for handling block consensus and consensus candidate nodes are responsible for supervising the legality of the master node's consensus behavior, and the supervision method requires completing all consensus processes of the master node and finally concluding the consensus of the master node; however, this improved method ignores the security of other consensus nodes; secondly, the proposed integral mode only considers the consensus behavior of nodes and ignores indicators such as consensus latency; in addition, the consensus process is redundant and the communication complexity is too high. Summary of the Invention

[0008] To address the problems existing in the aforementioned background technologies, this invention introduces a dual-master node strategy and a dynamic credit update mechanism to enhance the security of blockchain data storage in the Industrial Internet, proposing a dual-master node PBFT consensus method based on a credit mechanism. This scheme first designs a node partitioning scheme to select initial nodes, then filters them to obtain a consensus node set. Next, a dual-master node dynamic PBFT consensus protocol is designed, where the two master nodes supervise and collaborate with each other, reaching consensus on newly generated transaction information to form legitimate blocks for blockchain entry. Finally, a node credit evaluation model is designed to assess the credit of nodes based on their consensus behavior, thereby updating the consensus node set and replacing the consensus master node, preparing for the next cycle of transaction consensus. This invention is applicable to blockchain-integrated Industrial Internet application scenarios, reducing the probability of Byzantine nodes being selected as consensus nodes, decreasing the probability of view replacement and the number of communications between consensus nodes, improving the security and consensus efficiency of the blockchain system, and enhancing the scalability and robustness of the Industrial Internet data storage system.

[0009] like Figure 1 As shown, the specific steps of the dual-master node PBFT consensus method based on a credit mechanism described in this invention are as follows:

[0010] Step 1, Initialization Phase: Design a trusted node entry strategy to ensure the safe addition of nodes to the blockchain system and construct an initial node set; filter the initial node set to generate a consensus node set; design a dynamic node exit strategy to manage the exit of nodes in the blockchain system.

[0011] Step 2, Block Consensus Phase: A dual-master node dynamic PBFT consensus protocol is designed. The two master nodes supervise and collaborate with each other, packaging newly generated transaction information into proposed blocks for consensus. Successful consensus results in blocks being recorded as valid blocks in the blockchain ledger. The dual-master node dynamic PBFT consensus protocol includes:

[0012] The client packages each transaction message into a "request message" and sends it to the consensus master node P2. Master node P2 verifies and sorts the "request messages" and stores them in the transaction pool. Then, it packages w messages from the pool to generate a proposal block and sends it to all consensus replica nodes and master node P1. Each replica node and master node P1 independently verifies the legality of each message in the proposal block, generates a verification message, and sends it to master node P1. If master node P1 finds inconsistencies in the public information (proposal block M, block height h, view number v) of more than 1 / 3 of the verification messages, it determines that master node P2 is malicious and initiates a request to the cloud center to replace master node P2 and a view replacement request. Otherwise, it stores the transaction information verified by more than 1 / 3 of the replica nodes into the pending chain block and sends it to all consensus replica nodes and master node P2. If a replica node does not accept the pending chain block, it initiates a view replacement request to master node P2. If it accepts the block, it writes it into the local blockchain ledger. If master node P2 receives more than 2 / 3 of the view replacement requests, it determines that master node P1 is malicious. If consensus fails in this round, a request to replace master node P1 and view change is initiated to the cloud center. If more than 2 / 3 of the view change requests are not received within a timeout, consensus is considered successful, and the blocks to be added to the chain are recorded in the blockchain ledger. The triggering conditions for initiating view change during consensus also include: when a consensus node applies to leave the system, the consensus master node sends a node exit message to the cloud center and simultaneously sends a consensus view change request; if a consensus replica node does not receive a message from master node P1 (P2) within a timeout, it considers that consensus master node P1 (P2) may be malicious or faulty, and the replica node initiates a request to replace master node P1 (P2) to master node P2 (P1); when master node P2 (P1) counts that more than 2 / 3 of the replica nodes have initiated requests to replace master node P1 (P2), it sends a message to the cloud center to replace master node P1 (P2) and a view change request; when the preset time for node credit update expires, meaning that K rounds of block consensus have been completed consecutively, consensus master node P1 sends a node credit update message and a consensus view change request to the cloud center.

[0013] Step 3, Credit Update Phase: Design a node credit assessment model. After each credit update cycle T, i.e., after completing K rounds of block consensus, the cloud center reassesses the credit value of each node and dynamically updates the consensus node set to improve the security of subsequent transaction consensus.

[0014] It should be noted that the node mentioned in step 1 is an industrial internet terminal device or an edge network node; the initial selection node is a node that meets the blockchain capability requirements, that is, a node with certain computing and storage capabilities and basic credit standards, also known as a blockchain node.

[0015] Given that a large number of sensing and execution terminal devices in the Industrial Internet lack sufficient computing and storage capabilities and cannot perform the function of initial selection nodes, proxy nodes are introduced to manage these terminal devices. This invention adopts a cloud-edge collaborative Industrial Internet architecture, where proxy nodes are designated by the upper-layer cloud center as mobile edge network nodes, responsible for verifying whether terminal devices can become blockchain nodes, i.e., initial selection nodes.

[0016] It should be noted that, as Figure 2 As shown, the concepts of the initial node set and the consensus node set are explained in detail below:

[0017] The initial node set refers to the set of nodes composed of initial nodes; proxy nodes, as trusted nodes, directly enter the initial node set, and terminals with certain storage capacity can only enter the initial node set after being verified as trusted nodes by their associated proxy nodes.

[0018] The consensus node set refers to the collection of network nodes that participate in the consensus of transaction data. The consensus nodes are selected from the initial node set. The consensus node set includes two consensus master nodes and the remaining consensus nodes are consensus replica nodes.

[0019] Consensus Master Nodes: Responsible for coordinating and managing the transaction data consensus process. The two consensus master nodes in the consensus node set are called master node P1 and master node P2. Master node P2 is responsible for verifying, sorting, and packaging transactions to generate proposal blocks. Master node P1 is responsible for: 1. Supervising master node P2, verifying the legality of its proposed blocks, and reducing the consensus risk of P2 being a Byzantine node; 2. Statistics on the verification results of all transactions in the block by each replica node, generating the final on-chain block.

[0020] Consensus replica nodes: responsible for voting on the authenticity and validity of transaction data, verifying the legality of transactions, and forwarding voting information.

[0021] Furthermore, in step 1, the trusted node entry strategy is described as follows:

[0022] When a node i requests to join the blockchain system, it sends a join request message to its surrounding proxy nodes. This message contains the number of CPU cores (Cpu) of node i. i Hard drive capacity Stor i Information such as;

[0023] Upon receiving the request, the proxy node checks if any other proxy nodes have already agreed to the node joining. If so, it ignores the request; otherwise, it verifies whether the node meets the requirements for joining the blockchain network.

[0024] Check if the node's IP is in the whitelist maintained by all proxy nodes. If not, node i has a security risk and its access request is rejected. If yes, the proxy node calculates the node's basic credit value S according to equation (1). i :

[0025]

[0026] Among them, CPU i Indicates the number of CPU cores in node i; Cpu min CPU max These represent the minimum and maximum number of CPU cores, respectively; Stor i Stor is the computer memory capacity of node i. min Stor max These represent the minimum and maximum values ​​of the computer's memory capacity, respectively.

[0027] If the basic credit value of node i is S i Exceeding the credit threshold S min S i ≥S min The node is authenticated as a trusted node, and the proxy node sends a network access permission to node i.

[0028] If node i receives a network access permission from a single proxy node, it sends a network access confirmation message to that proxy node; if node i receives network access permission from multiple proxy nodes at the same time, it randomly selects a proxy node to associate with and sends a network access confirmation message to that proxy node.

[0029] After receiving the network access confirmation message from node i, the proxy node broadcasts node i's network access message to other proxy nodes, and simultaneously updates node i's network access status and basic credit value S in the whitelist. i The updated whitelist will be simultaneously reported to the cloud center.

[0030] A node that successfully joins the blockchain network automatically becomes a preliminary node and enters the preliminary node set.

[0031] Furthermore, the method for generating the consensus node set in step 1 is described below:

[0032] Step 1a: The cloud center sorts all the initial nodes in descending order of their basic credit values ​​and selects the two nodes with the highest credit values ​​as consensus master nodes P1 and P2; Master node P1 broadcasts a consensus invitation message to the other nodes in the initial node set.

[0033] Step 1b: The first N initial nodes that respond to the invitation from master node P1 are sorted from high to low based on their basic credit value. Master node P1 selects the first M nodes as consensus replica nodes. Together with the two master nodes, they form the consensus node set for the current stage.

[0034] Furthermore, in step 1, the dynamic node exit strategy is described as follows:

[0035] If a consensus replica node intends to leave the consensus node set, it directly applies to either of the two master nodes. After the master node agrees, it sends the node exit message to the other consensus nodes. The replica node successfully exits and returns to the initial node set.

[0036] If a consensus master node intends to leave the consensus node set, it needs to initiate a request to re-elect a master node. After the new master node election is completed, the master node becomes a replica node and leaves the consensus node set as a replica node, returning to the initial node set.

[0037] If a node in the initial selection intends to leave the blockchain system, it sends a request to its proxy node to leave. Upon receiving the request, the proxy node returns a message agreeing to the departure and broadcasts it to other nodes. Then, it deletes the node's attribute information stored locally, and the node successfully leaves the system.

[0038] Furthermore, the dual-master node PBFT consensus protocol described in step 2 specifically includes five stages: request, preparation, verification, decision, and completion. The tasks of each stage are described in detail below:

[0039] Step 2a, the request phase, involves the client packaging its own transaction information or the transaction information of several terminal devices it manages into a "request message" R. req Send to consensus master node P2; record client c i The consensus request message sent is R req (c i The message format is as follows:

[0040]

[0041] Where REQUEST is the message type identifier for a "request message"; R req (c i ,j) represents client c i The j-th R generated req information; Indicates client c i The generated j-th transaction information, where tm ij For transaction data, Generate timestamps for transactions; t ij Representing client c i Send the timestamp of the j-th transaction. For client c i The signature.

[0042] A client refers to a blockchain node that sends transaction information; transaction data generated by non-blockchain nodes is generated as transaction messages R by their associated proxy nodes acting as clients. req send.

[0043] Step 2b, preparation phase: Master node P2 receives R from the client. req After the message, based on the signature δ ci Verify R req Client c in the message i Identity verification is successful; a timestamp is generated based on the transaction. For R req After the messages are sorted, they are stored in the local transaction pool to await consensus; then, master node P2 retrieves w R messages from the transaction pool. req The message is packaged to generate a proposal block M, and R is used. pre The message format is sent to all consensus replica nodes; R pre The message format is:

[0044]

[0045] M={(n1,R req,1 ,t r,1 ),(n2,R req,2 ,t r,2 ),...,(n w ,R req,w ,t r,w (4)

[0046] Where PREPARE represents the message type identifier for "preparing message"; v represents the consensus view number, where a view refers to a set of consensus processes completed consecutively by the same set of consensus nodes. Once a consensus node is replaced, the view number increments by 1; h represents the height of the next block in the blockchain, i.e., the number of blocks already on the chain plus 1. M represents the proposal block generated by consensus master node P2, as shown in equation (4); where n k ,1≤k≤w represents R pre The message contains the k-th request message, namely R. req,k In the message pool, w represents the total number of request messages contained in the current proposal block, i.e., the number of transaction messages awaiting consensus, where 100 ≤ w ≤ 1000; t r,k This indicates that master node P2 has received R req,k The message timestamp This indicates that master node P2 sends R. pre The message's timestamp; P2 indicates that the preparation message was sent by the master node P2; This represents the signature of the master node P2.

[0047] Step 2c, Verification Phase: Each consensus replica node receives the preparation message R sent by the master node P2. pre And independently verify R pre The validity of each request message contained in the proposed block M is verified. If the message is valid, it is recorded as 1; otherwise, it is invalid and recorded as 0. When all request messages in the proposed block M have been verified, the consensus replica node generates a verification message R. che And send it to the master node P1. Record the consensus replica node u for R. pre The generated verification message is R che,u The message format is as follows:

[0048]

[0049] Where CHECK represents the message type identifier for "verification message"; the meanings of v, M, and h are the same as in equation (3); θ = [θ1, θ2, ..., θ w ] represents the decision result of the proposed block M, θ k =0, 1≤k≤w indicates that the k-th request message in M ​​is invalid, θ k =1 indicates that the k-th request message has been verified as valid; t fs,u This indicates that replica node u sends R. che,u Message timestamp; δ u This represents the signature of replica node u.

[0050] The consensus master node P1 verifies the legality of the request message in the proposal block M locally using the same judgment method, and obtains the local judgment result θ. loc =[θ loc,1 ,θ loc,2 ,...,θ loc,w ].

[0051] Step 2d, Judgment Phase: The consensus master node P1 receives the verification message R from each replica node. che,u And record its receiving time as t locally. r,u Then, the number of valid votes for each request message in the proposal block M is counted. If a request message is verified as valid by more than 1 / 3 of the consensus nodes, the request message is determined to be a valid message and the transaction data it contains is valid; otherwise, the request message is determined to be an invalid message and the transaction data it contains is invalid.

[0052] For request messages that are verified as invalid, master node P1 removes them from the proposal block M to generate the block to be added to the chain for this round of consensus. Simultaneously generate a judgment message R cmt Send to each consensus replica node so that the replica nodes can verify the block to be added to the chain generated by the master node P1. Is it legal? To prevent malicious intent from master node P1; R cmt The message format is as follows:

[0053]

[0054] Here, COMMIT represents the message type identifier for "commit message"; These represent the master node P1 sending R. cmt The message's timestamp and the signature of consensus master node P1.

[0055] It is divided into two parts: the head and the body, such as Figure 4 As shown, the block header contains the block generation timestamp t. b Block head hash head The block height h, view number v, and master node ID in equation (5); the block body contains the block body hash. body And a packaged sequence of valid transactions, which records the transaction sequence number n. k ,1≤k≤w, transaction content tm, transaction generation timestamp t tm The four parameters, including the check state θ, can be determined from R. che,u Message retrieval; Hash body The block hash is the hash value obtained by hashing the entire transaction sequence; the block header hash is... head =H(h,v,P) i ,t b Hash body ) is composed of h, v, P i ,t b Hash body The hash calculation is performed using five parameters, and its purpose is to ensure the uniqueness and security of the block.

[0056] Step 2e, Completion Phase: Each consensus replica node verifies the R sent by the master node P1. cmt The message will be added to the blockchain. The θ corresponding to n and the locally generated R che,u The message compares θ with n. If they are the same, the replica nodes accept the decision of the primary node P1; if they are different, the replica nodes consider the primary node P1 to pose a security risk and send a request to the primary node P2 to replace the primary node P1. If the primary node P2 counts that more than 2 / 3 of the replica nodes have initiated requests to replace the primary node P1, it determines that the primary node P1 is a Byzantine node and sends a message to the cloud center. View Change The request is simultaneously broadcast to the replica nodes to rescind the block. Incoming message: This round of block consensus has failed.

[0057] If master node P2 does not receive a request to change master node from more than 2 / 3 of the consensus replica nodes within the specified time limit, the consensus round is successful, and consensus master node P2 broadcasts the consensus block to the entire network. All blockchain nodes will block Once added to the local ledger, this round of consensus is complete.

[0058] At this point, even if a malicious consensus replica node wanted to tamper with transaction records and save a malicious block, it would be impossible. This is because the hash algorithm has collision-resistant properties; after the transaction is modified, the hash value calculated for the new transaction sequence will match the hash value of the incoming block. The block hash values ​​recorded in the middle are inconsistent.

[0059] Therefore, during the consensus process, the view replacement triggering conditions include:

[0060] (1) During the consensus process, when a consensus node applies to leave the system, the consensus master node sends a node exit message to the cloud center and simultaneously sends a consensus view replacement request.

[0061] (2) During the consensus decision phase, the master node P1 receives verification messages R from each consensus replica node for the same proposed block. che,u More than 1 / 3 of R che,u The public information in the message, such as M and h, is inconsistent, and the master node P2 is suspected of being malicious. The master node P1 sends a request to the cloud center to replace the master node P2 and a request to replace the consensus view.

[0062] (3) During the consensus completion phase, the consensus replica nodes do not recognize the R of the master node P1. cmt The message indicates that the primary node P1 may be malicious, and sends a request to primary node P2 to replace primary node P1; primary node P2 counts that more than 2 / 3 of the replica nodes have initiated the request to replace primary node P1, determines that primary node P1 is a Byzantine node, and then sends a message to the cloud center to replace primary node P1 and a request to replace view.

[0063] (4) During the consensus process, if a consensus replica node does not receive a message from the master node P1 (P2) after a timeout, it assumes that the consensus master node P1 (P2) may be malicious or faulty. The replica node then initiates a request to the master node P2 (P1) to replace the master node P1 (P2). The master node P2 (P1) counts that more than 2 / 3 of the replica nodes have initiated the request to replace the master node P1 (P2), and then sends a message to the cloud center to replace the master node P1 (P2) and a request to replace the view.

[0064] (5) When the node credit update time is up, that is, K rounds of block consensus have been completed, the consensus master node P1 sends a node credit update message and a request to change the consensus view to the cloud center.

[0065] Furthermore, the consensus view is managed by the upper-layer cloud center, and the specific description of the consensus view replacement operation is as follows:

[0066] The consensus master node initiates a view change request to the upper-layer cloud center; the cloud center verifies whether the received view change request is accompanied by a node credit update message or a consensus node exit request:

[0067] If a node credit update message is present, the cloud center updates the node credit according to the node credit assessment model, selects the consensus master node and consensus replica node according to the dynamic update consensus node set method, and then broadcasts the new consensus node set information and view replacement instructions to the consensus nodes to execute the consensus view replacement.

[0068] If there is no node credit update message but there is a request for exit / replacement of consensus master node P1, the cloud center designates the current master node P2 as the new consensus master node P1′, selects the consensus replica node with the highest current credit as the new master node P2′, and selects the candidate node with the highest current credit to fill the gap in the consensus node set; then the new master node information, the new consensus node information and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement.

[0069] If there is no node credit update message but there is a request for exit / replacement of consensus master node P2, the cloud center selects the consensus replica node with the highest current credit as the new master node P2′, and selects the candidate node with the highest current credit to fill the gap in the consensus node set; then the new master node information, the new consensus node information and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement.

[0070] If there is no node credit update message but there is a consensus replica node exit request, the cloud center selects the candidate node with the highest current credit to enter the consensus node set to fill the gap, and then sends the new consensus node information and view replacement instructions to all consensus nodes to execute the consensus view replacement.

[0071] Upon receiving the view change instruction, all consensus nodes increment their view number by 1, preparing to enter a new round of consensus process, i.e., executing step 2.

[0072] Furthermore, the node credit assessment model is described in detail below:

[0073] A node's credit update relies on its consensus behavior data within a credit assessment cycle, including consensus revenue, latency performance, and historical credit value. The node's consensus behavior data is recorded in the corresponding consensus view, which is jointly managed by the consensus master node and the cloud center. The cloud center can evaluate and update the node's credit value by calling the consensus view data.

[0074] Let a node's credit assessment period T go through K rounds of block consensus. After each K rounds of block consensus, the consensus reward, latency performance, and historical credit value of each node in a credit update period are defined and calculated as follows:

[0075] Consensus Reward: Refers to the credit gain a node receives for participating in block consensus within a credit update cycle. Node i's consensus reward B i The calculation formula is as follows:

[0076]

[0077] in, This represents the positive incentive portion, where α is the reward factor and ε1 controls the growth rate of the positive incentive curve. This represents the negative penalty component, where β is the penalty factor and ε² controls the growth rate of the negative penalty curve; N total =gw represents the total number of transactions verified by consensus node i within the credit update period T, g,1≤g≤w represents the number of blocks in which consensus node i participates in consensus within the credit update period T, and w represents the number of transactions contained in the proposal block M packaged by master node P1; N T This indicates the total number of transactions correctly verified by consensus node i within the credit update cycle T. The cloud center compares these transactions with the blocks. The θ and each R stored in che,u The sum of the total number of transactions with the same θ in the message is N. T N F =N total -N T This represents the total number of incorrectly verified transactions by consensus node i within the credit update cycle T.

[0078] Equation (7) shows that the more times a node successfully verifies a transaction, the higher its credit value and the better its security; conversely, the lower its credit value and the worse its security.

[0079] Latency performance: refers to the time it takes for a node to respond to the preparation message R sent by the master node P2 during the consensus process. pre And send back the master node P1 verification message R che The latency level. The latency performance D of consensus node i. i Calculated from equation (8):

[0080]

[0081] in, This represents the consensus latency of consensus node i for the j-th block. The consensus latency refers to the time from when master node P2 sends the preparation message R during the preparation phase. pre During the judgment phase, master node P1 receives the verification message R from consensus node i. che The time taken; d max=max(d ij ) represents the maximum consensus latency of consensus node i within this credit period; g represents the number of blocks in which consensus node i participates in consensus within the credit update period T, 1≤g≤w.

[0082] Consensus reward B based on node i i Delay performance D i And the credit score C from the previous credit assessment period. i The cloud center reassesses the current credit value C of node i according to equation (9). i for

[0083]

[0084] Where α, β, γ, and μ are weighting factors, and α+β+γ+μ=1. The values ​​of α, β, γ, and μ depend on the preferences of the blockchain system. For example, if the system attaches more importance to consensus benefits, α+β∈[0.5,0.8] and γ+μ∈[0.2,0.5].

[0085] It should be noted that all nodes, including the initial selection nodes and consensus nodes, participate in the credit update.

[0086] Furthermore, the method for dynamically updating the consensus node set described in step 3 is explained in detail below:

[0087] After the node credit assessment is completed, the cloud center sorts all nodes in descending order of their current credit value, with those having a credit value below the credit threshold S. min A node is directly kicked out of the blockchain system by its proxy node. After a period of time, the kicked-out node can reapply to the proxy node to join the initial node set. The cloud center selects the top M+2 nodes with the highest credit from the current initial node set as consensus nodes and enters the consensus node set. It also selects the two consensus nodes with the highest credit values ​​in the consensus node set as consensus master nodes P1 and P2 respectively, and broadcasts the new consensus node set to all nodes to prepare for a new round of consensus process.

[0088] Compared with the prior art, the present invention has the following advantages:

[0089] This invention employs a dual-master node mutual supervision and checks and balances strategy. Master node P2 generates proposal blocks, while master node P1 supervises and verifies the legality of the blocks before they are added to the chain. This avoids the excessive concentration of power in the master node of traditional single-master node systems, reducing the security risks of data consensus. For master nodes with security risks, a view replacement protocol based on the exit of all consensus nodes and credit update optimization, including a master node exit mechanism, is provided. This improves system security while ensuring system consistency and availability. Compared to traditional view optimization protocols that only consider one master node, the system offers higher consistency and practicality.

[0090] The node credit scoring mechanism provided in the preferred embodiment of the present invention evaluates the node credit value by combining the node's initial credit value and consensus performance, and dynamically updates the consensus node set to improve the reliability of consensus nodes and further enhance the security and robustness of the blockchain system. Attached Figure Description

[0091] Figure 1 This is a flowchart illustrating the implementation process of a dual-master node PBFT consensus method based on a credit mechanism according to the present invention.

[0092] Figure 2 This is a node classification diagram in an example of the present invention;

[0093] Figure 3 This is a flowchart of the improved PBFT consensus algorithm in an example of the present invention;

[0094] Figure 4 This is a schematic diagram of the block data structure in an example of the present invention. Detailed Implementation

[0095] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings.

[0096] The PBFT consensus method based on a credit mechanism described in this invention comprises the following steps:

[0097] Step 1, Initialization Phase: Design a trusted node entry strategy to ensure the safe addition of nodes to the blockchain system and construct an initial node set; filter the initial node set to generate a consensus node set; design a dynamic node exit strategy to manage the exit of nodes in the blockchain system.

[0098] like Figure 2 As shown, the node mentioned in step 1 is an industrial internet terminal device or an edge network node; the initial selection node is a node that meets the blockchain capability requirements, that is, a node with certain computing and storage capabilities and basic credit standards, also known as a blockchain node.

[0099] Given that a large number of sensing and execution terminal devices in the Industrial Internet lack sufficient computing and storage capabilities and cannot perform the function of initial selection nodes, proxy nodes are introduced to manage these terminal devices. This invention adopts a cloud-edge collaborative Industrial Internet architecture, where proxy nodes are designated by the upper-layer cloud center as mobile edge network nodes, responsible for verifying whether terminal devices can become blockchain nodes, i.e., initial selection nodes.

[0100] The initial node set refers to the set of nodes composed of initial nodes; proxy nodes, as trusted nodes, directly enter the initial node set, and terminals with certain storage capacity can only enter the initial node set after being verified as trusted nodes by their associated proxy nodes.

[0101] The consensus node set refers to the collection of network nodes that participate in the consensus of transaction data. The consensus nodes are selected from the initial node set. The consensus node set includes two consensus master nodes and the remaining consensus nodes are consensus replica nodes.

[0102] Consensus Master Nodes: Responsible for coordinating and managing the transaction data consensus process. The two consensus master nodes in the consensus node set are called master node P1 and master node P2. Master node P2 is responsible for verifying, sorting, and packaging transactions to generate proposal blocks. Master node P1 is responsible for: 1. Supervising master node P2, verifying the legality of its proposed blocks, and reducing the consensus risk of P2 being a Byzantine node; 2. Statistics on the verification results of all transactions in the block by each replica node, generating the final on-chain block.

[0103] Consensus replica nodes: responsible for voting on the authenticity and validity of transaction data, verifying the legality of transactions, and forwarding voting information.

[0104] For example, in a smart factory system based on a cloud-edge collaborative architecture, the system mainly consists of a perception layer, an edge layer, and a cloud layer. The perception layer is primarily responsible for sensing and uploading data. Specifically, it includes 80 intelligent terminals with computing and storage capabilities, such as CNC lathes, industrial computers, and robots, and 100 terminals without computing and storage capabilities, such as various sensors, robotic arms, electric valves, barcode scanners, and ordinary monitoring equipment. The edge layer is responsible for real-time data processing and analysis locally, for example, by setting up 6 edge nodes. The cloud layer is mainly responsible for large-scale data storage and analysis, and global control of the factory, with only one cloud center node. The initial node set can be constructed by first selecting approximately 60 nodes from the terminal nodes, edge nodes, and cloud center nodes, and then selecting a consensus node set of approximately 20 nodes from this initial set. The consensus node set includes 2 consensus master nodes and 18 consensus replica nodes.

[0105] Step 1-1, Design a trusted node entry strategy:

[0106] When a node i requests to join the blockchain system, it sends a join request message to its surrounding proxy nodes. This message contains the number of CPU cores (Cpu) of node i. i Hard drive capacity Stor i Information such as;

[0107] Upon receiving the request, the proxy node checks if any other proxy nodes have already agreed to the node joining. If so, it ignores the request; otherwise, it verifies whether the node meets the requirements for joining the blockchain network.

[0108] Check if the node's IP is in the whitelist maintained by all proxy nodes. If not, node i has a security risk and its access request is rejected. If yes, the proxy node calculates the node's basic credit value S according to equation (1). i :

[0109]

[0110] Among them, CPU i Indicates the number of CPU cores in node i; Cpu min CPU max These represent the minimum and maximum number of CPU cores, respectively; Stor i Stor is the computer memory capacity of node i. min Stor max These represent the minimum and maximum values ​​of the computer's memory capacity, respectively.

[0111] If the basic credit value of node i is S i Exceeding the credit threshold S min S i ≥S min The node is authenticated as a trusted node, and the proxy node sends a network access permission to node i.

[0112] If node i receives a network access permission from a single proxy node, it sends a network access confirmation message to that proxy node; if node i receives network access permission from multiple proxy nodes at the same time, it randomly selects a proxy node to associate with and sends a network access confirmation message to that proxy node.

[0113] After receiving the network access confirmation message from node i, the proxy node broadcasts node i's network access message to other proxy nodes, and simultaneously updates node i's network access status and basic credit value S in the whitelist. i The updated whitelist will be simultaneously reported to the cloud center.

[0114] A node that successfully joins the blockchain network automatically becomes a preliminary node and enters the preliminary node set.

[0115] In steps 1-2, a consensus node set is generated:

[0116] Step 1-2(a): The cloud center sorts all the initial nodes in descending order of their basic credit values ​​and selects the two nodes with the highest credit values ​​as consensus master nodes P1 and P2; Master node P1 broadcasts a consensus invitation message to the other nodes in the initial node set.

[0117] In step 1-2(b), the first N initial nodes that respond to the invitation of master node P1 are sorted from high to low according to their basic credit value. Master node P1 selects the first M nodes as consensus replica nodes. Together with the two master nodes, they form the consensus node set for the current stage.

[0118] Steps 1-3, Exiting Dynamic Nodes:

[0119] If a consensus replica node intends to leave the consensus node set, it directly applies to either of the two master nodes. After the master node agrees, it sends the node exit message to the other consensus nodes. The replica node successfully exits and returns to the initial node set.

[0120] If a consensus master node intends to leave the consensus node set, it needs to initiate a request to re-elect a master node. After the new master node election is completed, the master node becomes a replica node and leaves the consensus node set as a replica node, returning to the initial node set.

[0121] If a node in the initial selection intends to leave the blockchain system, it sends a request to its proxy node to leave. Upon receiving the request, the proxy node returns a message agreeing to the departure and broadcasts it to other nodes. Then, it deletes the node's attribute information stored locally, and the node successfully leaves the system.

[0122] Step 2, Block Consensus Phase: A dual-master node dynamic PBFT consensus protocol is designed. The two master nodes supervise and collaborate with each other, packaging newly generated transaction information into proposal blocks for consensus. Successful consensus results in these blocks being recorded as valid blocks in the blockchain ledger. Figure 3 As shown, the dual-master node PBFT consensus protocol described in step 2 includes five stages: request, preparation, verification, decision, and completion. The specific tasks of each stage are described below:

[0123] Step 2a, the request phase, involves the client packaging its own transaction information or the transaction information of several terminal devices it manages into a "request message" R. req Send to consensus master node P2; record client c i The consensus request message sent is R req (c i The message format is as follows:

[0124]

[0125] Where REQUEST is the message type identifier for a "request message"; R req (c i ,j) represents client c i The j-th R generated req information; Indicates client c i The generated j-th transaction information, where tm ij For transaction data, Generate timestamps for transactions; t ij Representing client c i Send the timestamp of the j-th transaction. For client c i The signature.

[0126] A client refers to a blockchain node that sends transaction information or a proxy node associated with a non-blockchain node that generates transaction data. In other words, transaction data generated by a non-blockchain node is generated into transaction messages R by its associated proxy node acting as a client. req send.

[0127] Step 2b, preparation phase: Master node P2 receives R from the client. req After the message, based on the signature Verify R req Client c in the message i Identity verification is successful; a timestamp is generated based on the transaction. For R req After the messages are sorted, they are stored in the local transaction pool to await consensus; then, master node P2 retrieves w R messages from the transaction pool. req The message is packaged to generate a proposal block M, and R is used. pre The message format is sent to all consensus replica nodes; R pre The message format is:

[0128]

[0129] M={(n1,R req,1 ,t r,1 ),(n2,R req,2 ,t r,2 ),...,(n w ,R req,w ,t r,w (4)

[0130] Where PREPARE represents the message type identifier for "preparing message"; v represents the consensus view number, where a view refers to a set of consensus processes completed consecutively by the same set of consensus nodes. Once a consensus node is replaced, the view number increments by 1; h represents the height of the next block in the blockchain, i.e., the number of blocks already on the chain plus 1. M represents the proposal block generated by consensus master node P2, as shown in equation (4); where n k ,1≤k≤w represents R pre The message contains the k-th request message, namely R. req,k In the message pool, w represents the total number of request messages contained in the current proposal block, i.e., the number of transaction messages awaiting consensus, where 100 ≤ w ≤ 1000; t r,k This indicates that master node P2 has received R req,k The message timestamp This indicates that master node P2 sends R. preThe message's timestamp; P2 indicates that the preparation message was sent by the master node P2; This represents the signature of the master node P2.

[0131] Step 2c, Verification Phase: Each consensus replica node receives the preparation message R sent by the master node P2. pre And independently verify R pre The validity of each request message contained in the proposed block M is verified. If the message is valid, it is recorded as 1; otherwise, it is invalid and recorded as 0. When all request messages in the proposed block M have been verified, the consensus replica node generates a verification message R. che And send it to the master node P1. Record the consensus replica node u for R. pre The generated verification message is R che,u The message format is as follows:

[0132]

[0133] Where CHECK represents the message type identifier for "verification message"; the meanings of v, M, and h are the same as in equation (3); θ = [θ1, θ2, ..., θ w ] represents the decision result of the proposed block M, θ k =0, 1≤k≤w indicates that the k-th request message in M ​​is invalid, θ k =1 indicates that the k-th request message has been verified as valid; t fs,u This indicates that replica node u sends R. che,u Message timestamp; δ u This represents the signature of replica node u.

[0134] The consensus master node P1 verifies the legality of the request message in the proposal block M locally using the same verification method, and obtains the local verification result θ. loc =[θ loc,1 ,θ loc,2 ,...,θ loc,w ].

[0135] Step 2d, Judgment Phase: The consensus master node P1 receives the verification message R from each replica node. che,u And record its receiving time as t locally. r,u Then, the number of valid votes for each request message in the proposal block M is counted. If a request message is verified as valid by more than 1 / 3 of the consensus nodes, the request message is determined to be a valid message and the transaction data it contains is valid; otherwise, the request message is determined to be an invalid message and the transaction data it contains is invalid.

[0136] For request messages that are verified as invalid, master node P1 removes them from the proposal block M to generate the block to be added to the chain for this round of consensus. Simultaneously generate a judgment message R cmt Send to each consensus replica node so that the replica nodes can verify the block to be added to the chain generated by the master node P1. Is it legal? To prevent malicious intent from master node P1; R cmt The message format is as follows:

[0137]

[0138] Here, COMMIT represents the message type identifier for "commit message"; These represent the master node P1 sending R. cmt The message's timestamp and the signature of consensus master node P1.

[0139] like Figure 4 As shown, It consists of two parts: a block header and a block body. The block header contains the block generation timestamp t. b Block head hash head The block height h, view number v, and master node ID in equation (5); the block body contains the block body hash. body And a packaged sequence of valid transactions, which records the transaction sequence number n. k ,1≤k≤w, transaction content tm, transaction generation timestamp t tm The four parameters, including the check state θ, can be determined from R. che,u Message retrieval; Hash body The block hash is the hash value obtained by hashing the entire transaction sequence; the block header hash is... head =H(h,v,P) i ,t b Hash body ) is composed of h, v, P i ,t b Hash body The hash calculation is performed using five parameters, and its purpose is to ensure the uniqueness and security of the block.

[0140] Step 2e, Completion Phase: Each consensus replica node verifies the R sent by the master node P1. cmt The message will be added to the blockchain. The θ corresponding to n and the locally generated R che,u The message compares θ with n. If they are the same, the replica nodes accept the decision of the primary node P1; if they are different, the replica nodes consider the primary node P1 to pose a security risk and send a request to the primary node P2 to replace the primary node P1. If the primary node P2 counts that more than 2 / 3 of the replica nodes have initiated the request to replace the primary node P1, it determines that the primary node P1 is a Byzantine node, and sends a view change request to the cloud center, while simultaneously broadcasting the block revocation to the replica nodes. Incoming message: This round of block consensus has failed.

[0141] If master node P2 does not receive a request to change master node from more than 2 / 3 of the consensus replica nodes within the specified time limit, the consensus round is successful, and consensus master node P2 broadcasts the consensus block to the entire network. All blockchain nodes will block Once added to the local ledger, this round of consensus is complete.

[0142] Therefore, during the consensus process, the view replacement triggering conditions include:

[0143] (1) During the consensus process, when a consensus node applies to leave the system, the consensus master node sends a node exit message to the cloud center and simultaneously sends a consensus view replacement request.

[0144] (2) During the consensus decision phase, the master node P1 receives verification messages R from each consensus replica node for the same proposed block. che,u More than 1 / 3 of R che,u The public information in the message, such as M and h, is inconsistent, and the master node P2 is suspected of being malicious. The master node P1 sends a request to the cloud center to replace the master node P2 and a request to replace the consensus view.

[0145] (3) During the consensus completion phase, the consensus replica nodes do not recognize the R of the master node P1. cmt The message indicates that the primary node P1 may be malicious, and sends a request to primary node P2 to replace primary node P1; primary node P2 counts that more than 2 / 3 of the replica nodes have initiated the request to replace primary node P1, determines that primary node P1 is a Byzantine node, and then sends a message to the cloud center to replace primary node P1 and a request to replace view.

[0146] (4) During the consensus process, if a consensus replica node does not receive a message from the master node P1 (P2) after a timeout, it assumes that the consensus master node P1 (P2) may be malicious or faulty. The replica node then initiates a request to the master node P2 (P1) to replace the master node P1 (P2). The master node P2 (P1) counts that more than 2 / 3 of the replica nodes have initiated the request to replace the master node P1 (P2), and then sends a message to the cloud center to replace the master node P1 (P2) and a request to replace the view.

[0147] (5) When the node credit update time is up, that is, K rounds of block consensus have been completed, the consensus master node P1 sends a node credit update message and a request to change the consensus view to the cloud center.

[0148] The consensus view is managed by the upper-layer cloud center. The specific description of the consensus view replacement operation is as follows:

[0149] The consensus master node initiates a view change request to the upper-layer cloud center; the cloud center verifies whether the received view change request is accompanied by a node credit update message or a consensus node exit request:

[0150] If a node credit update message is present, the cloud center updates the node credit according to the node credit assessment model, selects the consensus master node and consensus replica node according to the dynamic update consensus node set method, and then broadcasts the new consensus node set information and view replacement instructions to the consensus nodes to execute the consensus view replacement.

[0151] If there is no node credit update message but there is a request for exit / replacement of consensus master node P1, the cloud center designates the current master node P2 as the new consensus master node P1′, selects the consensus replica node with the highest current credit as the new master node P2′, and selects the candidate node with the highest current credit to fill the gap in the consensus node set; then the new master node information, the new consensus node information and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement.

[0152] If there is no node credit update message but there is a request for exit / replacement of consensus master node P2, the cloud center selects the consensus replica node with the highest current credit as the new master node P2′, and selects the candidate node with the highest current credit to fill the gap in the consensus node set; then the new master node information, the new consensus node information and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement.

[0153] If there is no node credit update message but there is a consensus replica node exit request, the cloud center selects the candidate node with the highest current credit to enter the consensus node set to fill the gap, and then sends the new consensus node information and view replacement instructions to all consensus nodes to execute the consensus view replacement.

[0154] Upon receiving the view change instruction, all consensus nodes increment their view number by 1, preparing to enter a new round of consensus process, i.e., executing step 2.

[0155] Step 3, Credit Update Phase: Design a node credit assessment model. After each credit update cycle T, i.e., after completing K rounds of block consensus, the cloud center reassesses the credit value of each node and dynamically updates the consensus node set to improve the security of subsequent transaction consensus.

[0156] Step 3-1, Dynamically update node credit value: The credit update of a node depends on its consensus behavior data in a credit assessment cycle, including consensus benefits, latency performance, historical credit value, etc. The consensus behavior data of the node is recorded in the corresponding consensus view, which is jointly managed by the consensus master node and the cloud center. The cloud center can evaluate and update the node's credit value by calling the consensus view data.

[0157] Let a node's credit assessment period T go through K rounds of block consensus. After each K rounds of block consensus, the consensus reward, latency performance, and historical credit value of each node in a credit update period are defined and calculated as follows:

[0158] Consensus Reward: Refers to the credit gain a node receives for participating in block consensus within a credit update cycle. Node i's consensus reward B i The calculation formula is as follows:

[0159]

[0160] in, This represents the positive incentive portion, where α is the reward factor and ε1 controls the growth rate of the positive incentive curve. This represents the negative penalty component, where β is the penalty factor and ε² controls the growth rate of the negative penalty curve; N total =gw represents the total number of transactions verified by consensus node i within the credit update period T, g,1≤g≤w represents the number of blocks in which consensus node i participates in consensus within the credit update period T, and w represents the number of transactions contained in the proposal block M packaged by master node P1; N T This indicates the total number of transactions correctly verified by consensus node i within the credit update cycle T. The cloud center compares these transactions with the blocks. The θ and each R stored in che,u The sum of the total number of transactions with the same θ in the message is N. T N F =N total -N T This represents the total number of incorrectly verified transactions by consensus node i within the credit update cycle T.

[0161] Equation (7) shows that the more times a node successfully verifies a transaction, the higher its credit value and the better its security; conversely, the lower its credit value and the worse its security.

[0162] Latency performance: refers to the time it takes for a node to respond to the preparation message R sent by the master node P2 during the consensus process. pre And send back the master node P1 verification message R che The latency level. The latency performance D of consensus node i. i Calculated from equation (8):

[0163]

[0164] in, This represents the consensus latency of consensus node i for the j-th block. The consensus latency refers to the time from when master node P2 sends the preparation message R during the preparation phase. pre During the judgment phase, master node P1 receives the verification message R from consensus node i. che The time taken; d max=max(d ij ) represents the maximum consensus latency of consensus node i within this credit period; g represents the number of blocks in which consensus node i participates in consensus within the credit update period T, 1≤g≤w.

[0165] Consensus reward B based on node i i Delay performance D i And the credit score C from the previous credit assessment period. i The cloud center reassesses the current credit value C of node i according to equation (9). i for

[0166]

[0167] Where α, β, γ, and μ are weighting factors, and α+β+γ+μ=1. The values ​​of α, β, γ, and μ depend on the preferences of the blockchain system. For example, if the system attaches more importance to consensus benefits, α+β∈[0.5,0.8] and γ+μ∈[0.2,0.5].

[0168] It should be noted that all nodes, including the initial selection nodes and consensus nodes, participate in the credit update.

[0169] Step 3-2: Dynamically update the consensus node set:

[0170] After the node credit assessment is completed, the cloud center sorts all nodes in descending order of their current credit value, with those having a credit value below the credit threshold S. min A node is directly kicked out of the blockchain system by its proxy node. After a period of time, the kicked-out node can reapply to the proxy node to join the initial node set. The cloud center selects the top M+2 nodes with the highest credit from the current initial node set as consensus nodes and enters the consensus node set. It also selects the two consensus nodes with the highest credit values ​​in the consensus node set as consensus master nodes P1 and P2 respectively, and broadcasts the new consensus node set to all nodes to prepare for a new round of consensus process.

[0171] The above description is merely a preferred embodiment of the present invention and is not intended to further limit the present invention. All equivalent changes made based on the description and drawings of the present invention are within the protection scope of the present invention.

Claims

1. A dual-master node dynamic PBFT consensus method based on a credit mechanism, characterized in that, The steps of the method are as follows: Step 1: Based on the basic credit value of the initial node, a consensus node set is generated by filtering from the initial node set. The initial node set is a set of nodes composed of the initial nodes. The initial nodes are proxy nodes or terminals with storage capabilities that have been verified as trusted nodes by associated proxy nodes. The two consensus nodes with the highest and second-highest basic credit scores are selected from the consensus node set as master nodes. and master node The remaining consensus nodes serve as consensus replica nodes; the exit of any node in the blockchain system is managed according to the dynamic node exit policy. Step 2: According to the dual-master node dynamic PBFT consensus protocol, the two master nodes supervise and cooperate with each other, packaging newly generated transaction information into proposal blocks for consensus. Upon successful consensus, these blocks are recorded as valid blocks in the blockchain ledger. The dual-master node dynamic PBFT consensus protocol includes: the client packaging transaction information into "request messages" and sending them to the consensus master node. Master node The request messages are verified, sorted, and stored in the transaction pool. Then, w messages are packaged from the pool to generate a proposal block, which is sent to all consensus replica nodes and the master node. Each replica node and the master node Each replica node independently verifies the validity of each message in the proposal block, generating a verification message and sending it to the master node. Master node If more than 1 / 3 of the verification messages contain public information proposal blocks... block height View Number If inconsistent, determine the master node. Malicious, initiating a request to the cloud center to replace the master node. The request and view replacement request will be processed; otherwise, the transaction information verified by more than 1 / 3 of the replica nodes will be stored in the block to be added to the chain and sent to all consensus replica nodes and the master node. If the replica node does not recognize the block to be added to the chain, it will send a request to the master node. Initiate a view replacement request; if approved, write the block to be added to the chain into the local blockchain ledger; if the master node... If a request to change more than 2 / 3 of the views is received, then the primary node is determined. Maliciously, this round of consensus failed, and an attempt was made to request the cloud center to replace the master node. If more than 2 / 3 of the view change requests are not received within a timeout period, consensus is considered successful, and the blocks to be added to the chain are recorded in the blockchain ledger. Other triggering conditions for initiating a view change during the consensus process include: when a consensus node applies to leave the system, the consensus master node sends a node exit message to the cloud center and simultaneously sends a consensus view change request; and when a consensus replica node does not receive a view change request from the master node within a timeout period. The message suggests that the consensus master node Possibly due to malicious intent or a malfunction, the replica node sent a message to the master node. Initiate a change of master node Request; Master Node Statistics show that more than two-thirds of the replica nodes initiated a switch of the primary node. The request was then sent to the cloud center to replace the master node. Messages and view change requests; consensus replica nodes timed out without receiving a message from the master node. The message suggests that the consensus master node Possibly due to malicious intent or a malfunction, the replica node sent a message to the master node. Initiate a change of master node Request; Master Node Statistics show that more than two-thirds of the replica nodes initiated a switch of the primary node. The request was then sent to the cloud center to replace the master node. Messages and view change requests; node credit update preset time has expired, meaning K rounds of block consensus have been completed consecutively, consensus master node Send a node credit update message and a request to change the consensus view to the cloud center; Step 3: After each credit update cycle T, i.e., after completing K rounds of block consensus, the cloud center re-evaluates the credit value of each node and dynamically updates the consensus node set.

2. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: In step 1, the initial node selection set is constructed using the following trusted node entry strategy: When a node i requests to join the blockchain system, it sends a join request message to its surrounding proxy nodes. This message contains the number of CPU cores of node i. Hard drive capacity information; Upon receiving the request, the proxy node checks if any other proxy nodes have already agreed to the node joining. If so, it ignores the request; otherwise, it verifies whether the node meets the requirements for joining the blockchain network. Check if the node's IP is in the whitelist maintained by all proxy nodes. If not, node i has a security risk and its access request is rejected. If yes, the proxy node calculates the node's basic credit value according to formula (1). : ； in, Indicates the number of CPU cores in node i; , These represent the minimum and maximum values ​​for the number of CPU cores, respectively. Let i be the computer memory capacity. , These represent the minimum and maximum values ​​of the computer's memory capacity, respectively. If the basic credit value of node i Exceeding the credit threshold ,Right now The node is authenticated as a trusted node, and the proxy node sends a network access permission to node i. If node i receives a network access permission from a single proxy node, it sends a network access confirmation message to that proxy node; if node i receives network access permission from multiple proxy nodes at the same time, it randomly selects a proxy node to associate with and sends a network access confirmation message to that proxy node. After receiving the network access confirmation message from node i, the proxy node broadcasts node i's network access message to other proxy nodes, and simultaneously updates node i's network access status and basic credit value in the whitelist. The updated whitelist will be simultaneously reported to the cloud center. A node that successfully joins the blockchain network automatically becomes a preliminary node and enters the preliminary node set.

3. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: In step 1, the consensus node set is generated as follows: Step 1a: The cloud center sorts all the initial nodes in descending order of their basic credit values ​​and selects the two nodes with the highest credit values ​​as the consensus master nodes. and Master node Broadcast the consensus invitation message to other nodes in the initial node set; Step 1b, prioritize responding to the master node. Invited The initial nodes are sorted from highest to lowest based on their basic credit score, and the master nodes... Before choosing Each node serves as a consensus replica node, and together with the two master nodes, they constitute the consensus node set for the current stage.

4. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: In step 1, the dynamic node exit strategy is as follows: If a consensus replica node intends to leave the consensus node set, it directly applies to either of the two master nodes. After the master node agrees, it sends the node exit message to the other consensus nodes. The replica node then successfully exits and returns to the initial node set. If a consensus master node intends to leave the consensus node set, it needs to initiate a request to re-elect a master node. After the new master node election is completed, the master node becomes a replica node and leaves the consensus node set as a replica node, returning to the initial node set. If a node intends to leave the blockchain system, it sends a request to its proxy node to leave. Upon receiving the request, the proxy node returns a message agreeing to the departure and broadcasts it to other nodes. Then, it deletes the node's attribute information stored locally, and the node successfully leaves the system.

5. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: The dual-master node PBFT consensus protocol described in step 2 specifically includes five stages: request, preparation, verification, decision, and completion. The tasks of each stage are described in detail below: Step 2a, the request phase, involves the client packaging its own transaction information or the transaction information of several terminal devices it manages into a "request message". Send to consensus master node ; Remember the client The consensus request message sent is Its message format is: ； in, The message type identifier for a "request message"; Indicates the client The j-th generated information; Indicates the client The generated j-th transaction information, where For transaction data, Generate timestamps for transactions; Representative client Send the timestamp of the j-th transaction. For the client The signature; A client refers to a blockchain node that sends transaction information; transaction data generated by non-blockchain nodes is generated by their associated proxy nodes acting as clients. send; Step 2b, Preparation Phase, Master Node Received from the client After the message, based on the signature verify The client in the message Identity verification is successful; a timestamp is generated based on the transaction. right After the messages are sorted, they are stored in the local transaction pool to await consensus; then, the master node... Take w items from the transaction pool. Messages are packaged to generate proposal blocks and adopt The message format is sent to all consensus replica nodes; The message format is: ； ； in, The message type identifier that indicates "preparing message"; This indicates the consensus view number. A view refers to a set of consensus processes completed consecutively by the same set of consensus nodes. Once a consensus node is replaced, the view number is incremented by 1. This indicates the height of the next block in the blockchain, which is the number of blocks already on the chain plus 1. Represents the consensus master node The generated proposal block is shown in equation (4); where, express The message contains the kth request message, i.e. The sequence number in the message pool. This indicates the total number of request messages contained in the current proposal block, i.e., the number of transaction messages awaiting consensus. ; Indicates the master node Received The message timestamp Indicates the master node send Message timestamp; This indicates that the preparation message was sent by the master node. issue; Indicates the master node The signature; Step 2c, Verification Phase: Each consensus replica node receives the primary node's... Preparation message to be sent And independently verified The message proposes a block The validity of each request message is assessed; if valid, it is recorded as 1; otherwise, it is recorded as 0. When a block is proposed... Once all request messages have been verified, the consensus replica node generates a verification message. And send it to the master node. ; Record the consensus replica node u for The generated verification message is The message format is as follows: ； in, The message type identifier representing a "verification message"; , , The meaning is the same as in formula (3); Indicates the proposed block The verdict, , express The k-th request message is invalid. This indicates that the k-th request message has been verified as valid; Indicates that replica node u sends Message timestamp; This represents the signature of the replica node u; Consensus Master Node Verify the proposed block locally using the same judgment method. The legality of the request message is verified to obtain a local judgment result. ; Step 2d, Judgment Phase: Consensus Master Node Receive verification messages from each replica node And record its receiving time locally. Then count the proposed blocks. The number of valid votes for each request message; if a request message is verified as valid by more than 1 / 3 of the consensus nodes, the request message is determined to be a valid message and the transaction data it contains is valid; otherwise, the request message is determined to be an invalid message and the transaction data it contains is invalid. For request messages that are verified as invalid, the master node Remove it from the proposal block Remove the pending blockchain blocks that generated this round's consensus. At the same time, a judgment message is generated. Send to each consensus replica node so that the replica nodes can verify the master node. Generated blocks to be added to the chain Is it legal? To prevent master nodes from... Malice; The message format is as follows: ； in, The message type identifier that represents a "commit message"; , These represent the master nodes respectively. send Message timestamps and consensus master nodes The signature; It consists of two parts: a block header and a block body. The block header contains the block generation timestamp. Block hash The block height in equation (5) View Number and master node ID; the block contains the block hash. And a packaged sequence of valid transactions, which records the transaction sequence number. Transaction details Transaction generation timestamp Checksum status These four parameters can all be determined based on Message obtained; The block hash value is obtained by hashing the entire transaction sequence; the block header hash is... It is by , , , , The hash calculation is performed on five parameters, which is used to ensure the uniqueness and security of the block. Step 2e, Completion Phase: Each consensus replica node verifies the master node. Sent The message will be added to the blockchain. middle corresponding Compared with locally generated In the message corresponding If they match, the replica node recognizes the master node. The decision result is the same as the primary node's; if they differ, the replica node considers the primary node to be the primary node. There is a security risk; send to the master node. Send to change master node Request; if the master node Statistics show that more than two-thirds of the replica nodes initiated a switch of the primary node. Request to identify the master node As a Byzantine node, it sends a view change request to the cloud center and simultaneously broadcasts the block revocation to the replica nodes. Incoming chain message: This round of block consensus failed; If the master node If no request to change the master node is received from more than 2 / 3 of the consensus replica nodes within the specified time limit, this round of consensus is successful, and the consensus master node is established. Broadcast consensus blocks to the entire network All blockchain nodes will block Once added to the local ledger, this round of consensus is complete.

6. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: The consensus view is managed by the upper-layer cloud center. The specific description of the consensus view replacement operation is as follows: The consensus master node initiates a view change request to the upper-layer cloud center; the cloud center verifies whether the received view change request is accompanied by a node credit update message or a consensus node exit request: If a node credit update message is present, the cloud center updates the node credit according to the node credit assessment model, selects the consensus master node and consensus replica node according to the dynamic update consensus node set method, and then broadcasts the new consensus node set information and view replacement instructions to the consensus nodes to execute the consensus view replacement. If there is no accompanying node credit update message but there is a consensus master node message The exit / replacement request specifies the current master node in the cloud center. As the new consensus master node At the same time, the consensus replica node with the highest current credit rating is selected as the new master node. Then, the candidate node with the highest current credit is selected to fill the gap in the consensus node set; then, the new master node information, the new consensus node information, and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement. If there is no accompanying node credit update message but there is a consensus master node message Upon receiving a request to exit / replace, the cloud center selects the consensus replica node with the highest current credit rating as the new master node. And select the candidate node with the highest current credit rating to fill the gap in the consensus node set; Then, the new master node information, the new consensus node information, and the view replacement instruction are sent to all consensus nodes to execute the consensus view replacement; If there is no node credit update message but there is a consensus replica node exit request, the cloud center selects the candidate node with the highest current credit to enter the consensus node set to fill the gap, and then sends the new consensus node information and view replacement instructions to all consensus nodes to execute the consensus view replacement. Upon receiving the view change instruction, all consensus nodes increment their view number by 1, preparing to enter a new round of consensus process.

7. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: In step 3, the credit value of each node is evaluated according to the following node credit assessment model: The credit update of a node is based on the consensus behavior data generated after it has gone through K rounds of block consensus in a credit assessment cycle T, including consensus benefits, latency performance, and historical credit value; the consensus behavior data of the node is recorded in the corresponding consensus view, which is jointly managed by the consensus master node and the cloud center; the cloud center can evaluate and update the credit value of the node by calling the consensus view data.

8. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 7, characterized in that: The consensus benefit refers to the credit gain obtained by a node for participating in block consensus within a credit update cycle; Node i consensus benefit The calculation formula is as follows: ； in, This represents the positive incentive portion. As a reward factor, Control the growth rate of the positive excitation curve; This indicates the negative penalty portion. As a penalty factor, Control the growth rate of the negative penalty curve; This represents the total number of transactions verified by consensus node i within the credit update period T. This represents the number of blocks that consensus node i participated in during the credit update period T. Indicates the master node Packaged proposal blocks The number of transactions included; This indicates the total number of transactions correctly verified by consensus node i within the credit update cycle T. The cloud center compares these transactions with the blocks. Stored in With each The message corresponding ,statistics The sum of the same total number of transactions is ; This represents the total number of incorrectly verified transactions by consensus node i within the credit update period T. Equation (7) shows that the more times a node successfully verifies a transaction, the higher its credit value and the better its security; conversely, the lower its credit value and the worse its security. The latency refers to the response time of a node to the master node during the consensus process. Preparation message sent And feedback to the master node Verification message latency level; consensus nodes latency performance Calculated from equation (8): ； in, This represents the consensus latency of consensus node i for the j-th block. The consensus latency refers to the time from the start of the preparation phase to the start of the consensus phase. Send preparation message Main node at the judgment stage Received a verification message from consensus node i The time taken; This indicates the maximum consensus latency of consensus node i within this credit period; This represents the number of blocks that consensus node i participated in during the credit update cycle T. ; Consensus benefits based on node i Latency performance And historical credit score, i.e., the credit score of the previous credit assessment period. The cloud center reassesses the current credit value of node i according to equation (9). for ； in, As a weighting factor, and ; The value of depends on the preferences of the blockchain system. If the system prioritizes consensus benefits, it can make ... , .

9. The dual-master node dynamic PBFT consensus method based on a credit mechanism according to claim 1, characterized in that: The method for dynamically updating the consensus node set described in step 3 is explained in detail below: After the node credit assessment is completed, the cloud center sorts all nodes in descending order according to their current credit value, and nodes with credit values ​​lower than the credit threshold are sorted. A node is directly kicked out of the blockchain system by its proxy node. After a period of time, the kicked-out node can reapply to the proxy node to join the initial node set. The cloud center selects the top M+2 nodes with the highest credit from the current initial node set as consensus nodes, and selects the two consensus nodes with the highest credit values ​​as the consensus master nodes. and It then broadcasts the new consensus node set to all nodes, preparing to enter a new round of consensus process.

Images