An asynchronous network consensus method and system based on a reputation model

Abstract

This invention discloses an asynchronous network consensus method and system based on a reputation model, belonging to the field of consensus algorithm technology. It aims to solve the problems of low efficiency, high latency, and frequent leader election failures in asynchronous network environments. The method is divided into a broadcast phase and a consensus phase: In the broadcast phase, broadcast nodes encode erasure codes into message fragments and distribute them; receiving nodes verify these fragments and store them in the corresponding priority queues. In the consensus phase, each node generates a binary value vector based on its priority queue and distributes it across the network. A leader is elected based on the reputation value calculated by each node. An asynchronous binary consensus protocol is used to reach a consensus on the leader's validity, determining a multi-value Byzantine consensus result. Finally, the original message is requested and restored from the node indicated by the result. Erasure coding reduces communication overhead, and the reputation model reduces the number of consensus failures, improving system throughput, reducing latency, and enhancing stability and efficiency in asynchronous network environments.

Description

Technical Field

[0001] This invention relates to the field of consensus algorithm technology, and in particular to an asynchronous network consensus method and system based on a reputation model. Background Technology

[0002] Asynchronous networks refer to communication models that do not rely on assumptions about upper bounds in message transmission time. They allow messages to be delayed, out of order, or even lost, and nodes cannot rely on a global synchronization clock or a fixed timeout mechanism to determine the network state. Consensus mechanisms, as the core of ensuring data consistency and security in distributed systems, are traditionally designed based on synchronous or partially synchronous models, relying on factors such as node computing power and stake ratios to determine decision-making power. However, in open network environments, nodes exhibit heterogeneous performance, significant behavioral differences, and wide geographical distribution. Traditional consensus mechanisms have significant limitations in dealing with uncertainties such as network latency, message loss, and node downtime, making them difficult to directly apply to asynchronous network models.

[0003] In recent years, consensus frameworks for asynchronous networks have gradually developed, maintaining the security and termination of protocols in the absence of synchronization assumptions through mechanisms such as event-driven mechanisms, randomized decision-making, and verifiable message propagation. In these frameworks, reputation mechanisms are introduced to enhance system robustness. Dynamic reputation models are established through continuous evaluation of node historical behavior and response patterns, prioritizing nodes with high reputation values ​​in message propagation and voting weighting, thereby mitigating the uncertainty caused by information asymmetry and latency in asynchronous networks.

[0004] However, existing asynchronous consensus methods incorporating reputation mechanisms still have several shortcomings. Some schemes rely on global state information for reputation value calculation, leading to throughput limitations as the system scales up. Furthermore, there is a lack of effective mechanisms to address partitioning or temporary node disconnection in asynchronous networks, easily causing reputation evaluation delays or even misjudgments. Simultaneously, the real-time nature of reputation updates is difficult to guarantee; attackers may obtain high reputation values ​​by faking short-term normal behavior. Moreover, the high coupling between the reputation mechanism and the underlying consensus protocol affects the system's flexibility and security. These factors collectively limit the performance and practical value of asynchronous consensus methods in complex network environments. Summary of the Invention

[0005] This invention proposes an asynchronous network consensus method and system based on a reputation model. It aims to address the challenges of traditional consensus protocols in asynchronous network environments. These protocols rely on synchronization assumptions or fixed timeout mechanisms, making them ill-suited for complex scenarios such as unpredictable message delays and uncertain node behavior. This results in limited system throughput and increased consensus latency. Furthermore, during random elections, the lack of effective evaluation of node historical behavior leads to excessive leader election failures, triggering frequent rollback operations and impacting the overall convergence speed and stability of the protocol. By introducing a two-stage processing mechanism of broadcast and consensus, the invention addresses these issues. In the broadcast stage, erasure coding and threshold signature technologies are used to reduce communication overhead, and priority queues are used to achieve ordered caching and decoupling of messages. In the consensus stage, a reputation evaluation model is introduced for leader election, combined with an asynchronous binary consensus protocol to verify and confirm the election results. This approach reduces invalid election rounds while ensuring security, thereby improving the system's processing efficiency and robustness in asynchronous networks.

