A blockchain-based reputation consensus method, device, program product, and storage medium

Abstract

This invention relates to the field of blockchain information security technology, and particularly to a blockchain-based reputation consensus method, device, program product, and storage medium. The method includes: calculating an intermediate value for the reputation value of nodes in the current round of consensus based on their direct trust value, incentive trust value, and consensus participation degree; obtaining the current final reputation value of nodes in the current round of consensus based on the final reputation value of nodes in the previous round of consensus, the intermediate value calculated from the reputation value, and a smoothing factor; determining a threshold value based on the current final reputation value ranking at a preset position; determining a leader node, candidate nodes, and member nodes based on the current final reputation value, the threshold value, a first reputation threshold, and a second reputation threshold; achieving consensus on the leader node based on candidate nodes and member nodes using a hierarchical aggregation signature mechanism; and adjusting the smoothing factor corresponding to each node based on its behavior in the consensus process.

Description

Technical Field

[0001] This invention relates to the field of blockchain information security technology, and in particular to a blockchain-based reputation consensus method, device, program product, and storage medium. Background Technology

[0002] A consortium blockchain is a type of blockchain that falls between public and private blockchains. The Practical Byzantine Fault Tolerance (PBFT) consensus algorithm is widely used in consortium blockchains; however, in practice, this algorithm is often vulnerable to Byzantine attacks, which can compromise the integrity of block data and the consistency of the ledger. Furthermore, under the existing PBFT framework, the roles of all nodes in the consensus process tend to become fixed, making it difficult for the system to adapt to dynamic changes in nodes, thus affecting long-term stability and efficiency.

[0003] With the development of technology in this field, a number of optimization schemes have been proposed, mainly focusing on node screening and communication optimization. However, these schemes generally have two common defects: First, they generally rely on empirical or heuristic scoring rules, which are insufficient in terms of stability and resistance to manipulation when facing long-term and dynamically changing collusion attacks, reputation drift or sudden changes in node behavior. Second, the grouping strategies adopted are still unable to effectively compress communication volume and resist cryptographic attacks such as Rogue Public Key. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based reputation consensus method, device, program product, and storage medium to address the problem that existing consensus algorithms lack stability and resistance to manipulation when facing long-term and dynamically changing collusion attacks, reputation drift, or sudden changes in node behavior.

[0005] To achieve the above objectives, the present invention provides a blockchain-based reputation consensus method, which includes: Based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value of the reputation value of each node in the current round of consensus is obtained. Based on the final reputation value of each node in the previous consensus, the intermediate value and the smoothing factor are calculated to obtain the current final reputation value of each node in the current consensus. Based on the relationship between all current final reputation values, the current final reputation value ranked in the preset position is determined as the threshold value; Leader nodes, candidate nodes, and member nodes are determined based on the current final reputation value, threshold value, preset first reputation threshold, and preset second reputation threshold; the second reputation threshold is greater than 0 and less than the first reputation threshold. The hierarchical aggregation signature mechanism achieves consensus on the leader node based on candidate nodes and member nodes; the hierarchical aggregation signature mechanism is a fusion of the BLS aggregation signature mechanism with provable ownership and the hierarchical consensus mechanism. Adjust the smoothing factor for each node based on its behavior in the consensus process.

[0006] Beneficial Effects: This invention provides a blockchain-based reputation consensus method. This method assists consensus through a dynamic reputation evaluation mechanism. Specifically, it involves performing a series of calculations based on the historical behavior data of each node participating in the consensus process to obtain a final reputation value. This final reputation value can be used to quantitatively evaluate the reputation (i.e., the integrity demonstrated in the consensus) of each node. Based on the relationship between the final reputation value and two set thresholds (i.e., the first reputation threshold and the second reputation threshold), nodes are divided into three functional roles: leader nodes, candidate nodes, and member nodes. These three functional roles have different permissions and responsibilities. The dynamic reputation evaluation mechanism accurately reflects the value of nodes. Nodes with high reputation values ​​are dynamically selected as leader nodes and have higher permissions in subsequent consensus processes; nodes with decreasing reputation values ​​may dynamically lose their permissions (i.e., dynamic reclamation of high-permission roles). By adjusting a smoothing factor, the functional roles of nodes are dynamically updated in sync with the consensus rounds, thereby avoiding the solidification of node roles. Permissions are dynamically adjusted according to the node's role status to adapt to the dynamic changes in the node's behavior, ensuring long-term operational stability and resistance to manipulation, and thus maintaining the integrity of block data and ledger consistency.

[0007] Furthermore, the leader node is determined based on the final reputation value, the threshold value, the preset first reputation threshold, and the preset second reputation threshold, including: If the current final reputation value is greater than a preset first reputation threshold and is greater than or equal to the threshold value, then the corresponding node is determined as a leader node; the first reputation threshold is greater than 0 and less than 1. If the current final reputation value is less than or equal to the first reputation threshold and greater than or equal to the second reputation threshold, then the node corresponding to the current final reputation value is determined as a candidate node. If the current final reputation value is less than the second reputation threshold, then the corresponding node is determined as a member node.

