A method and system for dynamic asynchronous byzantine consensus without blocking reconfiguration

Abstract

This invention provides a non-blocking reconfiguration dynamic asynchronous Byzantine consensus method and system. It employs a layered collaborative architecture of consensus execution layer and reconfiguration control layer. The execution layer continuously processes transaction ordering and submission, while the control layer concurrently promotes member changes and key refreshes. Atomic configuration switching is achieved through atomic vector splitting, and cross-configuration in-transit transaction takeover is completed using a streaming remapping mechanism. Erasure coding data distribution technology ensures data availability. This invention achieves non-blocking operation during reconfiguration, increases throughput by 1.75 times, and optimizes communication overhead to O(n^2). 2 The system reduces transaction confirmation latency by over 40%, combining high throughput, low latency, and strong security to effectively mitigate the risk of data loss due to consensus node exits. A data distribution mechanism mandates that consensus nodes distribute and store pending data using erasure coding before leaving, ensuring that critical data remains fully recoverable even if some consensus nodes fail or are maliciously scheduled.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a non-blocking reconfigurable dynamic asynchronous Byzantine consensus method and system. Background Technology

[0002] Blockchain technology, as a decentralized distributed ledger technology, has been widely applied in finance, supply chain, and the Internet of Things. The consensus protocol is its core mechanism, responsible for achieving data consistency among mutually distrustful consensus nodes. During the long-term operation of a blockchain, it is necessary to support consensus nodes joining or leaving the network due to maintenance, failure, or rotation, and to periodically refresh threshold keys to defend against mobile corruption attacks.

[0003] To address the dependence of traditional dynamic partial synchronization protocols (such as PBFT and HotStuff) on network timing, asynchronous Byzantine fault-tolerant protocols have emerged. These protocols do not rely on network timing assumptions and exhibit greater robustness under network fluctuations or malicious scheduling. In particular, pipelined asynchronous consensus protocols, by decoupling transaction propagation and consensus ordering, achieve high throughput and low latency, meeting the needs of real-world applications.

[0004] However, existing asynchronous Byzantine fault-tolerant consensus protocols have obvious engineering flaws: reconfiguration requires pausing or significantly slowing down to complete the establishment of a new committee and key updates, resulting in drastic fluctuations in throughput and confirmation latency; without shutdown, transactions in transit across configuration boundaries lack verifiable inheritance, which can easily lead to loss, duplicate propagation, or long-term unconfirmation issues; existing dynamic asynchronous consensus protocols mostly adopt a stop-restart reconfiguration strategy, which blocks the consensus transaction flow and cannot meet the continuity requirements of high-frequency transactions.

[0005] Therefore, there is an urgent need for a dynamic asynchronous Byzantine consensus scheme that balances high throughput, low latency, strong resistance to attacks, and operational continuity. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a non-blocking reconfiguration dynamic asynchronous Byzantine consensus method and system. This invention enables uninterrupted operation during reconfiguration, while maintaining high throughput, low latency, and strong security, and solves problems such as performance fluctuations, transaction loss, and excessive communication overhead during consensus node changes and key refresh processes.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a dynamic asynchronous Byzantine consensus method with non-blocking reconfiguration, comprising the following steps: S1) Construct a layered collaborative architecture of consensus execution layer - reconfiguration control layer. The consensus execution layer is responsible for the propagation, batch processing, sorting and submission of transactions. The reconfiguration control layer is responsible for the parallel advancement of member changes and threshold key refresh. The consensus execution layer - reconfiguration control layer synchronizes control transactions and certificate status in the ledger. S2) The consensus execution layer receives client transactions, performs deduplication and legality checks, aggregates them into batches, propagates batch data through asynchronous reliable broadcast, generates total order blocks in parallel sorting based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations to the outside world. S3) Reconfigure the control layer monitors the ledger Epoch height. When the preset reconfiguration threshold is reached, the optimistic distributed key refresh protocol is initiated to generate a new configuration threshold key pair through a two-path strategy. ) and configuration ready certificate ; S4) When the consensus node parses the ledger and finds the configuration-ready certificate... When a control transaction occurs, an atomic handover process is triggered. S5) Trigger the data distribution process, leave the data of the departing consensus node to the new committee, encode the high-risk transaction data that has not been submitted with erasure coding and broadcast it to the new committee. After verifying the integrity of the shards, the new committee consensus node reconstructs the data as needed and injects it into the transaction pool. S6) Load the new threshold key pair to update the verification predicate, restore transaction sorting and block production under the new configuration, and complete the non-blocking reconfiguration.