[0006] On the one hand, an asynchronous network consensus method based on a reputation model is provided, comprising N nodes, where N is a positive integer greater than or equal to 2. When any node acts as a broadcast node, the remaining N-1 nodes act as receiving nodes, including the following process:

[0007] The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node;

[0008] The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node;

[0009] After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into the priority queue maintained locally.

[0010] Each node generates a binary value vector based on its locally maintained priority queue and distributes the vector to all nodes;

[0011] Each node elects a leader based on its reputation value, and the validity of the selected leader is determined through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result.

[0012] Based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result.

[0013] Furthermore, the broadcast node receives information from the client and encodes it into message fragments. Specifically, the broadcast node receives information from the client, stores and packages it into a message, and after the message size reaches a threshold, it encodes the message into message fragments using erasure coding.

[0014] Based on the message fragments, the root and branches of the Merkel tree are calculated, and the message fragments, branches, and root are sent to the receiving node.

[0015] Furthermore, the broadcast node verifies the validity of the returned signature fragments. When the number of valid signature fragments collected reaches N- f At that time, the aggregated signature is generated as a complete signature, in which This represents the maximum allowed Byzantine nodes.

[0016] Furthermore, after the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into the priority queue maintained locally. Specifically, after receiving the complete signature sent by the broadcast node, the receiving node verifies the validity of the complete signature through a signature verification function. After the verification is successful, it confirms that the broadcast is complete and stores the message fragment received from the broadcast node into the priority queue maintained locally corresponding to that broadcast node.

[0017] Furthermore, each node generates a binary value vector based on the head status of all priority queues maintained locally. Specifically, it checks whether there is a message fragment at the head of each priority queue. If there is, the corresponding bit of the vector is set to 1; otherwise, it is set to 0.

[0018] Furthermore, the reputation value is calculated as follows:

[0019] ,

[0020] in, Indicates the current round. Number the nodes. It is the time decay factor. and These are the weights for success and failure, respectively. Let be a binary value, representing the result when node i is the leader in round t. =1 indicates that consensus was successful. =0 indicates that consensus has failed.

[0021] Furthermore, each node elects a leader based on its reputation score, and the validity of the selected leader is reached through an asynchronous binary consensus protocol to determine the multi-valued Byzantine consensus result, specifically as follows:

[0022] After a leader node is elected based on the current reputation value of each node, each node obtains the distribution result of the leader node stored locally and broadcasts the distribution result to other nodes.

[0023] Each node maintains a vote vector, and when it receives at least 2 votes... After +1 other node broadcasts the valid distribution results To determine the maximum allowed Byzantine node value, the element value in the vote vector corresponding to the leader node is used as the input to the asynchronous binary consensus protocol.

[0024] The asynchronous binary consensus protocol is run. If the output is 1, the binary value vector of the leader node is used as the multi-valued Byzantine consensus result. If the output is 0, the process is rolled back to the election phase to re-elect the leader and update the reputation value of the leader node.

[0025] Furthermore, based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result, specifically as follows:

[0026] Based on the nodes corresponding to the bits with a value of 1 in the multi-value Byzantine consensus result, at least 2 nodes with the highest reputation ranking in the network are considered. f +1 node sends a recovery request to obtain the original message fragment of the corresponding node. The maximum allowed Byzantine nodes;

[0027] Receive the returned message fragments and their corresponding Merkle branches and root, and verify their validity;

[0028] When the number of valid message fragments collected reaches N-2 f At that time, the original message of the corresponding node is recovered by erasure coding decoding, and all the recovered original messages are combined to obtain the final consensus result.

[0029] On the other hand, an asynchronous network consensus system based on a reputation model includes: N nodes, where N is a positive integer greater than or equal to 2, wherein when any node acts as a broadcast node, the other N-1 nodes act as receiving nodes, and all nodes are interconnected.

[0030] The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node;

[0031] The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node;

[0032] After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into the priority queue maintained locally.

[0033] Each node generates a binary value vector based on its locally maintained priority queue and distributes the vector to all nodes;

[0034] Each node elects a leader based on its reputation value, and the validity of the selected leader is determined through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result.

