Priority-driven Byzantine fault-tolerant non-master consensus optimization method and system

Abstract

The invention discloses a priority-driven Byzantine fault-tolerant non-master consensus optimization method and a priority-driven Byzantine fault-tolerant non-master consensus optimization system. The method is characterized by comprising the steps of building a block chain cluster, constructing a multi-consensus instance structure, selecting an optimal node as a main node to initiate instance proposal, performing multiple rounds of voting to achieve consensus of blocks, performing differentiated processes on different types of consensus blocks, completing receipt and persistence on executed blocks and the like. The system comprises a consensus protocol module, an execution module, a storage module, an authority management module, a lock module, a priority management module, an anchor point processing module and a network communication module. Compared with the prior art, the method has the advantages that the consensus delay is reduced, the system throughput is improved, the fault tolerance and the engineering practicability are good, and the method is particularly suitable for multiple scenes such as an alliance chain, a financial system and a distributed database and is applied to improving the data processing capacity, sharing, tracking and verifying supply data and quickly processing cross-border payment.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain consensus mechanism, and in particular to a priority-driven Byzantine fault-tolerant masterless consensus optimization method and system thereof. Background Art

[0002] The in-depth application of blockchain technology in key areas such as finance, supply chain, and government affairs has placed higher demands on the performance, scalability, and robustness of the underlying consensus protocol. While ensuring security, traditional Byzantine Fault Tolerant (BFT) consensus protocols generally face challenges such as limited throughput, significant single-instance bottlenecks, and the impact of master node failure on system performance. In recent years, masterless consensus protocols have become a key area of ​​evolution for blockchain consensus mechanisms, aiming to improve system decentralization by eliminating master node dependency. However, existing masterless consensus protocols often operate in a single-instance mode, failing to fully utilize the resource parallelism between nodes and being susceptible to bottlenecks when handling highly concurrent transactions. Furthermore, in asynchronous network environments, the execution efficiency of different nodes in an instance varies significantly, leading to increased waiting costs during synchronization between instances, thus impacting overall system performance.

[0003] To alleviate the above problems, some studies have proposed a multi-instance consensus mechanism, which distributes system transactions to multiple instances for independent processing through state partitioning, thereby improving system throughput. However, the current multi-instance masterless consensus method still faces the following challenges: First, the consensus efficiency between different instances varies significantly, and there is a lack of feedback adjustment on the running status, which causes fast instances to wait for slow instances, limiting the system execution throughput; second, there is a lack of a refined master node election and synchronization sorting mechanism, and it is impossible to dynamically adjust the distribution of responsibilities based on the stability and historical performance of the nodes, which can easily lead to frequent master changes and synchronization bottlenecks. In addition, when introducing node priorities, the existing solutions have not yet solved the problem of priority viewing. Figure 1 Different nodes may have different understandings of priorities, which in turn affects the consensus results and system consistency.

[0004] In summary, existing technologies suffer from issues such as inter-instance synchronization blocking, high fault recovery overhead, and significant long-tail latency. Therefore, there is an urgent need to develop a masterless consensus method that supports asynchronous multi-instance operation, introduces robustness and performance priority control in the master change and synchronization process, and features a consistent priority reconfiguration mechanism, thereby improving overall system performance and stability. Summary of the Invention

[0005] This invention addresses the shortcomings of existing technologies by providing a priority-driven, Byzantine-fault-tolerant, masterless consensus optimization method and system. This method intelligently optimizes the master election and inter-instance synchronization processes by calculating robustness and performance priorities for each consensus instance and its master node. This reduces the impact of slow instances on system performance in dynamic network environments, enhances system robustness, and significantly reduces the long-tail distribution of transaction latency, significantly improving system performance and robustness in dynamic network and fault-prone environments. This method introduces robustness and performance priority mechanisms to optimize instance master election and cross-instance synchronization, respectively, enhancing system robustness and performance in heterogeneous environments and under interference from malicious nodes. The robustness priority evaluates node stability based on historical view information, prioritizing the election of highly trusted nodes as masters. The performance priority adjusts the execution order of synchronized blocks based on the order in which instances are submitted, reducing inter-instance latency. To ensure consistent priority calculation in a distributed environment, the system incorporates a priority reconfiguration mechanism based on anchor blocks, coordinating global updates within each round. Experimental results demonstrate that this invention effectively reduces consensus latency, improves system throughput, and exhibits excellent fault tolerance and engineering practicality. The present invention optimizes the key links of the consensus process by introducing a dynamic priority mechanism based on allowing multiple consensus instances to run asynchronously. The method of the present invention calculates the robustness priority and performance priority for each consensus instance and its master node, and realizes intelligent optimization of the master node election and inter-instance synchronization process, thereby reducing the impact of slow instances on system performance in a dynamic network environment, enhancing system robustness, and significantly reducing the long-tail distribution of transaction delays. In addition, for cross-instance transaction processing, a priority-driven synchronization optimization mechanism is introduced to ensure system consistency. Reduce ineffective waiting time. The priority calculation mechanism, fault recovery optimization mechanism, and adaptive reconfiguration mechanism in this invention can effectively improve system throughput and response efficiency in scenarios with heterogeneous node performance, network fluctuations, or the presence of Byzantine nodes. This enables the system to be used in improving data processing capabilities, sharing, tracking, and verifying supply data, and rapidly processing cross-border payments. It has good fault tolerance and engineering practicality and is particularly suitable for multiple scenarios such as consortium chains, financial systems, and distributed databases, as well as application scenarios in consortium chain environments that improve consensus efficiency, system robustness, and cross-instance synchronization performance.