[0008] Furthermore, the hierarchical aggregation signature mechanism includes: After each node verifies the legitimacy of the transaction request sent by the leader node of its group, a corresponding signature is generated. If the generated signature is determined to be a valid signature based on the preset public key binding proof, the aggregate signature and aggregate public key within the group are calculated. Each leader node broadcasts the aggregated signature and aggregated public key calculated within its group to other groups. Each leader node obtains the intra-group aggregate signature and intra-group aggregate public key from other leader nodes through inter-group broadcast, and obtains the global aggregate signature and global aggregate public key based on the intra-group aggregate signature and intra-group aggregate public key; Each leader node broadcasts the global aggregate signature and the global aggregate public key to its respective group nodes.

[0009] Furthermore, the hierarchical aggregation signature mechanism also includes: When any node obtains the global aggregate signature and the global aggregate public key, it generates the corresponding bilinear pair for verification based on the public parameters, the global aggregate signature, the global aggregate public key, and the message to be verified. A deterministic challenge value is generated using a collision-resistant hash function. If substituting the deterministic challenge value into the bilinear pair verification makes the equation true, then the global aggregate signature is accepted; otherwise, the global aggregate signature is rejected.

[0010] Furthermore, based on the behavior of each node in the consensus process, the smoothing factor corresponding to each node is adjusted, including: If a node is a leader node and has not engaged in malicious behavior in the current round of consensus, then the smoothing factor corresponding to that node remains unchanged. If a node is a leader node and engages in malicious behavior during this round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the first reputation threshold.

[0011] Furthermore, based on the behavior of each node in the consensus process, the smoothing factor corresponding to each node is adjusted, including: If a node is a candidate node and no malicious behavior has occurred in the current round of consensus, then the smoothing factor corresponding to that node will be increased. If a node is a candidate node and engages in malicious behavior in the current round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to the node will be increased so that the final reputation value of the node in the next round of consensus is greater than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to that node will be lowered.

[0012] Furthermore, based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value for calculating the reputation value of each node in the current round of consensus is obtained, including: The direct trust value of each node is calculated based on the number of successful and failed transactions at each node. Based on the final reputation value, incentive magnitude, and adjustment sensitivity of each node in the previous consensus, the incentive trust value of each node is calculated. The consensus participation of each node is calculated based on the total number of transactions in the blockchain and the number of transactions completed by a single node; if a single node's transaction is successful, the number of transactions completed by that single node is 1, otherwise it is -1. The direct trust value, incentive trust value, and consensus participation are weighted and summed. The result of the weighted sum is processed by a pre-determined function to obtain the intermediate value of the reputation value of each node in the current round of consensus.

[0013] The present invention also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements a blockchain-based reputation consensus method as described in any of the embodiments of the present invention.

[0014] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements a blockchain-based reputation consensus method as described in any of the embodiments of the present invention.

[0015] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a blockchain-based reputation consensus method as described in any of the embodiments of the present invention.

[0016] The electronic devices, computer program products, and computer-readable storage media provided by this invention can all execute the blockchain-based reputation consensus method provided by this invention, and have the corresponding functional modules and beneficial effects of executing the method. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the blockchain-based reputation consensus method in the implementation of the present invention. Figure 2This diagram illustrates an application example of the consensus algorithm implemented through intra-group consensus and inter-group consensus phases in the blockchain-based reputation consensus method of this invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0020] Implementation of Blockchain-based Reputation Consensus Method This embodiment presents a technical solution for a blockchain-based reputation consensus method. This method is applied to a consortium blockchain network composed of multiple physical computing nodes, including servers, cloud virtual machines, or edge gateways—devices with processors, memory, and network communication capabilities, hereinafter referred to as nodes. The method uses a dynamic evaluation mechanism of node integrity in the blockchain. Based on observable data such as transaction verification success rate and participation rate in the consensus process, it dynamically quantifies and evaluates the reliability of nodes and assigns them different functional roles to prevent low-reputation nodes (i.e., malicious nodes) from being selected as primary nodes, thus ensuring the integrity of block data and ledger consistency.

[0021] In this embodiment, the method includes: Based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value of the reputation value of each node in the current round of consensus is obtained. Based on the final reputation value of each node in the previous consensus, the intermediate value and the smoothing factor are calculated to obtain the current final reputation value of each node in the current consensus. Based on the relationship between all current final reputation values, the current final reputation value ranked in the preset position is determined as the threshold value; Leader nodes, candidate nodes, and member nodes are determined based on the current final reputation value, threshold value, preset first reputation threshold, and preset second reputation threshold; the second reputation threshold is greater than 0 and less than the first reputation threshold. The hierarchical aggregation signature mechanism achieves consensus on the leader node based on candidate nodes and member nodes; the hierarchical aggregation signature mechanism is a fusion of the BLS aggregation signature mechanism with provable ownership and the hierarchical consensus mechanism. Adjust the smoothing factor for each node based on its behavior in the consensus process.

[0022] In this embodiment, the leader node is determined based on the final reputation value, the threshold value, a preset first reputation threshold, and a preset second reputation threshold, including: If the current final reputation value is greater than the preset first reputation threshold and is greater than or equal to the threshold value, then the corresponding node is determined as the leader node; the first reputation threshold is greater than 0 and less than 1. If the current final reputation value is less than or equal to the first reputation threshold and greater than or equal to the second reputation threshold, then the node corresponding to the current final reputation value is determined as a candidate node. If the current final reputation value is less than the second reputation threshold, then the corresponding node is determined as a member node.