[0035] Based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] This invention decouples and streamlines the broadcast and consensus phases by introducing a priority queue mechanism. In traditional Byzantine consensus protocols, the consensus phase typically waits for the current round of message broadcasting to complete before starting, resulting in a significant synchronous dependency in the system execution flow and making it difficult to fully utilize network and computing resources. By maintaining a priority queue corresponding to all nodes locally on each node, nodes can enter consensus processing early based on the queue head status after broadcasting part of the message, without waiting for the entire broadcast to finish. Broadcasting and consensus can thus proceed in parallel like a pipeline, significantly reducing idle waiting time between phases and effectively improving the overall throughput of the system in high-concurrency scenarios.

[0038] By introducing a reputation model, the number of failures and rollbacks in the Binary Byzantine Fault Dialogue (BBT) protocol is reduced. In BBT protocols, improper leader selection or unstable node behavior can lead to multiple rounds of decision-making failures, resulting in frequent rollbacks and significantly increasing the overall execution time of the protocol. To address this issue, this invention designs and introduces a reputation model into the protocol. This model quantifies and scores nodes based on factors such as their historical behavior, response latency, voting consistency, and the presence of Byzantine behavior. Leader election prioritizes nodes with higher reputations, making the system more reliant on participants with stable behavior, rapid responses, and no malicious history. Through this mechanism, the protocol effectively avoids low-reputation nodes frequently assuming key roles during operation, thereby reducing the number of failures and rollbacks in the BBT protocol, lowering the cost of repeated execution, shortening the overall consensus time, and improving the stability and efficiency of the protocol. Attached Figure Description

[0039] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0040] Figure 1 This is a flowchart of the method according to Embodiment 1 of the present invention;

[0041] Figure 2 This is an overall protocol flowchart of Embodiment 1 of the present invention;

[0042] Figure 3 This is a schematic diagram of the broadcast stage process of Embodiment 1 of the present invention;

[0043] Figure 4 This is a schematic diagram of the multi-value Byzantine protocol process according to Embodiment 1 of the present invention;

[0044] Figure 5 This is a comparison of the number of runs of different binary consensus protocols in Embodiment 1 of the present invention;

[0045] Figure 6 This is a comparison of the delays of different algorithms in Embodiment 1 of the present invention;

[0046] Figure 7 This is a comparison of the throughput of different algorithms when the number of nodes is 4 in Embodiment 1 of the present invention;

[0047] Figure 8 This is a comparison of the throughput of different algorithms when the number of nodes is 16 in Embodiment 1 of the present invention;

[0048] Figure 9 This is a comparison of the throughput of different algorithms when the number of nodes is 64 in Embodiment 1 of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. Those skilled in the art should understand that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0050] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0051] Example 1

[0052] In asynchronous network models, the system makes no upper bound assumptions about message transmission time. Message delays are unpredictable, potentially extremely short or arbitrarily long, and protocols cannot rely on fixed timeout mechanisms to determine node status. Messages may arrive out of order or be temporarily lost, and there is no global synchronization clock; the independent clock errors of each node are uncontrollable and cannot be used for strict synchronization coordination. The online status of nodes is also uncertain, potentially crashing, recovering, or temporarily losing connection at any time. However, the protocol still needs to maintain security and activity under such extreme environments. This model is more stringent than synchronous and partially synchronous networks, and better reflects the uncontrollable latency communication characteristics of the real-world Internet environment. This invention is applicable to node communication in such asynchronous networks.

[0053] like Figure 1As shown, this embodiment provides an asynchronous network consensus method based on a reputation model to solve the problems of latency and throughput conflict in consensus protocols under asynchronous networks, as well as the problem of excessive failures during random election. Figure 1 This is a flowchart of the overall method according to Embodiment 1 of the present invention. The method mainly includes two core parts: a broadcast phase and a consensus phase. It can be applied to an asynchronous distributed network consisting of N nodes, where N is a positive integer greater than or equal to 2 and satisfies N ≥ 3f + 1. This represents the maximum allowed number of Byzantine nodes. When any node acts as a broadcast node, the remaining N-1 nodes act as receiving nodes, specifically including the following steps:

[0054] S101: The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node;

[0055] S102: The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node;

[0056] S103: After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into the priority queue maintained locally.

[0057] S104: Each node generates a binary value vector based on the priority queue it maintains locally, and distributes the vector to all nodes;

[0058] S105: Each node elects a leader based on its reputation value, and reaches a consensus on the validity of the selected leader through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result.