[0006] The specific technical solution for achieving the objectives of the present invention is: a priority-driven Byzantine fault-tolerant masterless consensus optimization method, which is characterized in that the method specifically includes the following steps: Step 1: Build a blockchain cluster, configure the identity information of each node in the network, and start nodes that support multi-instance asynchronous consensus. The cluster is a collection of different server nodes in the inter-node network; the inter-node network is assumed to be partially synchronous, and an upper bound on the delay allowed for message transmission in the inter-node network is allowed; the cluster contains a total of N nodes, of which at most f nodes behave as Byzantine nodes, and the relationship N ≥ 3f + 1 is satisfied. Public key infrastructure (PKI) is used to authenticate the identities of nodes, and communication between nodes is carried out through authenticated channels; each node contains a unique public-private key pair and an IP address.

[0007] Step 2: Each node uses deterministic rules to elect the initial master node, uses the state partitioning algorithm to divide the global state into multiple subsets, and builds a multi-consensus instance structure based on this. The specific steps include: Step 2-1: Use a deterministic partitioning algorithm P(s) to partition all possible system states into non-overlapping subsets, generating multiple non-overlapping state subsets Si; Step 2-2: Divide transactions into intra-domain transactions tIS and cross-domain transactions tCS based on the state subsets they access. Intra-domain transactions tIS only involve a single state subset, while cross-domain transactions tCS involve states in multiple state subsets. Step 2-3: Each state subset after division corresponds one-to-one to a parallel consensus instance. The master node in each consensus instance has the right to propose transactions related to this state.

[0008] Step 3: Based on the robustness priority calculation results, the optimal node is selected as the master node in each round to initiate instance proposals. The Byzantine Fault Tolerance protocol is used to execute the in-instance process. The master node selection is based on the robustness priority mechanism, which is used to dynamically select a more stable and capable node as the master node in the consensus instance. The specific steps include: Step 3-1: Each node maintains a local view history information table, which records the view number and corresponding master node ID of the blocks submitted in the current round in this instance, and is used to identify the block segments led by different master nodes; Step 3-2: Based on the view changes in the block sequence, consecutive blocks generated by the same master node with the same view number are divided into a view segment. Each consensus round may contain multiple view segments, representing the master node switching during the consensus process. Step 3-3: For each view segment, the system calculates its penalty value according to the set rules. The penalty value is composed of the following parts: 1) The initial penalty generated by view switching, which is used to reflect the protocol overhead caused by frequent master node switching; 2) The compensation value given according to the number of blocks successfully copied and submitted in the view segment, which is used to incentivize efficient submission; 3) The additional reward value given when the view segment is the last segment, which is used to encourage the final successful submission; Step 3-4: Sum up the penalty values ​​of all view segments dominated by a master node in the current round to obtain the total robustness penalty value of the master node in the current instance; Step 3-5: Sort all nodes according to their total robustness penalty value to generate a priority sequence. The node with the smaller penalty value has a higher priority. Steps 3-6: All nodes obtain the unified priority ranking results under the current consensus round based on the anchor snapshot or other consensus synchronization methods, and select the node with the highest priority as the master node, which initiates the consensus proposal and continues the subsequent consensus process.

[0009] Step 4: Each node conducts multiple rounds of voting according to the consensus protocol to reach a consensus on the block and enter the subsequent execution process accordingly.