[0023] In this implementation, based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value of the reputation value calculation for each node in the current round of consensus is obtained, including: The direct trust value of each node is calculated based on the number of successful and failed transactions at each node. Based on the final reputation value, incentive magnitude, and adjustment sensitivity of each node in the previous consensus, the incentive trust value of each node is calculated. The consensus participation of each node is calculated based on the total number of transactions in the blockchain and the number of transactions completed by a single node; if a single node's transaction is successful, the number of transactions completed by that single node is 1, otherwise it is -1. The direct trust value, incentive trust value, and consensus participation are weighted and summed. The result of the weighted sum is processed by a pre-determined function to obtain the intermediate value of the reputation value of each node in the current round of consensus.

[0024] In a preferred embodiment, before each consensus round begins, the system acquires historical behavior data of each node participating in the consensus process in the blockchain. This historical behavior data includes, but is not limited to, the number of successful and failed transactions for each node, consensus participation level, response timeliness, and past voting consistency. Based on the acquired historical behavior data, the system performs dynamic reputation assessment and generates a reputation value normalized to the [0,1] interval (i.e., the final reputation value). Figure 1 As shown, the dynamic evaluation process specifically includes:

[0025] 1) Calculate the direct trust value; In this embodiment, the Beta probability distribution is used to describe the trust relationship between nodes; the formula for calculating the direct trust value is as follows: in, Indicates a direct trust value; For nodes The direct trust value in the k-th round of consensus (i.e., the current round of consensus); parameters This indicates the number of successful transactions between nodes; For nodes The number of successful transactions after the k-th round of consensus; parameter This indicates the number of failed transactions between nodes; For nodes The number of failed transactions in the k-th round of consensus.

[0026] Initially, if there is no historical interaction, set = = ,in >0 is a constant, making the initial trust value 0.5. As interactions increase, and Dynamic updates: When a node When the behavior is honest (i.e., no malicious behavior occurs), Increase, decay; when node When malicious behavior occurs, attenuation, Increase; as shown in the above formula, the direct trust value It can accurately reflect the historical transaction behavior of nodes.

[0027] (ii) Calculate the incentive trust value; The incentive trust value comprehensively reflects a node's performance in each round of consensus within a request cycle, and, combined with the node's current trust level, is used to assess the node for appropriate rewards or penalties. The formula for calculating the incentive trust value is as follows:

[0028] in, Indicates the incentive trust value; For nodes The incentive trust value in the k-th round of consensus; For nodes The final reputation value in the (k-1)th round of consensus (i.e., the previous round of consensus); Incentive range ( ); To adjust sensitivity ( ).

[0029] From the above formula, it can be seen that, according to The basic credibility of node i before the start of the k-th round of consensus can be evaluated. If a node is assessed as having high credibility before the start of the k-th round of consensus, the formula is used. Calculate its incentive trust value; node In the case of a node being assessed as having low credibility before the start of the k-th round of consensus, the formula is used. Calculate its incentive trust value. It's important to note that under this incentive trust value-based reward and punishment mechanism, a high-trust node, if behaving honestly, receives a lower trust reward than a low-trust node. Conversely, when a high-trust node makes a mistake, the trust penalty it faces is more severe. This ensures that if a high-trust node engages in malicious behavior, its privileges can be immediately revoked (this can also be understood as a sensitive privilege revoke mechanism), minimizing the risk of malicious nodes wielding excessive privileges and threatening consensus security and activity.

[0030] (iii) Calculate consensus participation; This step involves calculating the percentage of nodes that successfully participate in each transaction after joining the network, and the consensus is as follows: in, Indicates the degree of consensus participation; For nodes The consensus participation rate in the k-th round of consensus; the total number of system transactions (i.e., the total number of transactions in the blockchain, or the total number of consensus attempts or total consensus participations of each node in the blockchain). For nodes The number of completed transactions, if the transactions are successful. The value is 1 (i.e., node) If the transaction fails, the number of completed transactions is 1. The value is -1 (i.e., node) The number of completed transactions is -1.

[0031] As can be seen from the above formula, this implementation not only considers the positive impact of successfully completed transactions on nodes, but also the negative impact of failed transactions on nodes due to interference with the execution of normal transactions. Therefore, parameters are set in the consensus participation evaluation. By participating in the computation, the reputation value of a node can be more accurately evaluated, and the effective participation rate can be reflected.

[0032] It should be noted that steps one), two), and three are calculation steps for reputation assessment values ​​in three different dimensions, and there is no strict logical order among them (i.e., they are parallel steps). In other embodiments, they can be executed simultaneously, or the specific execution order can be arranged according to actual needs.