[0059] S106: Based on the multi-valued Byzantine consensus result, request and restore the original message to the corresponding node indicated by the result to obtain the final consensus result.

[0060] Figure 2 This is an overall protocol flowchart of Embodiment 1 of the present invention. In the broadcast phase, each node... The node continuously receives client information. Once the collected information reaches a preset threshold, the node packages the collected messages into a message. After the broadcast phase, each node maintains a priority queue equal to the number of nodes in the network to store message fragments received from other nodes. After another node completes its broadcast, the receiving node stores the corresponding message fragment in that node's priority queue, providing a foundation for the subsequent consensus phase.

[0061] like Figure 3 As shown, Figure 3 This is a schematic diagram of the broadcast phase process of the present invention. Specifically, in step S101, during the broadcast phase, any node acts as a broadcast node. Receive information from client C. Once the size of the collected information reaches a preset threshold, package this information into a message. Subsequently, the node use RS erasure coding technology, to erase messages Encoded into N message fragments, denoted as RS erasure coding is a linear block code based on the Galois field, possessing the maximum distance separability property, meaning that the original data can be recovered from any K data blocks. Based on this, Based on message fragmentation Constructing the root h and branches of the Merkle tree Finally, the triplet Send to the corresponding receiving node .

[0062] By introducing erasure coding technology, the communication complexity of the broadcast phase is effectively reduced. In traditional Byzantine consensus protocols, the message broadcast phase typically requires multiple rounds of full message exchange between nodes, resulting in a quadratic increase in communication complexity with the number of nodes and enormous network overhead. This invention employs a "distribute first, recover later" erasure coding mechanism. The sender divides the original message into several data blocks and generates redundant check blocks, allowing the receiver to fully recover the message even with only partial data blocks. Different nodes only need to send their corresponding fragments during the broadcast process, without repeatedly distributing the complete message, thereby significantly reducing network load, improving broadcast efficiency, and ensuring good scalability even with large-scale node deployments.

[0063] In step S102, the receiving node that receives the message fragment In the message Based on this, a signature fragment is calculated using the BLS threshold signature technique. and the message Return to broadcast node BLS threshold signature is a cryptographic technique whose core principle is to split a complete private key into multiple key shares through a secret-sharing mechanism and distribute them to different participants. Under this mechanism, as long as the number of valid signature fragments collected reaches a preset threshold (e.g., Nf), a valid complete signature can be generated; any set of signature fragments less than the threshold cannot generate a valid signature or recover the original private key, thus ensuring the security and fault tolerance of the system.

[0064] broadcast node It continuously receives signature fragments from each receiving node and verifies the validity of the signature fragments. When The number of valid signature fragments collected has reached the threshold. Then, threshold signature technology can be used to aggregate these signature fragments into a complete signature. Subsequently, the broadcast node Will Broadcast to receiving node .

[0065] In step S103, the receiving node Received broadcast node Message sent Then, the verification function verifies the validity of the signature. Once the verification is successful, the broadcast can be considered complete.

[0066] At this time, the receiving node From Message fragments received Stored locally and specifically corresponding to the sending node The priority queues are used to store message fragments that have been received from different nodes and confirmed by broadcast, providing input data for the subsequent consensus phase.

[0067] After the broadcast phase is complete, if a node needs to recover the original message that has been confirmed by consensus, it can initiate a message recovery process. Specifically, the node must send the message to at least two nodes ranked high in reputation within the network. f +1 node sends a recovery request. Node P receives the request. j It will store the message fragments corresponding to the target node, along with their Merkle branches and root. The result is returned to the requesting node. The requesting node verifies the validity of the received message fragments. The node proceeds when the number of valid message fragments collected reaches a threshold N-2. f When the original message is fully recovered, it can be recovered using RS erasure coding decoding technology.

[0068] After the broadcast phase, the protocol enters the consensus phase. Each node generates an input vector based on the head states of its N priority queues and determines the final result through a multi-valued Byzantine Fault Tolerance (MFT) consensus protocol. A flowchart of the MFT protocol is shown below. Figure 4 As shown.