[0010] Step 5: Execute differentiated processes for different types of consensus blocks: Intra-domain blocks are directly executed, while cross-domain blocks enter the synchronization process. The block sorting and execution order are optimized through the priority mechanism. Specifically, a performance priority mechanism is introduced to optimize the cross-instance synchronization process, reduce the waiting time of high-performance instances, and thus improve the overall execution efficiency of the system. The specific steps include: Step 5-1: During each round of cross-instance synchronization, the system divides the synchronization process into three phases: binding phase, synchronization consensus phase, and unbinding phase. During the synchronization consensus phase, each instance must wait for all bound instances to reach local consensus before proceeding with sorting and joint execution. Step 5-2: To prevent high-performance instances from being blocked by low-performance instances, each node locally records the timestamp of each consensus instance completing block submission during the synchronization phase, and uses this timestamp to sort the multiple consensus instances participating in this round of synchronization; Step 5-3: The local sorting result indicates the order in which the node processes each instance. Each instance is assigned a linearly distributed priority value, ranging from positive to negative, to reflect the speed of submission. Step 5-4: Because the synchronization process involves multiple nodes, each node may have different local priority rankings. The system aggregates the local priorities across all nodes participating in the synchronization process to calculate a global performance priority value for each instance, reflecting the instance's submission speed from a collective perspective. Step 5-5: For each round of synchronization, the system sorts all participating instances according to global performance priority and generates an execution sequence within the synchronization process, so that instances with higher priorities are completed first in the joint execution without waiting for other slower instances; Steps 5-6: If multiple synchronization processes are performed concurrently at multiple times, the system accumulates the global performance priority values ​​of each instance in each round of synchronization process, and finally generates a global performance priority sequence. This sequence is referenced in subsequent synchronizations to determine the execution order between instances, thereby improving the overall concurrent execution efficiency and system throughput.

[0011] Step 6: The node completes the receipt of the executed block and persists it. At the same time, it records the priority of this round and performs consistency reconfiguration to support the next round of process optimization. The priority reconfiguration mechanism is introduced to ensure that the nodes in the system have a consistent view of the robustness priority and performance priority in each round, thereby ensuring the coordination of the consensus process and the synchronization process. The specific steps include: Step 6-1: During system operation, the system periodically enters the priority reconfiguration phase according to the preset time or number of block rounds. The reconfiguration is based on rounds as the basic unit. Step 6-2: A consensus instance is set as the master instance in the system. The master instance is responsible for initiating the priority reconfiguration process in each round. Step 6-3: The master instance initiates the reconfiguration process by constructing an anchor block. The anchor block contains the current block height vectors of each consensus instance in the system, which is used to uniformly record the system status snapshot. Step 6-4: All nodes participate in the consensus process of the anchor block. The submission of the anchor block is regarded as the trigger point of a round switch, indicating that the current priority view will enter the update phase; Step 6-5: After the anchor block is submitted, all nodes recalculate the robustness priority and performance priority based on the running status and submission records of the previous round of consensus instance, and use the updated results as the basis for leader selection and sorting in the next round of consensus process and synchronization process; Step 6-6: This priority update is only performed when the anchor block consensus is successful, to ensure that all correct nodes reach a consistent priority view within the same round, thereby avoiding consensus process disagreements or disordered execution order due to inconsistent priorities; Steps 6-7: The master instance settings, anchor trigger frequency, and priority update strategy can be flexibly configured through system parameters to achieve a dynamic trade-off between system stability and operational performance.

[0012] Step 7: The blocks that have been executed on each node can directly issue receipts to users for the transactions on them, and then enter the persistence process to form a consistent persistent chain structure.

[0013] A Byzantine fault-tolerant, masterless consensus system constructed using a priority-driven Byzantine fault-tolerant, masterless consensus optimization method is characterized in that the system includes: a consensus protocol module, an execution module, a storage module, a permission management module, a lock module, a priority management module, an anchor processing module, and a network communication module, which implement state partitioning, consensus execution, synchronization process, and priority reconfiguration mechanism. The consensus protocol module is used to execute a deterministic state partitioning algorithm to divide the system state into multiple non-overlapping state subsets and divide transactions into intra-domain transactions and cross-domain transactions. The consensus protocol module is responsible for the consensus proposal and consensus process execution of the master node in each consensus instance. The execution module is used to execute transactions in the block according to the priority sorting and synchronization control results, and update the system status, supporting multi-instance concurrent execution and cross-instance synchronous execution; The storage module is used to store blockchain ledger data, status snapshots, anchor block information and transaction execution records, providing data persistence support for the system; The rights management module is based on the public key infrastructure (PKI) system to achieve identity authentication, rights allocation and access control of nodes in the blockchain cluster; The lock module is used to manage access locks for a subset of system states, ensuring state consistency during concurrent execution of multiple instances and cross-domain transaction processing; The priority management module is used to calculate the robustness priority and performance priority based on the historical view and submission time in each round of consensus, and supports node sorting and decision-making in the master change process and synchronization process; The anchor processing module is used by the master instance to initiate and reach consensus on the anchor block, unify system rounds and trigger priority reconfiguration to ensure that all nodes maintain a consistent priority view; The network communication module is used to transmit consensus messages, transaction information, anchor blocks and status snapshots between nodes, and supports high-reliability communication under partially synchronous network conditions.