[0033] (iv) Calculate the median value of the credit score; This step essentially involves weighting and fusing the calculation results from the three dimensions mentioned above (i.e., direct trust value, incentive trust value, and consensus participation), and then truncating them using the clip function (i.e., defining the range of the reputation value as [0, 1]) to obtain a more comprehensive and accurate reputation assessment value. The calculation formula is as follows: in, For nodes The intermediate value of the reputation value in the k-th round of consensus is used to integrate the results of multi-dimensional data. The weight corresponding to the direct trust value; The weight corresponding to the consensus participation level; The weights corresponding to the trust values ​​are used to incentivize the following three weights: Under the default configuration, all parameters meet the requirements. =0.4, =0.3, =0.3, to balance the impact of historical credibility, current activity, and behavioral incentives. The meanings of other parameters have been explained and will not be repeated here.

[0034] (v) Calculate the current final credit score; The final reputation score is a parameter that more accurately describes a node's reputation by combining the intermediate reputation score calculation with historical reputation scores through a smoothing factor. This is achieved after obtaining the node's... The median value of reputation in the k-th round of consensus calculation Then, the node can be calculated based on this value. The final reputation value in the k-th round of consensus (i.e., the current final reputation value) is calculated using the following formula:

[0035] in, For nodes The final reputation value in the k-th round of consensus; For nodes The final reputation value in the (k-1)th round of consensus (i.e., the previous round of consensus); This is a smoothing factor, whose value varies with the weights of the current credit indicators. , , .

[0036] Get Node Final reputation value in the k-th round of consensus Then, based on the relationship between this value and the two reputation thresholds, the nodes can be classified and grouped according to their roles. The specific steps are as follows: I) Set a reputation threshold; Specifically, the system sets three key thresholds: Cmin, Cmid, and Cmax, where 0 < Cmin < Cmid < Cmax. Among them, Cmid is the first reputation threshold; Cmin is the second reputation threshold; Cmax is the maximum reputation threshold (with a value of 1), which is only a theoretical value, and it is almost impossible for the actual reputation of a node to reach this threshold. Therefore, this threshold is not used as the main basis for classifying nodes. In a preferred embodiment, Cmin is initially default set to 0.5, Cmid to 0.8, and Cmax to 1. In other embodiments, other values can also be taken according to actual needs, but the relationship principle of 0 < Cmin < Cmid < Cmax still needs to be followed.

[0037] II) Classify the functional roles of nodes; Specifically, after the system globally sorts the nodes according to their final reputation values Credit, the nodes are initially classified as follows: a) If the final reputation value of a node is greater than the first reputation threshold (i.e., Credit > Cmid), then the node is tentatively designated as an alternative leader node and included in the leader node candidate set. However, since the leader node is not fully determined at this time, no corresponding functional permissions are assigned to the alternative leader node. b) If the final reputation value of a node is between Cmin and Cmid (i.e., Cmin ≤ Credit ≤ Cmid), then the node is determined as a candidate node, and corresponding functional permissions are assigned to the candidate node; its functional permissions include: participating in transaction verification, generating and submitting local signatures, and acting as a候补 node during view switching. c) If the final reputation value of a node is less than the second reputation threshold (i.e., Credit < Cmin), then the node is determined as a member node, and corresponding functional permissions are assigned to the member node; its functional permissions include: only receiving block data, performing integrity verification, and updating the local ledger, and not participating in the consensus voting process.

[0038] III) Execute node grouping; In one specific embodiment, the system is pre-divided into g groups. The system sorts the candidate leader nodes from the pool of leaders in descending order of their current final reputation values ​​(i.e., in descending order of size). The final reputation value of the node ranked g (i.e., the pre-defined g-th position) is used as the threshold value. This means that the node with the highest reputation value among the top g is selected as the leader node, ensuring that each group has at least one leader node. Nodes with a current final reputation value greater than this threshold value are then designated as the leader nodes for this round. These leaders are responsible for initiating the group consensus process, verifying member joining requests, and performing group aggregation signatures. Specifically, initiating the group consensus process involves each leader node broadcasting a group initialization message to the entire network. Verifying member joining requests involves each leader node checking if the number of members in its group exceeds a preset limit, receiving joining requests from other nodes, and if not exceeding the preset limit, including them in the current consensus group. This achieves the group consensus mechanism. Alternatively, in other embodiments, the threshold value can be determined according to actual needs, in ascending order of all current final reputation values ​​(i.e., in ascending order of size).

[0039] In this embodiment, the signing operation within the aforementioned aggregation group is implemented through a hierarchical aggregation signature mechanism. In fact, the hierarchical aggregation signature mechanism introduces a BLS aggregation signature mechanism based on Proof of Possession (PoP) on top of the hierarchical consensus architecture. This mechanism includes:

[0040] After each node verifies the legitimacy of the transaction request sent by the leader node of its group, a corresponding signature is generated. If the generated signature is determined to be a valid signature based on the preset public key binding proof, the aggregate signature and aggregate public key within the group are calculated. Each leader node broadcasts the aggregated signature and aggregated public key calculated within its group to other groups. Each leader node obtains the intra-group aggregate signature and intra-group aggregate public key from other leader nodes through inter-group broadcast, and obtains the global aggregate signature and global aggregate public key based on the intra-group aggregate signature and intra-group aggregate public key; Each leader node broadcasts the global aggregate signature and the global aggregate public key to its respective group nodes.