[0069] Specifically, in step S104, each node Maintaining There are priority queues, among which priority queues The content is the corresponding node The broadcast content. After entering the consensus phase, each node generates an N-dimensional binary vector based on the head state of its locally maintained N priority queues. The specific rule is as follows: if a message fragment exists at the head of the priority queue corresponding to node j, then the j-th bit of vector v is set to 1; otherwise, it is set to 0. This vector must satisfy the external validity condition Q, that is, the number of bits with a value of 1 in the vector is greater than or equal to Nf, to ensure that a sufficient number of nodes participate in this round of proposal.

[0070] After generating the vector, each node sends its vector v to all other nodes through a verifiable distribution protocol. This distribution process is similar to the broadcast phase, also involving sharding, signing, and aggregation, aiming to securely and reliably "lock" each node's input vector within the entire network for subsequent consensus use. Each node stores the vector results from other nodes that it has received and successfully verified locally, for querying and verification during subsequent leader election and consensus processes.

[0071] After the distribution is complete, each node executes the broadcast process. When a node receives at least... After the completion broadcast is sent by other nodes, a... The threshold signature generates a signature fragment and broadcasts this signature fragment to all other nodes; when a node receives at least After receiving the signed fragment messages broadcast by other nodes, the nodes aggregate them into a complete signature and broadcast a completion message. If a node receives the complete signature message, it means that at least... Once the node distribution is complete, the node will abandon the remaining unfinished distribution process and broadcast a completion message.

[0072] In step S105, after vector distribution is completed, the protocol enters the leader election and consensus phase. First, each node elects the node with the highest reputation value as the leader candidate for this round. This is achieved by generating a shared random number (generated by the distributed threshold shared coin protocol) among all nodes. This random number ranges from 1 to N, and the node corresponding to this random number is the leader for that round. The reputation value is calculated as follows:

[0073] ,

[0074] in, Indicates the current round. Number the nodes. It is the time decay factor. and These are the weights for success and failure, respectively. Let be a binary value, representing the result when node i is the leader in round t. =1 indicates that consensus was successful. =0 indicates consensus failure. This formula dynamically reflects a node's recent behavior by weighting and summing the scores from each historical round, with lower weights for scores further back from the current round. It's important to note that each node maintains its own local reputation value table for all nodes, updating it synchronously based on their historical behavior. Therefore, all honest nodes have a consistent understanding of their reputation values.

[0075] By introducing a reputation model based on the historical behavior of nodes, the system can prioritize nodes with stable and reliable behavior during leader election, thereby effectively reducing the number of failures and rollbacks in the asynchronous binary consensus protocol and improving the overall consensus efficiency and stability.

[0076] After selecting a leader candidate, each node checks if the result corresponding to that leader node is empty (i.e., the result stored during the distribution phase) and broadcasts this result to other nodes. If the result for that leader is not stored locally, an empty element is broadcast. Each node maintains an initial all-zero vote vector to record the voting status for the leader candidate's validity. Upon receiving a valid stored result broadcast by another node, it sets the position in the vote vector corresponding to that leader to 1 and updates its local stored result. Only when the candidate's vector bit is 1, or at least... After all other nodes have broadcast the valid storage results, the node will then use the element value corresponding to the leader in the vote vector (i.e., the common understanding of the leader vector among all nodes) as input to start the asynchronous binary consensus protocol (ABA).

[0077] The asynchronous binary consensus protocol uses multiple rounds of voting and randomization mechanisms to make a final decision on the proposition of "whether to adopt the leader's vector". If the ABA output is 1, it means that the entire network agrees to adopt it, and the leader's binary value vector is determined as the result of the multi-valued Byzantine consensus. If the ABA output is 0, it means that this round of election has been rejected, and the protocol rolls back to the election phase to re-elect the leader, updating the leader's reputation value based on the result of this failed round, thereby reducing the probability of being elected again in the future. Through the synergy of the reputation model and the asynchronous binary consensus protocol, the system can effectively reduce invalid election rounds and improve consensus efficiency and stability.

[0078] In S106: Once the multi-valued Byzantine consensus result is determined (i.e., an N-dimensional binary vector), each node parses the vector and finds the nodes corresponding to all bits with a value of 1. These nodes are the data providers ultimately selected in this round of consensus.