[0008] Preferably, in step S3), the optimistic distributed key refresh generates a new configuration threshold key pair through a dual-path strategy. ) and configuration ready certificate Specifically: Each consensus node in the old committee acts as a dealer, randomly sampling a secret value locally. Based on secret value Build a Threshold polynomial; and using verifiable secret sharing to generate the corresponding polynomial commitment and private key fragment encryption sent to the new committee; After receiving the secret shards and commitments from the old committee consensus nodes, the new committee consensus nodes initiate a multi-valued Byzantine consensus instance to reach a consensus on the sharing of valid old nodes and output the set of valid dealers. ; The new committee consensus node verifies private key shards and the set of valid dealers. If the global commitment to consistency is verified and there are no conflicts, the system proceeds to the optimistic path; if the verification fails, the system proceeds to the pessimistic recovery path. In the optimistic path, the new committee consensus nodes locally aggregate the set of valid dealers. The dealer's commitment is to compute the global threshold public key and use the sum of the fragments as the new private key share, with a communication complexity of O(n). ; In the pessimistic path, the new committee consensus nodes broadcast error reports, triggering a batch recovery mechanism that aggregates missing shares, and the communication complexity reverts to [previous scenario]. ; Once the new committee consensus nodes successfully calculate the new private key share and global public key, they sign the new configuration parameters. After collecting a threshold number of signatures, they are aggregated into the final configuration-ready certificate. .

[0009] Preferably, step S4) specifically includes the following steps: The consensus node parses the latest block submitted by the main chain and checks whether it contains the handover instructions corresponding to the configured ready certificate Σ; Calculate the atomic cleavage vector based on the block index where the handover instruction is located. And based on atomic cutting vectors Define configuration boundaries; for indices smaller than atomic cut vectors The transaction flow indicated by the height was verified by the old committee, and the index is greater than the atomic cut vector. The high-trading volume indicated by the new committee has been taken over. Determine the atomic cutting vector Then, freeze write permissions for the old configuration and refuse to accept any requests exceeding the limits. And the new broadcast slot is signed using the old key; Consensus nodes trigger a streaming handover process based on their own identities. Remaining consensus nodes execute a streaming remapping mechanism to take over transactions in transit. At the same time, they initiate a data distribution process, encoding unsubmitted transactions into fragments and broadcasting them to the new committee. Install new configuration on consensus node And load the new threshold key pair Update the verification predicate and take over the sorting and block production of the transaction stream based on the new configuration.

[0010] Preferably, the streaming remapping mechanism in step S4) specifically includes: Remaining consensus nodes scan locally cached in-transit transaction flows and identify those with index numbers greater than the atomic slicing vector. The high-order sequence of non-consensus transactions indicates the in-transit transactions; For each transaction in transit, the remaining consensus nodes extract its metadata and use the newly configured private key. Digitally sign the metadata to generate a new configuration. The remapping credential that has been verified; The remaining consensus nodes will broadcast a message containing the remapped credentials to the new committee; The new committee members receive and verify the validity of the remapping message. Once the new committee verifies the message, it maps the corresponding old transaction load in the local cache to the newly configured queue for processing.

[0011] Preferably, step S5) specifically includes: After atomic cross-contamination, the identification index number is greater than Transactions that have not yet been fully distributed are classified as high-risk transaction data and are locked locally. Outgoing consensus nodes adopt The threshold data redundancy coding mechanism encodes locked transaction data into multiple fragments containing redundant information, which are then broadcast in parallel to all members of the new committee. The new committee consensus node receives shards from the old committee consensus node and verifies the integrity of the shards based on the Merkle tree of the transactions, filtering out invalid or malicious shards. The new committee consensus nodes check whether they hold transactions. If they do, they inject the data into the transaction pool; if not, they request additional shards from their peers, pending collection. Each shard of data is reconstructed and injected into the transaction pool.

[0012] Secondly, the present invention provides a non-blocking reconfigurable dynamic asynchronous Byzantine consensus system, comprising: The execution layer module is used to perform transaction submission, batch processing, reliable propagation, consensus sorting, and ledger update. After receiving client transactions, it performs deduplication and legality checks, aggregates them into batches, propagates batch data through asynchronous reliable broadcast, generates total order blocks in parallel sorting based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations to the outside world. The control layer module monitors the ledger epoch height. When a preset reconfiguration threshold is reached, it initiates an optimistic distributed key refresh protocol to generate a new configuration threshold key pair using a two-path strategy. ) and configuration ready certificate ; The atomic handover module, when the ledger detects a configuration-ready certificate... When the corresponding control transaction occurs, the atomic handover process is triggered; The data distribution module is used to perform erasure coding, fragmented broadcasting, and integrity verification on unsubmitted transaction data. The key management module is used to store, distribute, and update threshold key pairs.