[0041] In a preferred embodiment, the hierarchical aggregation signature mechanism mainly includes five steps: system parameter setting, signature key generation, intra-group aggregation signature, inter-group aggregation signature, and signature verification, which are implemented as follows: 1) System parameter settings; In a preferred embodiment, during the system initialization phase, a Type-3 bilinear group is selected. There exists an efficient computable bilinear mapping. This bilinear mapping is used to generate bilinear pairs for verification. The generator is selected. and Collision-resistant hash function and Output common parameters The Type-3 bilinear group consists of three multiplicative cyclic groups: the source group... , and target group All are large prime numbers. In fact, the selection of a population is not unique. In this embodiment, Type-3 is chosen because the key characteristic of this population is... , There is no efficient isomorphic mapping between them, which can enhance security. In other embodiments, other specific groups can also be selected according to actual needs. This indicates mapping the input to a modulo. The integer is used for Discrete Logarithmic Equality (DLEQ) proofs or key derivation to ensure the indistinguishability of inputs and outputs. Additionally, using a collision-resistant hash function ensures that an attacker cannot find two different inputs mapping to the same output, preventing forgery attacks.

[0042] 2) Signature key generation; Specifically, each node i participating in the consensus runs independently upon startup. The algorithm randomly selects the private key. And calculate the public key. and .

[0043] Public Key It consists of the following two parts: Private key and generator scalar multiplication, mapped to the source group .

[0044] Private key and generator scalar multiplication, mapped to the source group .

[0045] calculate ,in For a collision-resistant hash function, the second part of the public key is mapped to a scalar field. This proof is used to verify the binding relationship between the private and public keys. The above structure ensures a strong binding between the public and private keys; any invalid public key will fail subsequent verification.

[0046] 3) Intra-group aggregate signature; In the consensus process, each node generates a corresponding signature after verifying the legitimacy of a transaction request sent by the leader node of its group. In a specific embodiment, when a node within the group... Verify the transaction request broadcast by the leader. After it is valid, call Generate signature And generate Chaum-Pedersen proof. The leader node randomly selects the challenge value. This ensures the randomness of each verification, preventing attackers from predicting or replaying attacks. After generating the challenge value, the public key binding proof can be verified, which consists of two parts:

[0047] i) Verification The correctness; if a member attempts to forge It must simultaneously satisfy the bilinear equation, and Its impact resistance makes it easy to counterfeit. or It is computationally infeasible.

[0048] ii) Verify whether the following equation holds true: Expanding both sides of the equation, we can see that the exponents on both sides are 1. This equation holds true if and only if With a legitimate private key Generate a signature. If the equation holds true, the verification passes, and the generated signature is determined to be valid. The group leader collects valid signatures. Then, the calculation is executed. Algorithm. First, calculate the aggregate signature within the group. Simultaneously calculate the aggregated public key within the group. After obtaining the calculation results, each group's leader node aggregates the results within its group, including the aggregated signature and the aggregated public key. Perform inter-group broadcasting.

[0049] Each leader node obtains the group's aggregate signature and group's aggregate public key from other leader nodes via inter-group broadcast. Based on the obtained information, it then obtains the global aggregate signature and group's aggregate public key. The final result and the final global aggregate signature are then broadcast to each node in the group.

[0050] In a preferred embodiment, to achieve hierarchical consensus, an intra-group consensus phase and an inter-group consensus phase are defined. The intra-group consensus phase implements intra-group aggregated signatures; the inter-group consensus phase implements inter-group aggregated signatures. The intra-group consensus phase includes an intra-group in-prepare phase and an intra-group in-commit phase. In the intra-group in-prepare phase, client requests are first received by the group leader nodes; after verifying the validity of the request, the leader node assigns a sequence number and timestamp, and broadcasts the in-prepare message within its group. This design restricts the in-prepare operation to within the group. Subsequently, in the intra-group in-commit phase, member nodes verify the in-prepare message and its transactions, and unicast their signatures only to their group leader node, rather than broadcasting them to the entire network. This change in communication mode reduces network overhead. Once the leader node collects a sufficient number of valid signatures, it uses the PoP-BLS algorithm to generate the intra-group aggregated signature Σg and the aggregated public key (…). , The aggregation results are then broadcast to the leader nodes of other groups in the out-prepare phase. Subsequently, each leader node exchanges and verifies the global aggregation signature Σglobal through the in-reply phase, thus completing the cross-group consistency confirmation.

[0051] refer to Figure 2 The specific workflow for the intra-group pre-preparation phase, intra-group submission phase, inter-group pre-preparation phase, inter-group response phase, and output phase is as follows: Intra-group pre-prepare phase: Upon receiving a client request, the leader node enters the extra-group pre-prepare phase, where the client node broadcasts a message to all leader nodes. The leader node first verifies the request and assigns a sequence number and timestamp, then broadcasts an in-prepare message to all group members. "In-prepare" indicates that this is a message in the in-prepare phase. In a specific embodiment, a broadcast in-prepare message is as follows: Where h represents the block height, v represents the view number, n represents the sequence number assigned to the request, t is the current timestamp, digest represents the digest of m, i.e. the block hash value, and m is the content of the entire block (this content is the message to be verified, which is the message sent by each node participating in the consensus in the blockchain network; its verification logic can be the logic of whether the specific message data structure is correct, etc.), including the collected transactions and the signatures of all transactions.