[0079] Based on this, the recovery protocol is initiated. According to the result of the Binary Byzantine consensus, if it is 1, the recovery protocol can proceed. At the start of the recovery protocol, the results of the two distributed three-phase broadcasts are first broadcast. Intermediate message nodes during the three-phase broadcast process store the data (two storages corresponding to the three-phase broadcast), and simultaneously receive messages from other nodes. After receiving the message, the original message can be restored to verify that it meets the external conditions. Then, the output of the multi-valued Byzantine protocol can be obtained.

[0080] To verify the technical effectiveness of this invention, the proposed solution, along with the Honeybadger and Dumbo protocols, were implemented and compared using Python. The experiment constructed a peer-to-peer communication network based on Socket technology, and standardized the encryption library, security parameters, and message size for each protocol submission.

[0081] like Figure 5 As shown, in an experiment where the protocol was run 1000 times consecutively with different numbers of nodes, the total number of runs of the binary consensus protocol for each protocol was counted. The experimental results show that compared with the Dumbo protocol, this scheme reduces the number of ABA runs by an average of about 8.35%, and has better stability and efficiency.

[0082] like Figure 6 As shown in the latency comparison experiment with different numbers of nodes, the latency from message submission to confirmation for each protocol under different node conditions was statistically analyzed. With a small number of nodes, the latencies of the three methods are relatively similar. However, as the number of nodes increases, the latencies of the other two schemes increase significantly, while the latency of this scheme increases less compared to the other two. Compared to Honeybadger's latency, this scheme reduces latency by 43.02%, and compared to the Dumbo protocol, it reduces latency by 17.01%, demonstrating good latency performance under different conditions.