[0013] Preferably, the execution layer module adopts a parallel pipeline structure that decouples propagation and sorting to ensure that transaction sorting continues in an asynchronous network environment without being paused by control layer activities.

[0014] Preferably, the atomic handover module triggers a streaming handover process, allowing the consensus node to execute a streaming remapping mechanism to take over transactions in transit, and achieves cross-configuration transaction takeover through transaction metadata signature authentication.

[0015] Preferably, the data distribution module restores data on demand, and when a new committee consensus node is missing data, it can request additional fragments from other consensus nodes.

[0016] Preferably, the system is deployed on a distributed node cluster, with nodes distributed in a wide area network environment, supporting dynamic expansion of 16-64 nodes, with each node equipped with at least 4 vCPUs and 8GB of memory, and using the BLS12-381 elliptic curve cryptography algorithm.

[0017] The beneficial effects of this invention are as follows: 1. This invention improves throughput by up to 1.75 times in reconfiguration scenarios. By decoupling the execution layer and control layer and using atomic split vectors to achieve seamless configuration switching, it completely eliminates the performance drop caused by stopping and restarting in traditional solutions, ensuring that the system can still maintain peak transaction processing capacity during member changes. 2. This invention reduces the communication complexity of key refresh from the traditional Optimized to the optimistic scenario By introducing an optimistic distributed key refresh mechanism and combining it with a verifiable ciphertext commitment mechanism, the system significantly reduces the bandwidth consumption of the backend management tasks on the main network, thereby significantly improving the overall operating efficiency of the system. 3. This invention effectively mitigates the risk of data loss due to consensus node exits. Through a cross-configuration data distribution mechanism, it mandates that consensus nodes distribute and store pending data via erasure coding before leaving, thus filling the liveness vulnerability in dynamic network environments and ensuring that critical data remains fully recoverable even when some consensus nodes fail or are maliciously scheduled. 4. The transaction confirmation latency of this invention is reduced by more than 40% compared to the baseline. By utilizing the streaming remapping mechanism, cross-configuration transaction takeover can be completed simply by digitally signing the metadata, avoiding network congestion caused by retransmitting the entire data and significantly reducing the additional latency caused by configuration switching. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the method in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the consensus execution layer in Embodiment 1 of the present invention; Figure 3 This is a flowchart illustrating the reconfiguration of the control layer in Embodiment 1 of the present invention; Figure 4This is a schematic diagram of the atomic transfer process in Embodiment 1 of the present invention; Figure 5 This is a flowchart illustrating the streaming remapping mechanism in Embodiment 1 of the present invention; Figure 6 This is a flowchart illustrating the data distribution process in Embodiment 1 of the present invention; Figure 7 This is a schematic diagram showing the test results of Embodiment 1 of the present invention at a scale of 64 nodes; Figure 8 This is a schematic diagram illustrating the test results of the reconfiguration frequency on the system performance stability in Embodiment 1 of the present invention; Figure 9 This is a schematic diagram showing the latency test results of the data distribution mechanism in Embodiment 1 of the present invention under a high load scenario. Detailed Implementation

[0019] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings: Example 1 like Figure 1 As shown, this embodiment provides a non-blocking reconfiguration dynamic asynchronous Byzantine consensus method, including the following steps: S1) Construct a layered collaborative architecture of consensus execution layer and reconfiguration control layer; In this embodiment, the consensus execution layer process is mainly maintained by the execution layer nodes and consensus nodes, which are responsible for the propagation, batch processing, sorting and submission of transactions to ensure the continuous operation of the main business flow. In this embodiment, the reconfiguration control layer process is executed independently in the background by the consensus node, which is responsible for the parallel advancement of member changes and threshold key refresh without blocking the consensus execution layer process; In this embodiment, the consensus execution layer process and the reconfiguration control layer process are connected through control transactions in the ledger (i.e., configuration ready certificates). (On-chain) to achieve state synchronization and atomic switching.