[0052] In-group commit phase: Group members receive and verify the in-prepare message. At this point, all nodes in the network have successfully received the message. Upon receiving the in-prepare message, each group member first verifies it, checking the validity of information such as the digest, block height, view, proof, and signature. After verification, they verify all transactions within the message. If all transactions are verified, group member i signs the message using their private key on the current view. During this phase, each group member sends an in-commit message to the group leader node. The in-commit message is... Where i is the node number within the group. For node signatures of views, the method of sending is slightly different from the original PBFT algorithm. Instead of broadcasting, the node only sends the signed information to the master node, which reduces the amount of communication messages.

[0053] Inter-group pre-preparation phase: During this phase, the leader node within the group continuously listens for in-commit messages sent by each replica node. The leader node verifies each in-commit message, including the signature of the verification message. Once verified, the signatures are collected. The leader node verifies these signatures and aggregates them into a single signature using PoP-BLS signing. Here, Σg represents the aggregate signature (i.e., the intra-group aggregate signature), signifying the consensus among all nodes in the group regarding the message m to be verified. Subsequently, the leader node simultaneously aggregates the public keys of all nodes in the group to calculate the intra-group aggregate public key. Each group leader node aggregates the results within its group. Then, an out-prepare message is broadcast between groups.<out-prepare,n, t,h,v,d,Σg,apk1,apk2, node> "Node" refers to the list of IDs of all leader nodes participating in the aggregate signature. This allows subsequent nodes receiving the message to verify the signature using the public keys of the participating nodes. Once each node receives the aggregate signature from the master node and verifies it, synchronization is complete. The main function of the out-prepare phase is for each leader node to collect and verify signatures, combine them with PoP-BLS signatures to aggregate multiple verified signatures into a single aggregate signature (i.e., inter-group aggregate signature), and broadcast this aggregate signature, public key, and other necessary information to the group's leader node for verification.

[0054] Inter-group response phase: Each group's leader node broadcasts its group's consensus result to other leader nodes as input for inter-group consensus. After receiving the consensus results from other groups, each leader node completes the inter-group aggregate signature, and upon global aggregate signature verification by the leader node, broadcasts the result within its group.<in-reply,n, t,h,v,d,Σglobal,APK2, node> Each node verifies the result using the global aggregated public key and global aggregated signature through the verification formula. This verification operation is equivalent to the entire network reaching a consensus. Each node updates its local state and adds the consensus result to its local ledger, thus completing the entire inter-group consensus process and achieving collaborative verification among multiple groups of nodes and consistent network-wide recognition of transactions and other messages.

[0055] Output Phase: Once all nodes in the network have completed the consensus process, the consensus process for this round is considered complete, and the leader node returns a response to the client.<out-reply, n, t, h, v, d, Σglobal,APK2> When the client receives When a reply message with identical content is received, the message is added to the end of the blockchain, and the global consensus is declared complete.

[0056] Specifically, the consensus mechanism requires only a subset of nodes to participate in voting, while ordinary nodes (i.e., member nodes) only need to participate in message synchronization and verification during the consensus process. This saves many unnecessary redundant communications (such as ordinary nodes receiving messages and sending feedback messages to the leader node), significantly reducing the number of communications. This reduction in communications effectively lowers latency, a major cause of network latency in large blockchain networks where communication between numerous nodes and the leader is a primary concern. Simultaneously, using PoP-BLS aggregated signatures effectively reduces the load on the master node and improves verification efficiency.

[0057] In this embodiment, the hierarchical aggregation signature mechanism further includes: When any node obtains the global aggregate signature and the global aggregate public key, it generates the corresponding bilinear pair for verification based on the public parameters, the global aggregate signature, the global aggregate public key, and the message to be verified. A deterministic challenge value is generated using a collision-resistant hash function. If substituting the deterministic challenge value into the bilinear pair verification makes the equation true, then the global aggregate signature is accepted; otherwise, the global aggregate signature is rejected.

[0058] At this stage, any node can pass Verify the aggregate signature. First, generate a deterministic challenge value. That is, through a collision-resistant hash function The message to be verified, m, and the first part of the global aggregated public key. The second part of the global aggregated public key Binding, ensuring Its uniqueness and unpredictability prevent chosen-message attacks or pre-computed attacks. Then, we verify whether the following bilinear equation holds:

[0059] If and only if and The index part, and The index part, and The equation holds when the exponent part of the equation satisfies a linear relationship under a bilinear mapping. Conversely, if the equation holds, it indicates that a linear relationship is satisfied, and the signature is valid; therefore, the global aggregate signature is accepted. If the equation does not hold, it indicates that a linear relationship is not satisfied, and the signature is invalid; therefore, the global aggregate signature is rejected. This verification logic, through the mathematical properties of bilinear mapping, the binding property of collision-resistant hash functions, and the randomness of challenge values, constructs an efficient and secure aggregate signature verification mechanism. This ensures the validity of the global signature while resisting various forgery and replay attacks, providing a solid cryptographic foundation for blockchain consensus protocols.