[0014] Compared with the prior art, the present invention has the following beneficial technical effects and significant technical progress: 1) The present invention solves the performance bottleneck problem of existing masterless consensus in dynamic environments by implementing a priority-driven dynamic optimization process. Specifically: Robustness priority optimizes master node election: Node stability (robustness priority) is calculated based on historical view changes and block submission information, making it easier for high-priority nodes to become master nodes, reducing frequent view switching and additional consensus overhead caused by malicious or inefficient master nodes; Performance priority optimizes cross-instance synchronization: Performance priority is calculated based on the submission order of each instance block during the historical synchronization process, allowing high-priority instances to execute in advance when processing cross-instance transactions, avoiding the throughput reduction caused by waiting for slow instances (corresponding to solving the inter-instance synchronization blocking problem in the background technology); Rounded security reconfiguration mechanism: System-level consistency snapshots are established through anchor blocks as the security basis for priority calculation, achieving a balance between low overhead and high precision to ensure the safe implementation of optimization strategies.

[0015] 2) This invention aims to improve the robustness and efficiency of masterless consensus in dynamic network environments. Addressing the shortcomings of existing technologies in addressing node performance variations, network latency fluctuations, and Byzantine behavior, it proposes an innovative priority-driven optimization system. In a masterless consensus system, multiple consensus instances run asynchronously, but slow instances (e.g., due to poor master node performance or malicious behavior) can still hinder overall performance through cross-instance synchronization. For example, when a cross-instance transaction must wait for blocks from multiple instances to reach consensus, the delay of the slowest instance can block the execution of all associated instances. This invention's priority mechanism overcomes this bottleneck through the following methods: Master rotation optimization: Highly stable master nodes are elected based on robustness priority, reducing view switching caused by master node failures (e.g., silent failures, error message attacks), and lowering fault recovery overhead; Synchronization optimization: The execution order of bound instances is predefined based on performance priority, allowing high-priority instances to execute directly after reaching consensus, without waiting for slow instances to commit.

[0016] 3) The priority calculation and reconfiguration process in this invention is strictly deterministic: Robust priority calculation: The instance's block sequence is segmented by view, and a penalty is calculated based on segment length, view switching cost, and terminal compensation. The final ranking sequence is generated by the aggregated penalty values ​​of the nodes. This process relies on historical on-chain data, and all nodes executing the same algorithm must obtain consistent results. Performance priority calculation: Local priorities are generated on a single node based on instance submission time, and then aggregated across nodes to generate a global ranking sequence. Both sorting rules (e.g., linear distribution) and aggregation operations (e.g., summation) are deterministic. Anchor block consensus: Initiated by the master instance, a Byzantine consensus (requiring 2f+1 votes) is performed on a series of height vectors to ensure the consistency of the underlying data for priority calculation.

[0017] 4) Determinism, as used in this article, refers to the property of an algorithm that, for a given input, it always produces the same output, and each step of its execution is predictable. This property makes deterministic algorithms particularly well-suited for distributed systems, as it ensures that even when executed independently on different nodes in the system, the results of each execution are identical, thereby enabling cross-node consistency verification and data synchronization. In the context of distributed systems and consensus mechanisms, algorithmic determinism ensures that all participating nodes, when receiving the same input information (for example, the same set of transaction data), will process this data according to the same logic and reach consistent conclusions. This consistency is a key element in achieving data consistency, preventing double spending, and maintaining overall system stability in distributed systems.

[0018] 5) The masterless consensus method and system constructed by this invention can significantly improve consensus efficiency and robustness in dynamic network environments (such as those subject to node performance variations, cross-regional network latency, or the presence of Byzantine nodes). In cross-border financial settlement scenarios, robustness priorities are used to dynamically select highly stable master nodes, reducing transaction interruptions caused by network partitions or malicious behavior. In supply chain collaborative traceability scenarios, performance priorities are used to optimize the data synchronization sequence across enterprise nodes, preventing high-performance nodes from being blocked by low-speed nodes and accelerating full-link transaction processing. Furthermore, in high-frequency trading platforms, a priority reconfiguration mechanism can adaptively adjust consensus strategies to ensure low-latency responses.