[0020] S2) The consensus execution layer receives client transactions, performs deduplication and legality checks, aggregates them into batches, propagates the batch data through asynchronous reliable broadcast, generates total order blocks in parallel based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations. Subsequently, consensus nodes generate total order blocks in parallel based on a pipeline mechanism. Finally, execution layer nodes update the ledger status based on the total order blocks and output transaction confirmations. In this embodiment, the consensus execution layer runs continuously under any valid configuration, completing transaction reception, batch processing, reliable propagation, parallel sorting, and block submission, and is not paused due to reconfiguration of the control layer activities. It adopts a parallel pipeline structure that decouples propagation and sorting, ensuring that sorting and submission can continue even with arbitrary network latency. Figure 2 As shown, it specifically includes: Transaction submission: The execution layer node receives transaction data sent by the client, which has been constructed and digitally signed by the client; Transaction collection and batch processing: The execution layer node stores the received transactions into the local transaction pool, performs deduplication and validity checks, and packages the valid pending transactions into batches; Reliable data propagation: Initiate an asynchronous reliable broadcast instance to distribute batch data across the entire network, and generate proof after achieving data availability; Consensus ordering and block generation: Consensus nodes run the multi-valued Byzantine consensus protocol to perform total ordering of the batch indices submitted by the execution layer nodes and generate global block proposals including transaction metadata; Ledger state update: Based on the index sequence determined by consensus, the execution layer nodes reconstruct the complete transaction data from the local cache or execution layer peer nodes, execute the transaction logic in sequence and update the blockchain ledger state. Once the transaction state update is completed, it is considered as final confirmation and written to the irreversible ledger. Then, the transactions that have been put on the chain are cleaned up from the transaction pool and returned to the loop for processing.

[0021] S3) Reconfigure the control layer monitors the ledger Epoch height. When the preset reconfiguration threshold is reached, the optimistic distributed key refresh protocol is initiated to generate a new configuration threshold key pair through a two-path strategy. ) and configuration ready certificate ; In this embodiment, the reconfiguration control layer employs an optimistic distributed key refresh protocol to complete the threshold key pairing for the next committee members without blocking the main consensus pipeline. The generation and distribution of (e.g.) Figure 3 As shown, the details are as follows: Monitoring Ledger Epoch Height: Consensus nodes read the local ledger status in real time during operation to obtain the current consensus cycle height value; Reconfiguration verification: The current Epoch height is compared with the preset reconfiguration threshold to verify whether the conditions for triggering member rotation or key refresh have been met. If the reconfiguration verification result is negative, the current committee configuration remains unchanged, and ordinary transactions submitted by users continue to be processed in the main consensus pipeline. If the reconfiguration verification result is positive, the background reconfiguration mechanism is triggered, and the optimistic distributed key refresh protocol is started in parallel without pausing the main consensus thread.

[0022] Optimistic Distributed Key Refresh: After successful verification, the protocol is initiated. Each consensus node in the old committee acts as a dealer, randomly sampling a secret value locally. Based on secret value Build a Threshold polynomial; and using verifiable secret sharing to generate the corresponding polynomial commitment and private key fragment encryption sent to the new committee; Confirmation of the valid dealer set: After receiving the secret shards and commitments from the old committee consensus nodes, the new committee consensus nodes initiate a multi-valued Byzantine consensus instance, reach a consensus on the sharing of valid old committee consensus nodes, and output the valid dealer set. ; Key Generation and Certificate Broadcasting: New Committee Consensus Nodes Verify Private Key Sharding and Valid Dealer Set If the global commitment to consistency is verified and there are no conflicts, the system proceeds to the optimistic path; if the verification fails, the system proceeds to the pessimistic recovery path. In the optimistic path, the new committee consensus nodes locally aggregate the set of valid dealers. The dealer's commitment is to compute the global threshold public key and use the sum of the shards as the new private key share; this process requires no interactive reconstruction, and the communication complexity is O(n log n). ; In the pessimistic path, the new committee consensus nodes broadcast error reports, triggering a batch recovery mechanism to aggregate requests for missing shares; nodes reconstruct valid private key shares without exposing the original secret, and the communication complexity regresses to [previous scenario].

[0023] Once the new committee consensus nodes successfully calculate the new private key share and global public key, they sign the new configuration parameters. After collecting a threshold number of signatures, they are aggregated into the final configuration-ready certificate. .

[0024] S4) When the ledger detects a configured ready certificate When the corresponding control transaction occurs, the atomic handover process is triggered; In this embodiment, after the key refresh protocol successfully generates a configuration-ready certificate, the certificate is encapsulated into a special management transaction and submitted to the main chain consensus for sorting. Once the atomic handover process transaction is packaged into a block and submitted, it signifies the issuance of the configuration switch instruction. When the consensus execution layer detects the configuration-ready certificate... When the corresponding control transaction occurs, an atomic handover process is triggered; such as Figure 4 As shown, it specifically includes: Consensus nodes parse the latest submitted block on the main chain and check if it contains a certificate ready for encapsulation configuration. The handover instructions are required; if not included, the consensus node maintains its current configuration. And continue the normal consensus loop; if a handover instruction is included, then the atomic handover logic is triggered; Consensus nodes deterministically compute atomic slicing vectors based on block indexes containing handover instructions. The atomic cutting vector Define globally consistent configuration boundaries: index less than The transaction flow was verified by the old committee, and the index is greater than... The transaction flow must be taken over by the new committee; Determine the atomic cutting vector Then, the consensus node immediately freezes the old configuration. Grant write permissions and refuse any requests exceeding them. Furthermore, the new broadcast slot is signed using the old key, thus preventing the old ledger from forking; After freezing the old configuration, the consensus node triggers a streaming handover process based on its own identity, which is responsible for remapping transactions in transit. At the same time, in order to further improve data security, the remaining consensus node can selectively trigger a data distribution process, which is responsible for leaving the data of the departing consensus node to the new committee.