[0060] In this implementation, the smoothing factor for each node is adjusted based on its behavior in the consensus process, including: If a node is a leader node and has not engaged in malicious behavior in the current round of consensus, then the smoothing factor corresponding to that node remains unchanged. If a node is the leader node and engages in malicious behavior during this round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the first reputation threshold.

[0061] If a node is a candidate node and no malicious behavior has occurred in the current round of consensus, then the smoothing factor corresponding to that node will be increased. If a node is a candidate node and engages in malicious behavior in the current round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to the node will be increased so that the final reputation value of the node in the next round of consensus is greater than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to that node will be lowered.

[0062] Specifically, after each round of consensus is completed, the system rewards or punishes nodes based on their behavior during the consensus process, and updates the final reputation value of each node according to a formula, where a smoothing factor is used. The smoothing factor is dynamically adjusted based on the relationship between the node's reputation value and the reputation threshold from the previous round (i.e., the smoothing factor is defined based on the reputation value range and adjusted accordingly). Since the smoothing factor is a known quantity in the final reputation value formula, the final reputation value can be dynamically updated simply by adjusting the smoothing factor. In a specific embodiment, with Cmin set to 0.5, Cmid to 0.8, and Cmax to 1, the adjustment of the smoothing factor corresponding to node i based on its behavior in the consensus process can be as follows:

[0063] Scenario 1: Node i is a high-reputation leader node (Credit > 0.8). In this case, a high smoothing factor is set so that node i's reputation value update mainly inherits its historical performance. If node i does not engage in malicious behavior in this round of consensus, inheriting its historical performance and maintaining its corresponding smoothing factor can effectively suppress excessive disturbances to the reputation value caused by non-malicious behavior due to network jitter or brief anomalies, thereby maintaining the stability of the consensus-leading role. However, once such a node engages in malicious behavior, although its reputation value drops relatively little, it is still enough to cause it to fall below the first reputation threshold (e.g., 0.8), automatically losing its aggregate signature and group coordination permissions, thus achieving dynamic reclamation of high-privilege roles.

[0064] Scenario 2: Node i is a candidate node with medium credit (0.5 ≤ Credit ≤ 0.8). In this case, a medium smoothing factor is set so that node i can receive a significant positive incentive when it continues to participate in consensus honestly. That is, the smoothing factor corresponding to node i is increased, pushing its credit value to converge towards the leader interval. If node i violates the rules, sufficient penalties are imposed to quickly demote it to a member node. That is, the smoothing factor corresponding to node i is decreased so that the final credit value of node i in the next round of consensus is less than 0.5, thereby strengthening the behavior guidance mechanism of intermediate layer nodes.

[0065] Scenario 3: Node i is a member node with low reputation (Credit < 0.5). In this case, a low smoothing factor is set to give node i high behavioral sensitivity: continuous compliant operation can quickly restore its reputation value to above the second reputation threshold (such as 0.5), regaining its eligibility to participate in the core consensus, reflecting the system's fault tolerance and self-healing capabilities; conversely, if node i continues to act maliciously, its final reputation value will quickly approach the lower limit and it will be excluded from the consensus process for a long time, effectively preventing malicious nodes from continuously consuming network resources and launching potential attacks.

[0066] In a preferred embodiment, referring to the three cases above, the smoothing factor corresponding to node i The settings are as follows: in," "Node i represents a high-reputation leader node in the (k-1)th round of consensus, and its smoothing factor is set to 0.95, which is a high smoothing factor." "This means that node i is a candidate node with medium credibility in the (k-1)th round of consensus, and its smoothing factor is set to 0.85, which is a medium smoothing factor." "This means that node i is a low-reputation member node in the (k-1)th round of consensus, and its smoothing factor is set to 0.7, which is a low smoothing factor."

[0067] This invention also provides a computer program product.

[0068] Various embodiments of the methods and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementation in one or more computer program products, which may include one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be an application-specific or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0069] This invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a blockchain-based reputation consensus method as provided in all embodiments of this invention: Based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, an intermediate value for calculating the reputation value of each node in the current round of consensus is obtained; based on the final reputation value of each node in the previous round of consensus, the intermediate value for calculating the reputation value, and a smoothing factor, the current final reputation value of each node in the current round of consensus is obtained; based on the relative sizes of all current final reputation values, the current final reputation value ranked at a preset position is determined as a threshold value; based on the current final reputation value, the threshold value, a preset first reputation threshold, and a preset second reputation threshold, a leader node, candidate nodes, and member nodes are determined; the second reputation threshold is greater than 0 and less than the first reputation threshold; consensus on the leader node is achieved based on candidate nodes and member nodes through a hierarchical aggregation signature mechanism; the hierarchical aggregation signature mechanism is a fusion mechanism of the BLS aggregation signature mechanism with provable ownership and the hierarchical consensus mechanism; based on the behavior of each node in the consensus, the smoothing factor corresponding to each node is adjusted. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor electronic devices, apparatuses, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires; portable computer disks; hard disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM or flash memory); optical fiber; portable compact disk read-only memory (CD-ROM); optical storage devices; magnetic storage devices; or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an electronic device, apparatus, or device that can be executed by instructions.