[0019] 6) Isolate the impact of slow instances through a dual-priority mechanism: Robustness priority identifies highly trusted nodes based on historical view change data and preferentially elects them as master nodes, significantly reducing the frequent view switching overhead caused by malicious nodes; Performance priority dynamically sorts cross-instance transactions based on the historical instance submission speed, allowing high-speed instances to execute in advance and reducing synchronization wait time. Experimental verification shows that under network fluctuations and uneven node performance, this invention significantly improves throughput compared to traditional solutions and significantly reduces the long-tail effect of latency distribution. This improvement stems from the priority mechanism's ability to dynamically shield slow instances and the secure reconfiguration process supported by anchor blocks, achieving adaptive optimization of system resources while ensuring consistency. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A schematic diagram of the system structure of the present invention; Figure 2 Update the flow chart for the priority of the present invention; Figure 3 This is an example diagram of the RCC processing flow in the prior art. DETAILED DESCRIPTION

[0021] This paper proposes a Byzantine fault-tolerant, masterless consensus method for asynchronous multi-instance operation. The masterless consensus protocol used allows instances to run asynchronously, thereby isolating the impact of slow consensus instances on overall system performance. This method includes: 1) utilizing deterministic state partitioning and state proposal authority management to resolve state conflicts between multiple instances, allowing each instance to independently reach consensus and execute on its corresponding intra-domain blocks while ensuring consistency; 2) introducing a synchronous processing flow for transactions whose states span multiple state subsets. This includes synchronous blocks and cross-domain block processing, enabling the system to find a snapshot of inter-instance consistency in an asynchronous instance environment, thereby achieving consistent submission of cross-domain transactions.

[0022] The invention is further described in detail with reference to the following specific examples and accompanying drawings. The processes, conditions, experimental methods, etc. for implementing the present invention, except for those specifically mentioned below, are common knowledge and common common sense in the art and are not particularly limited by the present invention. Example

[0023] See Figure 1 A priority-driven, Byzantine-fault-tolerant, masterless consensus system consists of a consensus protocol module, an execution module, a storage module, a permission management module, a lock module, a priority management module, an anchor processing module, and a network communication module, implementing state partitioning, consensus execution, synchronization processes, and priority reconfiguration mechanisms. The consensus protocol supports priority updates when multiple parallel consensus instances are running in parallel, and uses priorities to optimize instance operation processes. The leader (proposer) of each instance is responsible for proposing transactions (in the form of blocks) assigned to its instance. In each consensus round, each instance generates and agrees on a block, and these blocks are deterministically executed and submitted between nodes.

[0024] See Figure 1a. Under the overall process of asynchronous multi-instance operation, the system first uses a state partitioning algorithm to divide the global state into multiple non-overlapping subsets, each managed independently by a different consensus instance. The figure illustrates four consensus instances, each led by master nodes L1 through L4 responsible for proposing its own block. Each instance independently performs Byzantine fault-tolerant consensus based on its own operating state and master node efficiency, forming its own consensus block. User-submitted transactions are assigned to the corresponding instance based on the state subset involved, achieving consensus and execution without cross-instance coordination, significantly improving the system's overall concurrent processing capabilities. Notably, the system allows each instance to advance consensus completely asynchronously, allowing fast instances to independently complete transaction consensus and submission without being affected by slower instances. As shown in the figure, instances 1, 2, and 3 have each completed block generation and consensus without waiting for each other. Furthermore, when transactions involving multiple state subsets require cross-instance coordination, the system uses specialized "synchronization blocks" to coordinate state consistency across instances. Example 4 in the figure proposes a synchronization block, which ensures consistency in the state snapshots among multiple instances through joint consensus, thus ensuring the correct execution of cross-domain transactions.

[0025] See Figure 1 b. Depending on the transaction type contained in the block, different block processing workflows are initiated, including "asynchronous" and "synchronous" workflows. From a node's perspective, blocks consisting of transactions within a single state set are called intra-domain blocks. Once submitted by consensus, they enter the "asynchronous" workflow, where they are directly executed and subsequently update the state database and lock module. After updating the local state, the instance leader initiates a new round of consensus based on the new state set snapshot, independently of the completion status of other instances, and proposes a new intra-domain block. When an instance's master node intends to propose a block containing transactions across multiple state subsets, known as a cross-domain block, it initiates the "synchronous" workflow by proposing a specially designed "sync" block. This block is designed to establish a consistent state snapshot across instances in a multi-instance asynchronous environment. Once consensus is reached, this operation locks subsequent blocks in the corresponding state of the involved instances. This, in turn, influences node voting in subsequent consensus processes, preventing further changes to the state of these domains, thereby ensuring consistency. Finally, based on the submitted block information, the node updates the priority and optimizes the subsequent submission process.