[0025] In this embodiment, the streaming remapping mechanism utilizes the dual identity of the retained consensus node in both the previous and subsequent committees to transform high-bandwidth data transmission into low-overhead metadata authentication. This allows for cross-configuration inheritance of large-scale in-transit transactions within milliseconds, avoiding network storms. Figure 5 As shown, it specifically includes: After the atomic handover is initiated, the remaining consensus nodes immediately scan the locally cached transaction streams and identify all transactions with index numbers greater than [insert index number here]. Transactions in transit that are marked with a height but have not yet been sorted by consensus; For each transaction in transit, the remaining consensus nodes extract its metadata and use the newly configured private key. Digitally sign the metadata to generate a new configuration. The remapping credential that has been verified; The remaining consensus node will broadcast a message containing the remapped credentials to the new committee, which declares to the entire network that the old data is secure and valid and has been endorsed by the members of the old committee. The new committee members receive and verify the legitimacy of the remapping message. Once the verification is successful, the corresponding old transaction load in the local cache is directly mapped to the newly configured pending queue, thus completing the seamless switching of verification rules without interrupting the data flow.

[0026] S5) Trigger the data distribution process, leave the data of the departing consensus node to the new committee, encode the high-risk transaction data that has not been submitted with erasure coding and broadcast it to the new committee. After verifying the integrity of the shards, the new committee consensus node reconstructs the data as needed and injects it into the transaction pool. In this embodiment, the data distribution process is used to prevent data availability loss caused by the departure of a decommissioning node. In an asynchronous network environment, some transactions may only exist in the memory of the departing consensus node. To ensure system liveness, this embodiment designs a data redundancy coding distribution mechanism to ensure that high-risk data is transferred to the new committee before the consensus node leaves, such as... Figure 6 As shown, it specifically includes: After atomic cross-contamination, the identification index number is greater than Transactions marked with a high risk level and not yet fully distributed are considered high-risk transaction data and are locked locally. Outgoing consensus nodes adopt The threshold data redundancy coding mechanism encodes locked transaction data into multiple fragments containing redundant information and broadcasts these fragments in parallel to all members of the new committee to ensure the survival of the data in the network. The new committee consensus node receives shards from the old committee consensus node and verifies the integrity of the shards based on the Merkle tree of the transactions, filtering out invalid or malicious shards; only when a consensus node has collected enough shards will it confirm its exit on the main chain, otherwise the consensus node's staked assets will be forfeited. The new committee consensus nodes check whether they hold transactions. If they do, they inject the data into the transaction pool; if not, they request additional shards from their peers, pending collection. Each shard of data is reconstructed and injected into the transaction pool.

[0027] S6) Install new configuration And load the new threshold key pair The verification predicate is updated, and the ordering and block production of the transaction stream are restored under the new configuration, completing the non-blocking switch.

[0028] This embodiment performs the following tests in the following environment: Deployed on the Alibaba Cloud platform using the ecs.u1-c1m2.xlarge instance, this instance is used to deploy consensus nodes and execution layer nodes, with the nodes referred to below as consensus nodes. Each server is equipped with 4 vCPUs and 8GB of memory, running the Ubuntu Linux operating system. The nodes are located in a real wide area network environment, distributed across 9 different geographical locations globally, with each node's bandwidth limited to 100Mbps. The protocol code is implemented based on Python 3.8, using the gevent library to handle concurrent tasks, and elliptic curve cryptography operations are implemented based on BLS12-381 curves. The simulated transaction size is 250 bytes.

[0029] I. The method described in Embodiment 1 of this invention (a dynamic asynchronous Byzantine consensus method with non-blocking reconfiguration) was tested on a scale of 64 consensus nodes. The specific test settings are as follows: 1) Environment setup: Increase the number of network nodes from 16 to 64, deploy the non-blocking reconfigurable dynamic asynchronous Byzantine consensus method of this embodiment, and select the existing dynamic asynchronous consensus protocol Turritopsis and the static asynchronous consensus protocol sDumbo-Hybrid as the comparison benchmark.