[0083] like Figures 7 to 9 As shown, comparative experiments were conducted on throughput variations with batch size in scenarios with N nodes of 4, 16, and 64. When N=4, the proposed solution maintains high throughput across all batch size scenarios, with stable growth and no obvious bottleneck. When N=16 ( Figure 8 The throughput of all three protocols decreased, but this scheme maintained the fastest growth rate without stagnation, demonstrating stronger scalability. When N=64 ( Figure 9 While the overall system throughput decreased, this solution still maintained a good growth rate compared to other protocols, further validating its scalability and performance advantages in large-scale node deployments.

[0084] Example 2

[0085] This embodiment provides an asynchronous network consensus system based on a reputation model, comprising: N nodes, where N is a positive integer greater than or equal to 2, wherein when any node acts as a broadcast node, the remaining N-1 nodes act as receiving nodes, and all nodes are interconnected;

[0086] The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node;

[0087] The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node.

[0088] Once the receiving node verifies the complete signature, it confirms the broadcast is complete and inserts the message fragment into a locally maintained priority queue.

[0089] Each node generates a binary value vector based on its locally maintained priority queue and distributes the vector to all nodes;

[0090] Each node elects a leader based on its reputation value, and the validity of the selected leader is determined through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result.

[0091] Based on the multi-valued Byzantine consensus result, request and restore the original message to the corresponding node indicated by the result to obtain the final consensus result.

[0092] It should be noted that each module in this embodiment corresponds one-to-one with each step in Embodiment 1, and their specific implementation process is the same, so it will not be repeated here.

[0093] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for asynchronous network consensus based on a reputation model, characterized in that, It contains N nodes, where N is a positive integer greater than or equal to 2. When any node acts as a broadcast node, the remaining N-1 nodes act as receiving nodes. The process includes the following steps: The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node; The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node; After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into a locally maintained priority queue. Each node generates a binary value vector based on its locally maintained priority queue and distributes the vector to all nodes; Each node elects a leader based on its reputation value, and the validity of the selected leader is determined through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result. Based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result; The credit score is calculated as follows: , wherein, denotes the current round, is the node number, is the time decay factor, and are the success and failure weights, respectively, is a binary value indicating the outcome of node i as a leader in round t, = 1 indicates consensus success, = 0 indicates consensus failure.

2. The method according to claim 1, characterized in that, The broadcast node receives information from the client and encodes it into message fragments. Specifically, the broadcast node receives information from the client, stores and packages it into a message, and after the message size reaches a threshold, it encodes the message into message fragments using erasure coding. Based on the message fragments, the root and branches of the Merkel tree are calculated, and the message fragments, branches, and root are sent to the receiving node.

3. The method according to claim 1, characterized in that, The broadcast node verifies the validity of the returned signature fragments. When the number of valid signature fragments collected reaches N- f At that time, the aggregated signature is generated as a complete signature, in which This represents the maximum allowed Byzantine nodes.

4. The method according to claim 1, characterized in that, After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into the priority queue maintained locally. Specifically, after receiving the complete signature sent by the broadcast node, the receiving node verifies the validity of the complete signature through the signature verification function. After the verification is successful, it confirms that the broadcast is complete and stores the message fragment received from the broadcast node into the priority queue maintained locally corresponding to that broadcast node.

5. The method according to claim 1, characterized in that, Each node generates a binary value vector based on the head status of all priority queues maintained locally. Specifically, it checks whether there is a message fragment at the head of each priority queue. If there is, the corresponding bit of the vector is set to 1; otherwise, it is set to 0.

6. The method according to claim 1, characterized in that, Each node elects a leader based on its reputation score. An asynchronous binary consensus protocol is used to reach a consensus on the validity of the selected leader, thus determining the multi-valued Byzantine consensus result. Specifically: After a leader node is elected based on the current reputation value of each node, each node obtains the distribution result of the leader node stored locally and broadcasts the distribution result to other nodes. Each node maintains a vote vector, and when it receives at least 2 votes... After +1 other node broadcasts the valid distribution results To determine the maximum allowed Byzantine node value, the element value in the vote vector corresponding to the leader node is used as the input to the asynchronous binary consensus protocol. The asynchronous binary consensus protocol is run. If the output is 1, the binary value vector of the leader node is used as the multi-valued Byzantine consensus result. If the output is 0, the process is rolled back to the election phase to re-elect the leader and update the reputation value of the leader node.

7. The method according to claim 1, characterized in that, Based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result, specifically: Based on the nodes corresponding to the bits with a value of 1 in the multi-value Byzantine consensus result, at least 2 nodes with the highest reputation ranking in the network are considered. f +1 node sends a recovery request to obtain the original message fragment of the corresponding node. The maximum allowed Byzantine nodes; Receive the returned message fragments and their corresponding Merkle branches and root, and verify their validity; When the number of valid message fragments collected reaches N-2 f At that time, the original message of the corresponding node is recovered by erasure coding decoding, and all the recovered original messages are combined to obtain the final consensus result.

8. An asynchronous network consensus system based on a reputation model, employing an asynchronous network consensus method based on a reputation model as described in any one of claims 1-7. Its features are: It includes: N nodes, where N is a positive integer greater than or equal to 2. When any node acts as a broadcast node, the other N-1 nodes act as receiving nodes, and all nodes are interconnected. The broadcast node receives information from the client and encodes it into message fragments, then sends the message fragments to the receiving node; The broadcast node collects the signature fragments returned by each receiving node, aggregates them to generate a complete signature, and sends the complete signature to the receiving node; After the receiving node verifies the complete signature, it confirms that the broadcast is complete and inserts the message fragment into a locally maintained priority queue. Each node generates a binary value vector based on its locally maintained priority queue and distributes the vector to all nodes; Each node elects a leader based on its reputation value, and the validity of the selected leader is determined through an asynchronous binary consensus protocol to determine the multi-value Byzantine consensus result. Based on the multi-valued Byzantine consensus result, the original message is requested and restored to the corresponding node indicated by the result to obtain the final consensus result.

9. The system according to claim 8, characterized in that, Each node participates in an election based on its own reputation value to obtain a leader. An asynchronous binary consensus protocol is used to reach a consensus on the validity of the selected leader, thereby determining the multi-valued Byzantine consensus result. Specifically: After a leader node is elected based on the current reputation value of each node, each node obtains the distribution result of the leader node stored locally and broadcasts the distribution result to other nodes. Each node maintains a vote vector, and when it receives at least 2 votes... After +1 other node broadcasts the valid distribution results To determine the maximum allowed Byzantine node value, the element value in the vote vector corresponding to the leader node is used as the input to the asynchronous binary consensus protocol. Run the asynchronous binary consensus protocol. If the output is 1, then the binary value vector of the leader node is taken as the multi-valued Byzantine consensus result. If the output is 0, roll back to the election phase to re-elect a leader and update the reputation value of the leader node.

Images