[0070] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in conjunction with an electronic device, apparatus, or device that executes instructions.

[0071] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0072] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0073] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A blockchain-based reputation consensus method, characterized in that, include: Based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value of the reputation value of each node in the current round of consensus is obtained. Based on the final reputation value of each node in the previous consensus, the intermediate value and the smoothing factor are calculated to obtain the current final reputation value of each node in the current consensus. Based on the relationship between all current final reputation values, the current final reputation value ranked in the preset position is determined as the threshold value; Leader nodes, candidate nodes, and member nodes are determined based on the current final reputation value, threshold value, preset first reputation threshold, and preset second reputation threshold; the second reputation threshold is greater than 0 and less than the first reputation threshold. A hierarchical aggregation signature mechanism is used to achieve consensus on the leader node based on candidate nodes and member nodes. The hierarchical aggregation signature mechanism is a fusion of the BLS aggregation signature mechanism with provable ownership and the hierarchical consensus mechanism. Adjust the smoothing factor for each node based on its behavior in the consensus process.

2. The blockchain-based reputation consensus method according to claim 1, characterized in that, The leader node is determined based on the final reputation score, the threshold score, the preset first reputation threshold, and the preset second reputation threshold, including: If the current final reputation value is greater than a preset first reputation threshold and is greater than or equal to the threshold value, then the corresponding node is determined as a leader node; the first reputation threshold is greater than 0 and less than 1. If the current final reputation value is less than or equal to the first reputation threshold and greater than or equal to the second reputation threshold, then the node corresponding to the current final reputation value is determined as a candidate node. If the current final reputation value is less than the second reputation threshold, then the corresponding node is determined as a member node.

3. The blockchain-based reputation consensus method according to claim 1 or 2, characterized in that, Layered aggregation signature mechanisms include: After each node verifies the legality of the transaction request sent by the leader node of its group, a corresponding signature is generated. If the generated signature is determined to be a valid signature based on the preset public key binding proof, the aggregate signature and aggregate public key within the group are calculated. Each leader node broadcasts the calculated aggregate signature and aggregate public key within its group to other groups. Each leader node obtains the intra-group aggregate signature and intra-group aggregate public key from other leader nodes through inter-group broadcast, and obtains the global aggregate signature and global aggregate public key based on the intra-group aggregate signature and intra-group aggregate public key; Each leader node broadcasts the global aggregate signature and the global aggregate public key to its respective group nodes.

4. The blockchain-based reputation consensus method according to claim 3, characterized in that, The hierarchical aggregation signature mechanism also includes: When any node obtains the global aggregate signature and the global aggregate public key, it generates the corresponding bilinear pair for verification based on the public parameters, the global aggregate signature, the global aggregate public key, and the message to be verified. A deterministic challenge value is generated using a collision-resistant hash function. If substituting the deterministic challenge value into the bilinear pair verification makes the equation true, then the global aggregate signature is accepted; otherwise, the global aggregate signature is rejected.

5. The blockchain-based reputation consensus method according to any one of claims 1-4, characterized in that, Based on the behavior of each node in the consensus process, adjust the smoothing factor corresponding to each node, including: If a node is a leader node and has not engaged in malicious behavior in the current round of consensus, then the smoothing factor corresponding to that node remains unchanged. If a node is a leader node and engages in malicious behavior during this round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the first reputation threshold.

6. The blockchain-based reputation consensus method according to any one of claims 1-4, characterized in that, Based on the behavior of each node in the consensus process, adjust the smoothing factor corresponding to each node, including: If a node is a candidate node and no malicious behavior has occurred in the current round of consensus, then the smoothing factor corresponding to that node will be increased. If a node is a candidate node and engages in malicious behavior in the current round of consensus, the smoothing factor corresponding to that node will be lowered so that the final reputation value of that node in the next round of consensus is less than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to the node will be increased so that the final reputation value of the node in the next round of consensus is greater than the second reputation threshold. If a node is a member node and no malicious behavior has occurred in this round of consensus, the smoothing factor corresponding to that node will be lowered.

7. The blockchain-based reputation consensus method according to any one of claims 1-4, characterized in that, Based on the direct trust value, incentive trust value, and consensus participation degree of each node participating in the consensus in the blockchain, the intermediate value of the reputation value of each node in the current round of consensus is obtained, including: The direct trust value of each node is calculated based on the number of successful and failed transactions at each node. Based on the final reputation value, incentive magnitude, and adjustment sensitivity of each node in the previous consensus, the incentive trust value of each node is calculated. The consensus participation of each node is calculated based on the total number of transactions in the blockchain and the number of transactions completed by a single node; if a single node's transaction is successful, the number of transactions completed by that single node is 1, otherwise it is -1. The direct trust value, incentive trust value, and consensus participation are weighted and summed. The result of the weighted sum is processed by a pre-determined function to obtain the intermediate value of the reputation value of each node in the current round of consensus.

8. A computer program product, comprising a computer program, characterized in that, When a computer program is executed by a processor, it implements a blockchain-based reputation consensus method according to any one of claims 1-7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements a blockchain-based reputation consensus method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a blockchain-based reputation consensus method as described in any one of claims 1-7.

Images