[0030] 2) Load testing: At each node scale, continuously send transaction requests until the network is saturated, and record the system's average throughput (transactions per second) and average confirmation latency.

[0031] 3) Comparative analysis: Evaluate the performance loss of this embodiment compared to the static protocol and the performance improvement compared to the existing dynamic protocol after introducing the dynamic reconfiguration function.

[0032] The results are as follows Figure 7 As shown, in terms of throughput: at a scale of 64 nodes, the peak throughput of this embodiment (optimistic path) reaches 82kTPS, which is 1.75 times higher than Turritopsis (47kTPS) and 1.5 times higher than static sDumbo-Hybrid (55kTPS).

[0033] Regarding latency: with 16 nodes, the latency of this embodiment is about 1.3 seconds, which is 27% lower than Turritopsis; with 64 nodes, the latency of Embodiment 1 is maintained at 1.8 seconds, which is much lower than Turritopsis's 3.0 seconds, a reduction of more than 40%.

[0034] II. In this embodiment, the reconfiguration interval is adjusted. (i.e., the number of consensus rounds executed between two consecutive member changes) is used to simulate different reconfiguration frequencies and test their impact on system performance stability, as detailed below: 1) Parameter settings: The network size is fixed at 32 nodes. The set of values ​​is {10, 20, 50, 100, 150, 200}. A smaller value indicates more frequent reconfiguration.

[0035] 2) Stability testing: under different conditions... The system operates under a specific protocol, recording the average throughput and latency of the system to observe the impact of high-frequency reconfiguration on system stability.

[0036] 3) Comparative Verification: The dual-path mode of this embodiment is compared with Turritopsis, and the results are as follows: Figure 8 As shown.

[0037] Throughput robustness: When reconfiguration is extremely frequent (R=10), Turritopsis experiences a throughput drop to 21kTPS due to frequent blocking. This embodiment, however, maintains a high throughput of over 36kTPS thanks to its non-blocking mechanism, outperforming by 71%. As R increases to 100, this invention stabilizes at 51kTPS, consistently maintaining its advantage.

[0038] Delay stability: Under high-frequency reconfiguration, the delay of Turritopsis fluctuates drastically, reaching as high as 6.0 seconds at R=10. In contrast, this embodiment maintains a smooth delay curve, with a delay of less than 3.2 seconds even at R=10, and converges to 2.3 seconds as the system stabilizes, demonstrating the strong adaptability of this embodiment to highly dynamic environments.

[0039] Third, this embodiment also tests the efficiency of the optimistic distributed key refresh protocol, as follows: Under the same hardware environment, the network node size was increased from 16 to 64, and the optimistic distributed key refresh protocol (including optimistic and pessimistic paths), the traditional asynchronous distributed key refresh protocol, and the asynchronous distributed key generation protocol of this embodiment were tested respectively. The total running time required for each protocol to complete one full key refresh was recorded.

[0040] The results are shown in Table 1. With a scale of 64 nodes, this embodiment (optimistic path) takes only 24.72 seconds, which is 49% shorter than the traditional asynchronous distributed key refresh protocol (48.61 seconds) and 85% shorter than the asynchronous distributed key generation protocol (164.37 seconds), showing a significant improvement in efficiency.

[0041] Table 1 Efficiency test results of different protocols

[0042] IV. This embodiment also tests the latency of the data distribution mechanism under heavy load scenarios, as follows: 1) Load simulation: The network size is fixed at 32 nodes, and the data load size for cross-configuration transmission is set to increase from 5MB to 50MB.

[0043] 2) Mechanism Comparison: Compare the data distribution mechanism of this embodiment 1 with the traditional full state transmission mechanism.

[0044] 3) Metrics logging: Records the transmission latency required from the old configuration being frozen to the new configuration fully taking over the data.

[0045] The results are as follows Figure 9As shown, under 32 nodes and a 50MB load, the traditional state transmission mechanism has a latency of 14.5 seconds, showing a linear increase; this embodiment uses erasure coding distribution technology, with a latency of only 2.4 seconds, achieving a speed improvement of about 6 times, and does not significantly deteriorate with the increase of load.