[0026] See Figure 2The priority calculation and update process mainly includes priority calculation and round-based priority update: the figure shows four consensus instances (Instance 1 to Instance 4) in vertical columns, and the operation type of each instance in round X and round X+1 is marked by color blocks: Instance 1 alternately executes anchor block "A" and regular block "B¹", Instance 2 continuously processes "B²" transaction flow, Instance 3 promotes "B³" chain growth, and Instance 4 submits "B" after initiating the synchronization block "Sync". 4 The top set {h1, h2, h3, h4} records the global height status in real time, the "consensus submission block" at the bottom triggers round switching, and the "update priority" module on the right implements closed-loop optimization. During round X, each instance performs asynchronous operations in parallel: asynchronously submitting its consensus block. This asynchronous concurrency mode continues until the end of the round. When all instances have completed a certain number of block submissions (marked at the bottom), the system automatically triggers the key stage of anchor consensus - the master instance updates the height vector {h1, h2, h3, Byzantine agreement is initiated, and after confirmation by 2f+1 nodes, a consistency snapshot is formed. Dynamic priority updates (right-hand module) are then initiated. Based on historical data such as view switching information encapsulated in the anchor block and block synchronization data, robustness priorities (to suppress malicious master nodes) and performance priorities (to optimize cross-domain transaction ordering) are recalculated in real time. The new priorities are immediately applied to the optimization run in round X+1: high-performance instances are preferentially selected as master nodes (e.g., accelerating the extension of the "B²" chain in instance 2). The dotted arrows in the figure indicate the logic of "consensus submission → height vector consensus → priority update → new round optimization."

[0027] This invention primarily targets decentralized consortium blockchain scenarios. These permissioned blockchains, which have entry barriers, urgently need to improve consensus efficiency in dynamic environments while maintaining decentralization, tamper-proofing, and traceability. Through a priority-driven mechanism—including robustness prioritization for selecting highly stable nodes, performance prioritization for optimizing resource allocation, and dynamic reconfiguration triggered by anchor rounds—the invention significantly enhances the system's adaptability to node performance variations, network fluctuations, or malicious attacks. This technology is particularly applicable to three key scenarios: In the financial sector (such as cross-border clearing and securities trading), robustness prioritization ensures the stability of master nodes in critical transaction channels, while performance prioritization ensures the independent execution of high-frequency settlements without interference from slower nodes. In cross-enterprise supply chain collaboration, performance prioritization isolates bottlenecks in IoT data collection and financial settlement processes, enabling parallel progress in logistics traceability and fund clearing. In particular, in multinational cross-border payment systems, dual priorities collaborate to mitigate geographic latency differences: high-performance nodes in Asia asynchronously process local payments through performance prioritization, while robustness prioritization automatically blocks frequently faulty nodes from participating in global channel consensus.

[0028] Taking the cross-border payment alliance chain as an example, when there is a three-fold performance difference between the London node and the Sydney node, the traditional solution is limited to the slowest node due to the global synchronization mechanism, resulting in a sharp drop in throughput. The present invention achieves dual optimization through a priority isolation mechanism: the performance priority allows European nodes to independently complete euro clearing transactions to avoid waiting for Australian nodes; the robustness priority automatically downgrades frequently faulty nodes in the anchor round. This dynamic tuning mechanism keeps the system throughput running at a high level, and significantly compresses the long-tail effect of the cross-border transaction delay distribution. Actual deployment shows that under the same network fluctuation conditions, compared with solutions such as RCC that require global sorting, the present invention maintains Byzantine security while more than doubling the response efficiency of the alliance chain in complex business scenarios.

[0029] The present invention is further described in detail below using a system with four nodes as an example: See Figure 3 Conventional RCC uses rounds to advance consensus. In each round, users send transactions to each node. Each node corresponds to a different instance, resulting in a total of four instances. The master node packages the transactions and initiates a consensus proposal, which then enters the consensus voting node. The specific voting process is similar to PBFT (Practical Byzantine Fault Tolerance Consensus Protocol). In each round, after all instances complete the consensus vote, all nodes sort the blocks generated by each instance and execute them to ensure consistency. However, this also makes the slowest instance the bottleneck of the system. If one instance fails to reach consensus, all instances will be forced to wait for it.

[0030] From the above description of the embodiments, it can be seen that those skilled in the art can clearly understand that the present invention can be implemented by means of software plus the necessary general-purpose hardware platform. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments of this application or certain portions of the embodiments.

[0031] Each of the aforementioned embodiments is described in a progressive manner. Similar portions between the various embodiments can be referenced. Each embodiment focuses on the differences between the other embodiments. In particular, the client and server embodiments can be referenced and explained in conjunction with the description of the aforementioned method embodiments.

[0032] The present invention can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. They can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices. In addition to implementing the client and server in pure computer-readable program code, it is entirely possible to implement the same functionality of the client and server in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers through logical programming using the methods of the present invention. Therefore, such clients and servers can be considered to be hardware components, and the devices used to implement various functions can also be considered to be structures within the hardware components. Alternatively, the devices used to implement various functions can even be considered to be both software modules that implement the method and structures within the hardware components.

[0033] The protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the appended claims.

Claims

1. A priority-driven Byzantine fault-tolerant masterless consensus optimization method, characterized in that: In the multi-instance asynchronous consensus framework, a method of introducing a node and instance priority calculation mechanism is used to optimize the Byzantine fault-tolerant masterless consensus process. The method specifically includes the following steps: Step 1: Build a blockchain cluster, configure the identity information of each node in the network, and start nodes that support multi-instance asynchronous consensus; Step 2: Each node uses deterministic rules to elect the initial master node, uses the state partitioning algorithm to divide the global state into multiple subsets, and builds a multi-consensus instance structure based on this; Step 3: Based on the robustness priority mechanism, the best node is selected as the master node in each round to initiate instance proposals, and the Byzantine fault-tolerant protocol is used to execute the process within the instance; Step 4: Each node conducts multiple rounds of voting according to the consensus protocol to reach a consensus on the block, and then enters the subsequent execution process; Step 5: Differentiated processes are implemented for different types of consensus blocks. Intra-domain blocks are directly executed, while cross-domain blocks enter the synchronization process. The block sorting and execution order are optimized through the priority mechanism. Step 6: The node completes the receipt of the executed block and persists it, while recording the priority of this round and performing consistency reconfiguration to support the next round of process optimization.

2. The priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1 is characterized in that: The cluster in step 1 is a collection of different server nodes in the inter-node network, containing a total of N nodes, of which at most f nodes are Byzantine nodes and satisfy the relationship N ≥ 3f + 1. The public key infrastructure (PKI) is used to authenticate the identities of the nodes, and the nodes communicate with each other through authenticated channels. Each node contains a unique public-private key pair and IP address. The inter-node network is assumed to be partially synchronized, and an upper bound on the delay allowed for message transmission in the inter-node network is allowed.

3. The priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1 is characterized in that: The global state division in step 2 specifically includes the following steps: Step 2-1: Use a deterministic partitioning algorithm P(s) to partition all possible system states into non-overlapping subsets, generating multiple non-overlapping state subsets Si; Step 2-2: Divide transactions into intra-domain transactions tIS and cross-domain transactions tCS based on the state subsets they access. Intra-domain transactions tIS only involve a single state subset, while cross-domain transactions tCS involve states in multiple state subsets. Step 2-3: Each state subset after division corresponds one-to-one to a parallel consensus instance. The master node in each consensus instance has the right to propose transactions related to this state.

4. The priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1 is characterized in that: The robustness priority mechanism in step 3 specifically includes the following steps: Step 3-1: Each node maintains a local view history information table, which records the view number and corresponding master node ID of the blocks submitted in the current round in this instance, and is used to identify the block segments led by different master nodes; Step 3-2: Based on the view changes in the block sequence, blocks generated consecutively by the same master node with the same view number are divided into a view segment. Each consensus round contains multiple view segments and represents the master node switching during the consensus process. Step 3-3: Calculate the penalty value for each view segment according to the rules set for each view segment. The penalty value consists of the initial penalty caused by view switching, the protocol overhead caused by frequent switching of the master node, and the additional reward value given when the view segment is the last segment to encourage the final successful submission. Step 3-4: Sum up the penalty values ​​of all view segments dominated by a master node in the current round to obtain the total robustness penalty value of the master node in the current instance; Step 3-5: Sort all nodes according to their total robustness penalty value to generate a priority sequence. The node with the smaller penalty value has a higher priority. Steps 3-6: All nodes obtain the unified priority ranking results under the current consensus round based on the anchor snapshot or other consensus synchronization methods, and select the node with the highest priority as the master node, which initiates the consensus proposal and continues the subsequent consensus process.

5. The priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1 is characterized in that: The step 5 specifically includes the following steps: Step 5-1: During each round of cross-instance synchronization, the synchronization process is divided into the binding phase, the synchronization consensus phase, and the unbinding phase. In the synchronization consensus phase, each instance must wait for all bound instances to complete local consensus before sorting and joint execution can proceed. Step 5-2: During the synchronization phase, each node locally records the timestamp of each consensus instance completing block submission, and uses this timestamp to sort the multiple consensus instances participating in this round of synchronization; Step 5-3: The local sorting result indicates the order in which the node processes each instance. Each instance is assigned a linearly distributed priority value, which ranges from positive to negative, reflecting the speed of submission. Step 5-4: Aggregate the local priorities across all nodes participating in the synchronization process and calculate a global performance priority value for each instance, reflecting the submission speed of the instance from a collective perspective. Step 5-5: For each round of synchronization, all participating instances are sorted according to global performance priority, and an execution sequence is generated within the synchronization process so that instances with higher priorities are completed first in the joint execution without waiting for other slower instances; Steps 5-6: If multiple synchronization processes are performed concurrently at multiple times, the global performance priority values ​​of each instance in each round of synchronization are accumulated to eventually generate a global performance priority sequence. This sequence is referenced in subsequent synchronizations to determine the execution order between instances, thereby improving overall concurrent execution efficiency and system throughput.

6. The priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1 is characterized in that: The step 6 specifically includes the following steps: Step 6-1: Periodically enter the priority reconfiguration phase according to a preset time or number of block rounds, with the reconfiguration taking rounds as the basic unit; Step 6-2: Set a consensus instance as the master instance, which is responsible for initiating the priority reconfiguration process in each round; Step 6-3: The master instance initiates the reconfiguration process by constructing an anchor block. The anchor block contains the current block height vector of each consensus instance, which is used to uniformly record the state snapshot. Step 6-4: All nodes participate in the consensus process of the anchor block. The submission of the anchor block is regarded as the trigger point of a round switch, indicating that the current priority view will enter the update phase; Step 6-5: After the anchor block is submitted, all nodes recalculate the robustness priority and performance priority based on the running status and submission records of the previous round of consensus instance, and use the updated results as the basis for leader selection and sorting in the next round of consensus process and synchronization process; Step 6-6: Priority updates are performed based on the success of the anchor block consensus to ensure that all correct nodes reach a consistent priority view within the same round, thereby avoiding consensus process disagreements or disordered execution order caused by inconsistent priorities. Steps 6-7: Configure the master instance settings, anchor trigger frequency, and priority update parameters to achieve a dynamic trade-off between stability and performance.

7. A Byzantine fault-tolerant masterless consensus optimization system constructed by the priority-driven Byzantine fault-tolerant masterless consensus optimization method according to claim 1, characterized in that: The system consists of a consensus protocol module, an execution module, a storage module, a permission management module, a lock module, a priority management module, an anchor processing module, and a network communication module, which implement state partitioning, consensus execution, synchronization process, and priority reconfiguration. The consensus protocol module executes a deterministic state partitioning algorithm and consensus proposals and consensus process execution by the master node in each consensus instance. The state partitioning algorithm divides the system state into multiple non-overlapping state subsets and divides transactions into intra-domain transactions and cross-domain transactions. The execution module executes transactions in the block according to priority sorting and synchronization control results, and updates the system state, supporting multi-instance concurrent execution and cross-instance synchronous execution. The storage module stores blockchain ledger data, state snapshots, anchor block information, and transaction execution records, providing data persistence support for the system; The rights management module is based on the public key infrastructure system to realize the identity authentication, rights allocation and access control of nodes in the blockchain cluster; The lock module is used to manage access locks for a subset of system states, ensuring state consistency during concurrent execution of multiple instances and cross-domain transaction processing; The priority management module calculates robustness priority and performance priority based on historical views and submission time in each round of consensus, and supports node sorting and decision-making in the master change process and synchronization process; The anchor processing module is initiated by the master instance and reaches consensus on the anchor block, unifies the system rounds and triggers priority reconfiguration to ensure that all nodes maintain a consistent priority view; the network communication module transmits consensus messages, transaction information, anchor blocks and status snapshots between nodes, and supports communication under synchronous network conditions.

Images