[0046] Example 2 This embodiment provides a non-blocking reconfigurable dynamic asynchronous Byzantine consensus system, including: The execution layer module is used to perform transaction submission, batch processing, reliable propagation, consensus sorting, and ledger update. After receiving client transactions, it performs deduplication and legality checks, aggregates them into batches, propagates batch data through asynchronous reliable broadcast, generates total order blocks in parallel sorting based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations to the outside world. The control layer module monitors the ledger epoch height. When a preset reconfiguration threshold is reached, it initiates an optimistic distributed key refresh protocol to generate a new configuration threshold key pair using a two-path strategy. ) and configuration ready certificate ; The atomic handover module is used to monitor the ledger status and detects a configured ready certificate. When the corresponding control transaction occurs, the atomic handover process is triggered; The data distribution module is used to perform erasure coding, fragmented broadcasting, and integrity verification on unsubmitted transaction data. The key management module is used to store, distribute, and update threshold key pairs.

[0047] The embodiments and descriptions above are merely illustrative of the principles and preferred embodiments of the present invention. Various changes and modifications may be made to the present invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed.

Claims

1. A non-blocking reconfiguration dynamic asynchronous Byzantine consensus method, characterized in that, Includes the following steps: S1) Construct a layered collaborative architecture of consensus execution layer and reconfiguration control layer; The consensus execution layer is responsible for the propagation, batch processing, sorting, and submission of transactions; The reconfiguration control layer is responsible for handling member changes and threshold key refreshes in parallel. The consensus execution layer-reconfiguration control layer synchronizes control transactions and certificate states in the ledger. S2) The consensus execution layer receives client transactions, performs deduplication and legality checks, aggregates them into batches, propagates batch data through asynchronous reliable broadcast, generates total order blocks in parallel sorting based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations to the outside world. S3) Reconfigure the control layer monitors the ledger Epoch height. When the preset reconfiguration threshold is reached, the optimistic distributed key refresh protocol is initiated to generate a new configuration threshold key pair through a two-path strategy. ) and configuration ready certificate ; S4) When the consensus node parses the ledger and finds the configuration-ready certificate... When a control transaction occurs, an atomic handover process is triggered. S5) Trigger the data distribution process, leave the data of the departing consensus node to the new committee, encode the high-risk transaction data that has not been submitted with erasure coding and broadcast it to the new committee. After verifying the integrity of the shards, the new committee consensus node reconstructs the data as needed and injects it into the transaction pool. S6) Load the new threshold key pair to update the verification predicate, restore transaction sorting and block production under the new configuration, and complete the non-blocking reconfiguration.

2. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 1, characterized in that: Step S2) specifically includes: Transaction submission: The execution layer node receives transaction data sent by the client, which has been constructed and digitally signed by the client; Transaction collection and batch processing: The execution layer node stores the received transactions into the local transaction pool, performs deduplication and validity checks, and packages the valid pending transactions into batches; Reliable data propagation: Initiate an asynchronous reliable broadcast instance to distribute batch data across the entire network, and generate proof after achieving data availability; Consensus ordering and block generation: Consensus nodes run the multi-valued Byzantine consensus protocol to perform total ordering of the batch indices submitted by the execution layer nodes and generate global block proposals including transaction metadata; Ledger state update: Based on the index sequence determined by consensus, the execution layer nodes reconstruct the complete transaction data from the local cache or peer execution layer nodes, execute the transaction logic in sequence and update the blockchain ledger state. Once the transaction state update is completed, it is considered as final confirmation and written to the irreversible ledger. Then, the transactions that have been put on the chain are cleaned up from the transaction pool and returned to the loop for processing.

3. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 1, characterized in that: In step S3), the consensus node reads the local ledger status in real time during operation to obtain the current consensus cycle height value; and compares the current consensus cycle height value with the preset reconfiguration threshold to verify whether the conditions for triggering member rotation or key refresh have been met. If the reconfiguration verification result is negative, the current committee configuration remains unchanged, and the ordinary transactions submitted by users continue to be processed in the main consensus pipeline. If the reconfiguration verification result is positive, the optimistic distributed key refresh protocol is started in parallel without pausing the operation of the consensus execution layer.

4. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 3, characterized in that: In step S3), the optimistic distributed key refresh is initiated, and a new configuration threshold key pair is generated through a dual-path strategy. ) and configuration ready certificate Specifically: Each consensus node in the old committee acts as a dealer, randomly sampling a secret value locally. Based on secret value Build a Threshold polynomial; and using verifiable secret sharing to generate the corresponding polynomial commitment and private key fragment encryption sent to the new committee; After receiving the secret shards and commitments from the old committee consensus nodes, the new committee consensus nodes initiate a multi-valued Byzantine consensus instance to reach an agreement on the sharing of valid old committee consensus nodes and output the set of valid dealers. ; The new committee consensus node verifies private key shards and the set of valid dealers. If the global commitment to consistency is verified and there are no conflicts, the system proceeds to the optimistic path; if the verification fails, the system proceeds to the pessimistic recovery path. In the optimistic path, the new committee consensus nodes locally aggregate the set of valid dealers. The dealer's commitment is to compute the global threshold public key and use the sum of the fragments as the new private key share, with a communication complexity of O(n). ; In the pessimistic path, the new committee node broadcasts an error report, triggering a batch recovery mechanism that aggregates requests for missing shares, and the communication complexity reverts to [previous scenario]. ; Once the new committee node successfully calculates the new private key share and global public key, it signs the new configuration parameters. After collecting a threshold number of signatures, they are aggregated into the final configuration-ready certificate. To peer-to-peer networks.

5. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 4, characterized in that: Step S4 specifically includes the following steps: The consensus node parses the latest block submitted by the main chain and checks whether it contains the handover instructions corresponding to the configured ready certificate Σ; Calculate the atomic cleavage vector based on the block index where the handover instruction is located. And based on atomic cutting vectors Define configuration boundaries; for indices smaller than atomic cut vectors The transaction flow indicated by the height was verified by the old committee, and the index is greater than the atomic cut vector. The transaction flow indicated by the height is now under the control of the new committee; Determine the atomic cutting vector Then, freeze write permissions for the old configuration and refuse to accept any requests exceeding the limits. And the new broadcast slot is signed using the old key; Consensus nodes trigger a streaming handover process based on their own identities, while remaining consensus nodes execute a streaming remapping mechanism to take over transactions in transit; Install new configuration on consensus node And load the new threshold key pair Update the verification predicate and take over the sorting and block production of the transaction stream based on the new configuration.

6. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 5, characterized in that: In step S4), the streaming remapping mechanism specifically includes: Remaining consensus nodes scan locally cached in-transit transaction flows and identify those with index numbers greater than the atomic slicing vector. Transactions in transit with no consensus on their order; For each transaction in transit, the remaining consensus nodes extract its metadata and use the newly configured private key. Digitally sign the metadata to generate a new configuration. The remapping credential that has been verified; The remaining consensus nodes will broadcast a message containing the remapped credentials to the new committee; The new committee members receive and verify the validity of the remapping message. Once the new committee verifies the message, it maps the corresponding old transaction load in the local cache to the newly configured queue for processing.

7. The non-blocking reconfiguration dynamic asynchronous Byzantine consensus method according to claim 6, characterized in that: Step S5 specifically includes: After atomic cross-contamination, the identification index number is greater than Transactions that have not yet been fully distributed are classified as high-risk transaction data and are locked locally. Outgoing consensus nodes adopt The threshold data redundancy coding mechanism encodes locked transaction data into multiple fragments containing redundant information, which are then broadcast in parallel to all members of the new committee. The new committee consensus node receives shards from the old committee consensus node and verifies the integrity of the shards based on the Merkle tree of the transactions, filtering out invalid or malicious shards. The new committee consensus nodes check whether they hold transactions. If they do, they inject the data into the transaction pool; if not, they request additional shards from other consensus nodes, pending collection. Each shard of data is reconstructed and injected into the transaction pool.

8. A non-blocking, reconfigurable, dynamically asynchronous Byzantine consensus system, characterized in that, include: The execution layer module is used to perform transaction submission, batch processing, reliable propagation, consensus sorting, and ledger update. After receiving client transactions, it performs deduplication and legality checks, aggregates them into batches, propagates batch data through asynchronous reliable broadcast, generates total order blocks in parallel sorting based on a pipeline mechanism, updates the ledger status, and outputs transaction confirmations to the outside world. The control layer module monitors the ledger epoch height. When a preset reconfiguration threshold is reached, it initiates an optimistic distributed key refresh protocol to generate a new configuration threshold key pair using a two-path strategy. ) and configuration ready certificate ; The atomic handover module, when the ledger detects a configuration-ready certificate... When the corresponding control transaction occurs, the atomic handover process is triggered; The data distribution module is used to perform erasure coding, fragmented broadcasting, and integrity verification on unsubmitted transaction data. The key management module is used to store, distribute, and update threshold key pairs.

9. A non-blocking reconfigurable dynamic asynchronous Byzantine consensus system according to claim 8, characterized in that: The execution layer module adopts a parallel pipeline structure that decouples propagation and sorting, ensuring that transaction sorting continues in an asynchronous network environment without being paused by control layer activities.

10. A non-blocking reconfigurable dynamic asynchronous Byzantine consensus system according to claim 8, characterized in that: The atomic handover module triggers a streaming handover process, allowing the consensus node to execute a streaming remapping mechanism to take over transactions in transit, and achieves cross-configuration transaction takeover through transaction metadata signature authentication.

Images