Anole: reconfiguration-based protocol for dynamic asynchronous Byzantine fault tolerance

Introduction

Consensus mechanisms form the core of blockchain systems. Byzantine Fault Tolerance protocols are widely adopted to ensure deterministic and efficient agreement while tolerating up to one-third faulty nodes. Popular protocols such as PBFT, HoneyBadgerBFT, and BEAT have been applied in permissioned blockchains, including Hyperledger Fabric and Tendermint. However, while these protocols offer resilience and efficiency, they face critical challenges in supporting dynamic membership and maintaining scalability.

Traditional ABFT protocols, such as HoneyBadgerBFT (Stei et al., 2021; Duan and Zhang, 2022; Miller et al., 2016), are typically designed for static membership, where the set of consensus nodes remains fixed. Any changes to the consensus group—such as the addition or removal of nodes—require full system reconfiguration, which is costly, inefficient, and disruptive. This limitation restricts their applicability in real-world environments where dynamic membership updates are essential. Furthermore, most existing ABFT protocols lack mechanisms for detecting and excluding malicious or inactive nodes, compromising the reliability and integrity of the system in dynamic and practical settings.

Anole is designed to address these challenges through a certificate-based mechanism for managing membership updates without disrupting the ordinary transaction-consensus path (Tran et al., 2023). It avoids an external single trusted third party by distributing certificate and key-management decisions across a replicated Supervisor Committee (SC). The core consensus path is asynchronous ABFT; the current PBFT-based SC is separated as a low-frequency management path and therefore introduces a partial-synchrony requirement for timely reconfiguration.

As summarized in Table 1, compared to traditional BFT protocols such as PBFT (Castro and Liskov, 1999), HoneyBadgerBFT (Miller et al., 2016), and BEAT (Duan et al., 2018), Anole combines an asynchronous transaction-consensus path with certificate-based dynamic membership. Unlike a design governed by one external trusted administrator, Anole replicates management decisions across the SC. Table 1 therefore compares the protocols by their consensus and membership-management properties.

TABLE 1. Comparison among typical BFT protocols.

ABFT systems face several critical issues that undermine their performance and security.

Static Membership Constraints in ABFT Protocols: Asynchronous Byzantine Fault Tolerant protocols, such as HoneyBadgerBFT (Miller et al., 2016), have demonstrated their effectiveness in ensuring consensus in fully asynchronous environments, where network delays and partitions are common. These protocols, however, are typically designed for a fixed set of nodes, meaning that the membership of the consensus group is static throughout the protocol’s operation. The lack of support for dynamic membership—where nodes can join or leave the network without requiring a complete reconfiguration of the system—presents a fundamental limitation.

In many practical blockchain applications, especially in decentralized and permissioned systems, the network needs to adapt to changes in the number and composition of participating nodes. This includes adding new nodes to scale the system or removing faulty/inactive nodes to maintain security and fault tolerance. However, traditional ABFT protocols do not provide native support for dynamic membership updates. Any changes to the consensus group require a full reconfiguration of the system, which is costly and disruptive, limiting scalability and adaptability. In dynamic environments like business ecosystems, financial systems, and the Internet of Things (IoT), this inability to perform seamless membership updates severely hampers the effectiveness of ABFT protocols in real-world applications. There is a growing need for ABFT protocols that can support dynamic membership without the need for full system reconfiguration.

Issues with Relying on a Single Trusted Third-Party: In many traditional BFT protocols, a single third-party entity is used as a trusted intermediary to supervise or mediate the consensus process (Cachin and Vukolić, 2017; Hao et al., 2018). Although this approach can provide a centralized means of ensuring security and integrity, it introduces several significant drawbacks. First, the reliance on a single entity creates a single point of failure, making the system vulnerable to attacks or manipulations aimed at compromising this trusted party (Vukolić, 2016). Furthermore, such centralization contradicts the decentralized nature of blockchain systems, undermining their security and trustlessness. In addition, the involvement of a third-party entity can result in inefficiencies, as it often introduces delays and additional overhead in the consensus process, reducing the system’s scalability and responsiveness. A replicated management approach can instead avoid dependence on a single trusted third-party entity while preserving verifiable decision making.

Difficulties in Detecting and Excluding Malicious Nodes: A critical challenge in Asynchronous Byzantine Fault Tolerant systems is the detection and removal of malicious or faulty nodes that can undermine the integrity, security, and performance of the system. While ABFT protocols are designed to tolerate a certain fraction of faulty nodes, the identification and exclusion of these nodes remains a complex issue, especially when the mechanisms for detection are not sufficiently robust or efficient. Most traditional ABFT protocols lack an adequate and systematic approach for promptly identifying inactive or malicious nodes, leading to the potential continuation of these faulty nodes within the consensus process. This can compromise the reliability of the system, as these nodes may influence or disrupt the consensus outcome. Furthermore, even after identifying malicious nodes, removing them from the system without causing disruptions to ongoing operations is a major concern. Most existing ABFT protocols do not effectively address this issue, making it difficult to maintain a stable and reliable consensus process in the presence of faulty nodes.

These issues highlight the need for a robust, dynamic solution that can manage changes in the consensus group efficiently, use verifiable evidence to trigger the removal of malicious participants, and avoid reliance on an external single trusted third party.

Contributions are summarized as follows.

• We propose Anole, a dynamic ABFT protocol with a leaderless architecture. Unlike static ABFT systems, Anole allows consensus nodes to securely and efficiently join, leave, or be removed from the network without requiring a complete reconfiguration of the system. This design supports adaptable membership management for permissioned deployments while preserving the ordinary transaction-consensus path during reconfiguration.
• We integrate DTPKE to support dynamic recipient and threshold selection during encryption. The ordinary consensus path also integrates local coins to support progress in an asynchronous network without coupling its randomness to a static threshold-signature common coin.
• We develop a certificate-based membership management framework that formalizes the processes for dynamic node operations. This framework includes Join, Leave, and Complain protocols, which ensure secure and verifiable membership updates. The Join and Leave protocols support membership transitions, while the Complain protocol treats inactivity observations as suspicion triggers that require multi-party evidence and committee confirmation before exclusion.
• We evaluate Anole against HoneyBadgerBFT, Dumbo, and HotStuff in LAN and WAN deployments at 4, 7, 16, and 31 nodes, reporting consensus latency and derived throughput under a fixed batch size of 10 transactions.

The rest of this article is organized as follows. Related Works reviews related work. Building Blocks introduces the building blocks used in Anole. Preliminary describes the adversary model and security goals of our protocol. Anole Design presents the design of the Anole protocol. Security Analysis provides a security analysis of the proposed protocol. Performance Evaluation evaluates the performance of Anole through experiments. Conclusion concludes the paper and discusses future research directions.

Related works

Byzantine Fault Tolerance consensus protocols have emerged as a viable approach for achieving secure and reliable consensus in both permissioned and permissionless blockchain environments (Vukolić, 2016; Bessani et al., 2014; Sousa et al., 2018). A significant subset of these protocols operates under partially synchronous conditions and employs a leader-driven architecture (Castro and Liskov, 1999; Yin et al., 2019). In this design, a designated leader or primary node takes on the critical role of proposing and ordering client requests, ensuring an organized sequence of operations across the network.

Asynchronous protocols (Miller et al., 2016; Duan et al., 2018; Guo et al., 2020) operate independently of timing assumptions, enabling a more egalitarian consensus process. In these systems, all nodes are treated equally and independently propose requests rather than relying on a designated leader. Each proposal is resolved—either committed or aborted—through an agreement protocol that uses randomization to overcome the FLP (Fischer, Lynch, and Paterson) impossibility (Fischer et al., 1985). Notably, asynchronous protocols offer the advantageous property of responsiveness (Yin et al., 2019), allowing the system to progress at the pace determined by the actual network delay, ensuring efficient and adaptive operation.

The randomness of RITAS (Moniz et al., 2008.) relies on the local coin-tossing protocol (local coin-tossing (Bracha, 1984)). In comparison, the common coin-tossing protocol (common coin-tossing (Rabin, 1983)) requires 3-4 rounds to complete, with each round involving only steps. However, the local coin-tossing protocol requires an exponential number of rounds, with each round involving 9 steps. Due to the efficiency limitations and architectural constraints of RITAS, it is deployed on networks with no more than 10 nodes. HoneyBadgerBFT introduced the first practical asynchronous Byzantine fault-tolerant protocol. HoneyBadgerBFT is built upon an Asynchronous Common Subset (ACS) module, which consists of Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA), or alternatively, Multi-Valued Validated Byzantine Agreement (MVBA). HoneyBadgerBFT significantly reduces the communication complexity of traditional asynchronous Byzantine fault-tolerant protocols while boasting a well-designed system architecture and robust codebase. It has been deployed on more than 90 nodes in Amazon Cloud. HoneyBadgerBFT (Miller et al., 2016) is based on the ACS framework proposed by Ben-Or (Ben-Or, 1983) and others. Similarly, BEAT (Duan et al., 2018) and EPIC (Zhang et al., 2022) adopt the ACS framework developed by Ben-Or and colleagues. BEAT introduces five distinct protocols (BEAT0-BEAT4) to cater to various business needs. Among them, BEAT0 and BEAT1 support online/offline smart contracts, while BEAT3 and BEAT4 serve as Byzantine fault-tolerant storage protocols. Cachin et al. proposed another framework called SINTRA (Cachin and Poritz, 2002), which employs the Multi-Valued Validated Byzantine Agreement (MVBA). Both HoneyBadgerBFT and SINTRA utilize the ACS framework; however, HoneyBadgerBFT adopts a more efficient ACS design. While SINTRA’s communication complexity is O ( N 2 ), HoneyBadgerBFT reduces it to O ( N ).

The Dumbo (Guo et al., 2020) framework, developed by Zhang Zhengfeng’s team at the Chinese Academy of Sciences Institute of Software, introduced two new protocols: Dumbo1 and Dumbo2. In the ABA phase, HoneyBadgerBFT requires each node to run n instances, whereas Dumbo1 significantly reduces this by running only k instances, where k is much smaller than n. Dumbo2 further reduces the communication complexity to a constant level of O ( 1 ). These two Dumbo protocols demonstrate that reducing the number of ABA instances and utilizing MVBA can significantly improve the efficiency of asynchronous Byzantine fault-tolerant protocols.

Additionally, Duan and Zhang proposed PACE (Zhang and Duan, 2022). The PACE protocol innovatively introduces a Reproposable asynchronous Byzantine fault-tolerant framework, utilizing the Reproposable ABA (RABA) protocol. The RABA protocol allows nodes that initially vote 0 to change their vote to 1. By leveraging RABA, a parallel and highly efficient asynchronous Byzantine fault-tolerant framework can be constructed.

WaterBear (Zhang et al., 2023) is an efficient asynchronous BFT protocol family that matches the security of partially synchronous protocols, utilizing optimized local coin-based ABA and reusable ABA mechanisms. Bolt-Dumbo (Lu et al., 2022) Transformer (BDT) is a practical framework for optimistic asynchronous atomic broadcast. At its core, BDT introduces a fastlane abstraction that ensures speed and simplicity while preparing honest parties to handle fastlane failures caused by malicious leaders or network issues, enabling efficient fallback through pace-synchronization. EPIC and HALE (Zhang et al., 2022) are adaptive asynchronous BFT protocols designed for different adversarial models. EPIC targets the computational model using secure key generation and common coin protocols, while HALE operates in the information-theoretic model, relying on Bracha’s local coin method without needing distributed key generation. SRFACS (Zhu et al., 2024) is a robust framework for anonymous communication, integrating an enhanced ABFT protocol to handle up to ( n − 1 ) / 3 faulty nodes and ensure fault tolerance in asynchronous environments. It employs leader-based communication with efficient leader change protocols, multi-signature schemes for security, and a reputation mechanism to optimize node performance.

Table 2 positions Anole conservatively against representative asynchronous-consensus and dynamic-reconfiguration work. Dumbo, PACE, and WaterBear primarily optimize asynchronous agreement for a configured membership, whereas DEBFT and BMS focus on membership change or reconfiguration. Anole’s distinguishing design combination is an asynchronous ABFT transaction path using DTPKE and local-coin ABA together with MSP-certificate-based membership updates. This is a qualitative protocol comparison, not an empirical performance ranking.

TABLE 2. Qualitative positioning of Anole and representative related protocols.

Table 2 provides architectural positioning rather than a performance ranking because the protocols differ in their system models, reconfiguration objectives, and cryptographic components. Within this design space, Anole integrates DTPKE, local-coin ABA, and MSP-certificate-based reconfiguration for permissioned blockchain deployments. The main notations used throughout this paper are summarized in Table 3.

TABLE 3. Notations and descriptions.

Building blocks

This section outlines the various components utilized in our work, detailing their individual functions and specific characteristics.

Signature scheme

In our system architecture, we enforce the assumption that a node’s identity is non-forgeable. To achieve this, each node is required to append its digital signature to messages exchanged with other nodes. This security measure is implemented through the adoption of the BLS (Boneh-Lynn-Shacham) signature (Boneh et al., 2004), with its core procedures detailed in Algorithm 1.

Algorithm 1 BLS Signature Scheme.

Dynamic certificate management scheme

Dynamic certificates play a pivotal role in Anole’s membership management framework. During the Join protocol, the certificate acts as proof of a node’s legitimacy to participate in the consensus group, validated by other nodes through efficient aggregate signature verification. For the Leave protocol, the certificate ensures that a node’s departure is securely authorized and acknowledged by the system, preventing unauthorized exits that could disrupt consensus operations. In the Complain protocol, the certificate records a committee-confirmed complaint supported by verifiable malicious-behavior evidence or multi-party suspicion evidence; the certificate, rather than a single observer’s window measurement, authorizes the subsequent reconfiguration process.

In this work, we adopt the Multi-Signature with Public-key (MSP) scheme proposed by Boneh (Boneh et al., 2018), which leverages bilinear pairings to enable efficient signature aggregation and key aggregation. This scheme allows multiple signatures to be compactly combined into a single aggregate signature, significantly reducing the verification overhead. Importantly, MSP is resilient to rogue key attacks, ensuring that the signature generation process remains secure even in the presence of malicious participants (Mao et al., 2023). The MSP scheme is particularly well-suited for dynamic membership management in ABFT systems. In Anole, we integrate MSP as the foundation for generating compact aggregate signatures, which serve as dynamic certificates. These certificates are critical for verifying the legitimacy of nodes during Join, Leave, and Complain operations, enabling secure and efficient membership updates without disrupting ongoing consensus processes. By using the generated aggregate signatures as certificates, our protocol ensures that membership changes are not only verifiable but also lightweight and scalable. Below, we outline the key features of MSP that make it integral to our protocol:

• Compactness: Aggregate signatures produced by MSP are highly compact, significantly reducing the communication and storage overhead associated with membership updates.
• Efficiency: The aggregation process minimizes computational costs, allowing rapid generation and verification of certificates for dynamic operations.
• Security: MSP ensures the integrity and authenticity of certificates, providing resilience against malicious attacks such as rogue key and replay attacks.

Algorithm 2 MSP Scheme.

As shown in Algorithm 2, the following pseudocode provides a high-level overview of the MSP signature process, which serves as the foundation for constructing dynamic certificates.

By employing the MSP-based dynamic certificate scheme, Anole achieves a secure, scalable, and efficient mechanism for membership updates. This integration ensures that membership changes, whether for joining, leaving, or removing nodes, are handled with cryptographic guarantees of authenticity and integrity.

DTPKE scheme

HoneyBadgerBFT’s TPKE fixes the threshold and participant set during configuration. In Anole, DTPKE denotes the system-level dynamic threshold encryption component, which is instantiated using the DTIBE construction of Susilo et al. (Susilo et al., 2016). Node identities serve as encryption identities, and the sender selects the recipient identity set and decryption threshold when creating a ciphertext. This allows an approved membership change to be reflected by updating the recipient set without generating a fresh group key for every configuration.

Algorithm 3 presents the DTPKE interfaces exposed to Anole. Here, I D identifies a node and its encryption identity, d I D is the identity-bound private key, and M P K and S K are the master public and secret keys. Authorized recipients produce decryption shares, and the ciphertext can be recovered only after the required threshold of valid shares is available.

Algorithm 3 DTPKE Scheme.

Unlike a TPKE configuration with a fixed threshold and participant set, DTPKE allows the sender to select recipient identities and threshold t at encryption time. This property supports Anole’s membership transitions by aligning encrypted proposals with the approved recipient identity set.

Local-coin driven ABA protocol

HoneyBadgerBFT uses Binary Agreement (BA) to decide a bit vector representing the proposals selected for output. Its BA protocol uses a threshold-signature scheme to construct a common coin (Boldyreva, 2002). Common-coin designs usually associate threshold key material with a configured committee or epoch; membership changes therefore require corresponding key refresh or reconfiguration procedures.

Anole employs Bracha’s ABA protocol, which uses local coins to ensure consensus in asynchronous environments. This approach follows the Asynchronous Common Subset (ACS) framework and achieves adaptive security by relying on the randomness of local coins for progress. Specifically, we adopt G. Bracha’s ABA protocol (Bracha, 1984), a well-known method for achieving binary agreement in asynchronous systems resilient to up to ⌊ ( n − 1 ) / 3 ⌋ faulty nodes. The protocol progresses in phases, where each phase consists of multiple rounds. In every phase, replicas exchange messages carrying binary values. The protocol ensures that a binary value is accepted only if it is supported by a sufficiently large fraction of replicas in the network. This mechanism guarantees consistency and prevents invalid values from being agreed upon. The use of local coins ensures that the protocol breaks potential deadlocks in asynchronous environments by introducing randomness into the decision-making process.

The local-coin choice reflects a protocol-level trade-off between ABA round behavior and membership-management complexity. A threshold-signature common coin provides correlated public randomness and often yields fewer or more predictable expected ABA rounds. Each coin invocation, however, requires nodes to generate and disseminate coin shares, collect a threshold of valid shares, verify them, and combine them into the common random value. Such designs usually bind threshold key material to a configured committee or epoch, so membership changes require key refresh or reconfiguration. Bracha’s local-coin ABA avoids threshold common-coin key setup and refresh, reducing its coupling with Anole’s changing DTPKE recipient sets and MSP membership certificates. This simplifies integration with dynamic membership, at the cost of more variable expected rounds and potentially higher message-round overhead. Anole therefore adopts local coins to reduce the interaction between common-coin key management and reconfiguration, rather than to claim uniformly lower latency than common-coin designs.

Algorithm 4 ABA Protocol with Local Coin-Tossing.

As shown in Algorithm 4, the protocol begins with each replica broadcasting its initial binary value v to all other replicas and collecting P R O P O S E messages from at least n − t replicas. Valid values are added to the set v a l i d V a l u e s, and if a single value is supported by a sufficiently large fraction of replicas, the protocol moves to the commit phase. In the commit phase, replicas broadcast their commitment to the agreed value, and once C O M M I T messages from n − t replicas confirm the value, agreement is reached, and the protocol terminates. If no single value gains sufficient support, the protocol utilizes the local coin generator L C to introduce randomness and select a new binary value for the next phase. This use of local coins ensures progress and avoids deadlocks, enabling the protocol to achieve consistency, validity, and termination in asynchronous settings.

Preliminary

This work aims to ensure the confidentiality, integrity, and availability (CIA) of the system, addressing malicious consensus nodes, data owners, and data accessors. In the proposed system, a strong adversary model is assumed, where the adversary can passively compromise up to f nodes out of n and adaptively compromise an unlimited number of users. The security goals are divided into two categories: confidentiality and trustworthiness.

Confidentiality goals

A unified security definition is introduced to meet all confidentiality-related requirements. The system assumes the following: Anole’s DTPKE confidentiality goal follows the semantic and selective security model of Susilo et al. (2016). An adversary may select challenge messages but must obtain fewer than the threshold number of valid identity-bound private keys or decryption shares for the challenge ciphertext.

• Adversarial Selection: Adversary A selects f consensus nodes to compromise.
• Adaptive Compromise: A interacts with honest nodes and adaptively selects users to compromise, subject to the adopted selective-security restriction that it obtains fewer than the threshold number of valid identity-bound private keys or decryption shares for the challenge ciphertext.
• Challenge Phase:
• A chooses two messages m 0 and m 1, and submits them to an encryption oracle.
• The encryption oracle randomly selects a bit b, encrypts m b, and returns the ciphertext c to A.
• A must not compromise the confidentiality of m b to win the game.
• Interaction: A may interact with honest entities but cannot obtain enough valid private keys or decryption shares to recover the challenge plaintext.
• Output: A outputs a bit b ′. A wins the game if b ′ = b.

Trustworthiness goals

The trustworthiness goals are defined as follows:

• Consistency 1: If any correct node receives a message m, all correct nodes eventually commit m.
• Consistency 2: If any data accessor receives a message m, all correct data accessors also receive m.
• Total Order: If one node receives messages m 1 , m 2 , … , m s and another correct node receives m 1 ′ , m 2 ′ , … , m s ′ ′, then m i = m i ′ for 1 ≤ i ≤ min ( s , s ′ ).
• Liveness: If a message m is proposed by n − f correct nodes, all correct nodes eventually accept m.
• No Message Creation: If a data accessor receives a message m, it must have been published by a data owner.
• No Duplication: A data accessor cannot receive the same message m twice.

Anole design

Anole is designed to address the challenges of dynamic membership management in Asynchronous Byzantine Fault Tolerant systems, offering a robust approach to consensus and membership handling. This approach ensures secure and efficient system operation while accommodating the dynamic nature of the network.

The adopted approach incorporates DTPKE into the regular consensus process so that recipient identity sets and thresholds can reflect an approved membership change. The Supervisor Committee issues membership-related Dynamic Certificates, while DTPKE protects encrypted proposals within the transaction-consensus path. This separation supports protocol-level membership adaptability while preserving distinct consensus and management responsibilities.

This section outlines the core design principles of Anole, including the system initialization phase, the dynamic certificate issuance process, and the workflows for specific requests such as Join, Leave, and Complain operations. These components are designed to work cohesively, ensuring flexible and secure membership management while preserving the continuity and integrity of the consensus processes across the network.

The Anole framework includes three main entities:

1) Supervisor Committee: A replicated set of management nodes (denoted P 0 to P c) responsible for validating membership changes and issuing Dynamic Certificates. The SC is not modeled as one trusted entity or one unilateral decision maker: a certificate represents a committee decision and carries an aggregate signature that can be verified by consensus nodes. Its Byzantine-fault-tolerance assumption must hold for management decisions to remain safe.

2) Consensus Nodes: These nodes participate in the ABFT consensus process to maintain the blockchain ledger and execute transactions. The consensus nodes handle the dynamic reconfiguration operations, adapting to membership changes as dictated by the certificates issued by the Supervisor Committee.

3) Clients: External entities that submit transaction requests to the blockchain network. Clients rely on the consensus nodes to validate and execute their transactions while benefiting from the network’s dynamic and fault-tolerant capabilities.

System design

As mentioned above, the system is composed of clients, a Supervisor Committee, and consensus nodes. The replicated Supervisor Committee is denoted by S C and is tasked with node-identity checks, certificate issuance, and key-management requests. Anole therefore avoids an external single trusted third party, but it does assume that the SC’s Byzantine-fault-tolerance threshold is not exceeded. Let N be the potential maximum number of nodes, while n indicates the actual number currently in operation. Each node P i refers to the i-th participant in the system. The system tolerates up to t faulty nodes.

Before the system starts operation, each node P i with identity I D i generates its signature key pair ( S I G p k i , S I G s k i ) using the BLS scheme. Here, S I G p k i is the public key of node P i, and S I G s k i is its secret key used for signing messages. The Supervisor Committee S C, acting through a replicated committee decision rather than a single member, validates the identity of each node and determines whether it should be admitted into the consensus group. In DTPKE, I D i also serves as the node’s encryption identity. Once validated, S C executes D T P K E . S e t u p to initialize the master public key M P K, which is then broadcast to all valid nodes. For each node P i, S C generates the identity-bound private decryption key d I D i using D T P K E . G e n and securely delivers it to the node. The public information of each node P i is represented as ( I D i , S I G p k i ), which is signed and bound by S C to ensure authenticity.

Asynchrony boundary. The DACS/DTPKE/ABA transaction-consensus path is designed for the asynchronous model and does not wait for an SC decision during ordinary rounds. The SC uses PBFT only for low-frequency join, leave, complaint, certificate, and key-management requests. Consequently, safety of the ordinary ABFT path does not depend on a timely SC response, but the liveness of a pending reconfiguration can stall when the PBFT committee cannot make progress. This design separates asynchronous transaction processing from management-path coordination; an asynchronous BFT committee protocol could extend asynchronous liveness to reconfiguration management.

This section elucidates the procedure for confirming transactions within a distributed system. The consensus mechanism operates through a sequence of iterative rounds, where the current round is represented by r. During each round, participating nodes formulate proposals, which are subsequently evaluated via the consensus protocol. The result of round r is a mutually agreed-upon subset of proposals, shared among all nodes. A visual representation of this process is provided in Figure 1, with a comprehensive breakdown of the steps outlined below.

Clients send transaction requests to all network nodes. Each node P i maintains a local FIFO queue b u f i to store these requests. A fixed batch size B is set, from which node P i randomly selects B / n requests among the first B entries in b u f i. Node P i uses the D T P K E . E n c algorithm to encrypt the selected requests, producing the ciphertext v i.

The D A C S [ r ] establishes a common proposal subset for round r. All nodes execute D A C S [ r ] by submitting their own v i. The protocol involves n binary agreements { A B A i } n, based on Bracha’s protocol with local coins, to decide acceptance. Node P i initiates R B C i with v i, and when it receives v j from R B C j, it checks whether input has been sent to A B A j; if not, it inputs 1. Once n − t A B A instances output 1, it inputs 0 to any remaining ones. After all A B A instances finish, D A C S [ r ] outputs a common subset { v j } j ∈ S.

Each node P i applies D T P K E . S h a r e D e c to compute decryption shares for each v j, j ∈ S, and multicasts them. Upon receiving at least t + 1 valid shares for a ciphertext, P i uses D T P K E . C o m b i n e to recover plaintexts { y j } j ∈ S.

Certificate request protocol

In this part, we describe the content and structure of certificates, as well as the different types of certificate applications that nodes in the system may initiate. Certificates serve as a formal proof of a node’s validity and authorization to join, leave, or perform certain operations within the network. The protocol ensures that each certificate request is properly authenticated and verified by the participating nodes, maintaining the security and integrity of the system.

Certificates play a crucial role in various reconfiguration protocols, enabling nodes to request and prove their identity or membership in the network. These requests can involve the joining or leaving of nodes, as well as complaints against inactive or malicious nodes. By formalizing these requests with certificates, the system prevents unauthorized actions and ensures that any changes to the network configuration are agreed upon through a transparent and consensus-driven process.

Join request

The purpose of the certificate request is to enable a new node to obtain a legitimate certificate for joining the network. Suppose the system already contains n nodes, and a new node with ID n + 1 (where n + 1 ≤ N) seeks to join the system. The certificate request process is illustrated in Figure 2a, and it can be divided into three stages: broadcast request, consensus, and reply.

Broadcast request phase

The joining node P n + 1 begins by running the K e y G e n function to obtain its key pair ( S I G p k n + 1 , S I G s k n + 1 ). It then formulates a join request J R and sends it to the management component S C, with the request structured as follows: The join request is constructed as shown in Equation 1.

J R = J , S I G pk n + 1 , I D n + 1 , S i g G e n h m , S I G sk n + 1 (1)

The symbol J identifies the message type. S I G pk n + 1 refers to the public key of node P n + 1. The hash function h ( m ) is applied to the concatenated data formed by these elements. The term S i g G e n h ( m ) , S I G sk n + 1 denotes the signature produced by P n + 1 on the hashed message using its private key.

Consensus phase

After receiving J R from node P n + 1, S C first verifies the J R to determine whether node P n + 1 should join the system, and then checks the correctness of S i g G e n ( h ( m ) , S I G sk n + 1 ). Next, S C will initiate consensus on the request using the PBFT protocol (Castro and Liskov, 1999). The consensus phase will involve multiple rounds of message exchanges among the nodes to achieve agreement on whether node P n + 1 should be accepted. Because PBFT provides liveness under a partial-synchrony assumption, this management request may be delayed during severe asynchrony; the ordinary asynchronous transaction-consensus path can continue under its existing membership while the request is pending.

Reply certificate phase

Once the consensus is reached, and node P n + 1 is accepted into the system, each node uses the M S P . S i g function to sign the message and sends the signature to the Leader node. The Leader node then uses M S P . A g g to aggregate the signatures. Afterward, the Leader node in S C uses D T P K E . G e n to generate the private key d I D n + 1 for node P n + 1 in DTPKE. Finally, S C sends the J o i n C e r t i f message is defined in Equation 2, which includes d I D n + 1, to node P n + 1.

J o i n C e r t i f = A c c e p t J , J R , A g g h m (2)

Here, A c c e p t J specifies the message type that confirms the join request, while A g g ( h ( m ) ) represents the aggregated signature generated by S C over h ( m ).

Leave request

Similar to joining, leaving also requires applying for a certificate in advance. The Leave Request enables a node to exit the network without triggering a full reconfiguration. When node P k, with k ∈ { 1 , … , n }, intends to leave, the corresponding protocol is illustrated in Figure 2b, with further details described below.

Broadcast request phase

Node P k broadcasts L R to all nodes in S C. The L R message contains the following: The leave request is constructed as shown in Equation 3.

L R = L , S I G pk k , I D k , S i g G e n h m , S I G sk k (3)

L denotes the message type, I D k identifies node P k. The signature S i g G e n ( h ( m ) , S I G sk k ) is produced by P k over the hash of message m using its private key.

Consensus phase

After receiving L R from node P k, S C first verifies the correctness of the signature S i g G e n ( h ( m ) , S I G sk k ). Once the verification is successful, S C initiates consensus on the request using the PBFT protocol. The consensus ensures that all nodes agree on whether node P k should be allowed to leave the network.

Reply certificate phase

Once consensus is reached, each node signs the message using M S P . S i g and sends the signatures to the Leader node. The Leader node then aggregates the signatures using M S P . A g g. After the signatures are aggregated, the Leader node generates a private key d I D k for node P k in DTPKE using D T P K E . G e n. Finally, S C sends the LeaveCertif message is defined in Equation 4 to node P k.where A c c e p t L is a message type indicating that the leave request has been accepted, A g g ( h ( m ) ) is the aggregated signature of S C on the message hash h ( m ).

L e a v e C e r t i f = A c c e p t L , I D k , r , A g g h m (4)

Complain request

The C o m p l a i n R e q u e s t is designed to initiate committee review of verifiable malicious behavior or suspected inactivity. It separates a local suspicion trigger from the certificate and multi-party confirmation required for exclusion.

Malicious Behavior: The first type of faulty behavior is malicious activity. If a node P i detects malicious behavior from another node P j, it immediately invokes the C o m p l a i n R e q u e s t. Malicious behaviors include, but are not limited to, the following:

• Node P j proposes a set of transactions that are eventually included in the common subset, but these transactions are found to be invalid or tampered with.
• Node P j sends conflicting messages to different nodes, causing inconsistencies within the system and undermining consensus integrity.

These types of malicious actions disrupt the consensus process and need to be detected quickly to maintain system security.

Suspected Inactive Behavior: The second complaint trigger is an observation of insufficient participation. We define w as an engineering round window and p as a predefined proposal-count threshold. If node P j has proposed fewer than p proposals during the last w rounds, an observer may classify P j as a complaint candidate, or suspected inactive node, and submit supporting round records. This window is not a perfect failure detector and does not claim to distinguish a crash, malicious withholding, and an arbitrarily slow link in a purely asynchronous network.

The observation triggers suspicion only; it does not authorize one observer to remove P j. Safety does not rely on the window being an accurate fault classifier. Instead, exclusion requires authenticated evidence from multiple nodes, SC confirmation, a valid complaint certificate, and the reconfiguration replies described below. The practical speed at which a complaint is triggered depends on the engineering choice of w and p, analogous to a timeout-like deployment assumption. False or delayed suspicion can therefore affect reconfiguration liveness and efficiency, but cannot by itself change membership.

Assume the system consists of n nodes and that node P s, where s ∈ { 1 , … , n }, is accused of verifiable malicious behavior or is a suspected-inactive complaint candidate. The following protocol requests committee review and does not treat the accusation itself as a final fault determination. The removal process is shown in Figure 2c, with the steps detailed below.

Node request phase

Every node P i assesses the behavior of all nodes in the consensus process, collecting authenticated evidence of malicious behavior or observations that trigger suspected inactivity.

If node P k considers node P s to be malicious or a suspected-inactive complaint candidate, it sends a C R message to S C: The complaint request is constructed as shown in Equation 5.where C is a message type, I D s is the identity of the node being complained about, I D k is the identity of node P k.

C R = C , I D s , I D k , S i g G e n h m , S I G sk k (5)

Consensus phase

After receiving C R from node P k, S C first verifies the correctness of the signature S i g G e n ( h ( m ) , S I G sk k ). The committee also checks the attached evidence and whether independent complaints satisfy the required threshold. Once the signature is verified, S C initiates consensus on the complaint request using the PBFT consensus protocol. After reaching consensus, each node records the information about the complaint candidate locally.

Next, S C checks how many times the node has been complained about. If node P k finds that it has received C R regarding I D s from more than f different nodes (where f is the fault tolerance threshold), it adds node P s to its local blacklist. Then, P i signs the complaint request using M S P . S i g and sends the signature to the Leader node, which aggregates the signatures using M S P . A g g.

Reply certificate phase

Once the signatures have been aggregated, S C generates a response and sends the C o m C e r t i f message is defined in Equation 6 to node P k. This message indicates that the complaint against node P s has been accepted.where A c c e p t C is a message type indicating that the complaint has been accepted, and A g g ( h ( m ) ) is the aggregated signature of S C on the message hash h ( m ).

C o m C e r t i f = A c c e p t C , I D s , A g g h m (6)

Membership management

Node join and reconfiguration

In this part, we describe the process through which a new node can join the network without disrupting or reconfiguring the entire system.

After receiving the c e r t i fi c a t e, node P n + 1 broadcasts it to all nodes in the network. Upon receiving the certificate, each node, such as node P i, where i ∈ { 1 , … , n }, will verify the validity of the certificate. If the verification is successful, node P i proceeds to execute the Reconfiguration Protocol, as shown in Figure 2d.

If the c e r t i fi c a t e is determined to be valid, node P i will reply with a J R e p l y message is defined in Equation 7 to node P n + 1.where J A c c e p t confirms node P i’s acceptance of the join request, with signature S i g G e n ( h ( m ) , S I G sk i ) on the hash h ( m ).

J R e p l y = J A c c e p t , I D i , S i g G e n h m , S I G sk i (7)

After node P n + 1 has collected 2 t + 1 J R e p l y messages, it packages them into a single message and broadcasts the aggregated message to all nodes and to the S C. Existing nodes schedule the membership update for round r + 2, while P n + 1 becomes voting-eligible at that round only if it has completed the state-synchronization checks described below; otherwise, its activation is deferred.

This design ensures that a node can only join the system at the start of a new round, providing a clear and synchronized transition. Moreover, by requiring at least 2 t + 1 replies before node P n + 1 joins, the system guarantees that sufficient consensus has been reached, preventing malicious nodes from easily joining the network. Additionally, this approach ensures that there is enough time for message delivery, as it requires at least one full round for all messages to propagate across the system.

State synchronization for joining nodes

A valid Join certificate and 2 t + 1 J R e p l y messages authorize membership, but they are not sufficient for a joining node to validate new proposals. Before participating from round r + 2, node P n + 1 performs state synchronization against the configuration that approved its join. It first obtains the latest membership certificate and requests from existing consensus nodes a recent stable checkpoint, the corresponding state digest, committed block headers or ledger prefix, and the commit certificates that bind the checkpoint to the ledger history.

The synchronization has two stages. During checkpoint bootstrap, P n + 1 waits for matching checkpoint digests and supporting certificates from at least 2 t + 1 existing nodes; it does not trust a checkpoint supplied by one peer. The node verifies the aggregate or multi-party signatures and checks the checkpoint’s Merkle root or hash-chain commitment against the supplied committed headers. During incremental catch-up, it downloads and verifies the blocks and commit certificates after that checkpoint up to the latest committed round. Data chunks may be obtained from different peers, but every chunk must be authenticated against the verified digest or hash chain.

Node P n + 1 remains non-voting while synchronization is incomplete. It participates in consensus at or after round r + 2 only after verifying (i) the latest membership certificate, (ii) a 2 t + 1-supported checkpoint certificate or consistent digest, and (iii) the incremental committed suffix. If these conditions are not met by round r + 2, activation is deferred rather than allowing an unsynchronized node to vote. This state-transfer rule prevents a single Byzantine peer from presenting a fabricated ledger state.

Node leave and reconfiguration

This part outlines how a node can exit the network without disrupting ordinary consensus or requiring a full system restart. When node P k, with k ∈ { 1 , … , n }, wishes to leave, the protocol is illustrated in Figure 2e, with further details provided below.

Similar to the node joining process, node P k broadcasts its c e r t i fi c a t e to all nodes in the network. Upon receiving this request, each node in the network, such as node P i, verifies the validity of the certificate. If the certificate passes all checks, node P i will initiate the Reconfiguration Protocol. If the c e r t i fi c a t e is deemed valid, node P i replies with a L R e p l y message is defined in Equation 8 to node P k.

L R e p l y = L A c c e p t , I D i , S i g G e n h m , S I G sk i (8)

Here, L A c c e p t is a message type indicating that the leave request has been accepted, and S i g G e n ( h ( m ) , S I G sk i ) is the signature of node P i on the hash of the message h ( m ).

After node P k has received 2 t + 1 L R e p l y messages, it aggregates these replies and broadcasts the result to all nodes, as well as to S C. Node P k will officially leave the network starting from round r + 2. Similarly, after node P i has received 2 t + 1 valid L R e p l y messages, it will exclude node P k from the system starting from round r + 2.

This design ensures that nodes can leave the network without disrupting consensus. By requiring at least 2 t + 1 valid replies before any node is removed from the system, the protocol guarantees that the decision to remove a node is made with sufficient consensus, protecting the network from malicious removal or denial-of-service attacks. Additionally, the round-based exclusion guarantees that there is sufficient time for all nodes to receive and process the leave requests, preventing race conditions or message loss.

Node clear and reconfiguration

This part removes a node only after a complaint has received a valid SC certificate and sufficient reconfiguration support. As shown in Figure 2f, node P k broadcasts the certificate concerning P s to the other nodes. Each node P i verifies the certificate before executing the Reconfiguration Protocol; the original local suspicion alone is insufficient.

If the c e r t i fi c a t e is valid, node P i will respond with the CReply message is defined in Equation 9 to node P k:where C A c c e p t confirms node P i’s acceptance of the complaint and exclusion of node P s, with signature S i g G e n ( h ( m ) , S I G sk i ) on message hash h ( m ).

C R e p l y = C A c c e p t , I D s , S i g G e n h m , S I G sk i (9)

Once sufficient valid C R e p l y messages are received, node P k aggregates and broadcasts the responses. A node P i excludes P s and records it in its local blacklist only after verifying the valid complaint certificate and the sufficient reconfiguration replies.

This protocol ensures that nodes supported by a valid complaint certificate and sufficient reconfiguration replies can be excluded without a global restart. The complaint window is only a suspicion trigger; signatures, multi-party evidence, committee confirmation, and reconfiguration replies make the process auditable and prevent a single observer from directly excluding an honest but slow node. Excluded nodes cannot rejoin without proper revalidation.

Security analysis

This section analyzes the proposed Anole framework’s confidentiality, integrity, and availability properties under the stated adversary model. The confidentiality claim for DTPKE is inherited from the adopted construction and its security model rather than established through a new formal reduction in this paper.

Confidentiality analysis

The primary goal of confidentiality is to ensure that sensitive information is accessible only to authorized entities while remaining secure against both passive and active adversaries.

The confidentiality of the DTPKE component is inherited from the adopted DTIBE instantiation of Susilo et al. (2016). Susilo et al. define semantic and selective security for DTIBE and prove their construction secure under the EMSE-DDH assumption.

Under the adopted model, an adversary that obtains fewer than the threshold number of valid identity-bound private keys or decryption shares cannot distinguish the encrypted message contents with non-negligible advantage. Malformed or unauthorized share-decryption attempts return ⊥. This inheritance argument depends on the assumptions and threshold restriction of the adopted construction; it is not a new independent DTPKE formal reduction.

Integrity analysis

Integrity ensures that all committed messages are authentic, unaltered, and free from unauthorized creation or duplication.

The Anole framework employs authenticated digital signatures and reliable communication channels to guarantee the authenticity of messages exchanged between data owners, consensus nodes, and data accessors. Every message is signed with a unique key pair generated using the BLS signature scheme, ensuring that it cannot be tampered with or forged by malicious actors.

The first integrity property, Consistency 1, ensures that if a correct node commits a message m, all other correct nodes eventually commit m. This is guaranteed by the asynchronous Byzantine Fault Tolerance (ABFT) protocol, which ensures consensus even in the presence of f faulty nodes. Similarly, Consistency 2 ensures that if a data accessor receives a message m, all other correct data accessors also receive m.

Furthermore, the system guarantees that no unauthorized messages can be created. Any committed message m must originate from a legitimate data owner, as verified by its digital signature and the authenticated channels through which it was transmitted. Additionally, the system’s sequential processing ensures that duplicate messages are not delivered to any data accessor. Each node maintains a local log of processed messages, identified by unique sequence numbers, which eliminates the possibility of duplicate message delivery.

Thus, the integrity of the Anole framework is preserved, as no unauthorized or duplicate messages are accepted by correct nodes.

Availability analysis

Availability ensures that all legitimate requests are processed, and that the system remains operational even under adversarial conditions.

The Anole framework guarantees availability through the liveness property of the ABFT protocol. This property ensures that if a message m is proposed by n − f correct nodes, it will eventually be delivered to all correct nodes. The system is designed to tolerate up to f faulty nodes without disrupting the consensus process, ensuring continuous progress.

Dynamic membership management can enhance availability by allowing the system to adapt to changing network conditions. A node can be excluded through the complaint and reconfiguration protocols only after the required evidence, certificate, and replies are verified; an inactivity-window observation alone is insufficient.

Membership updates, such as node join or leave requests, are authenticated by Dynamic Certificates issued through replicated SC agreement. Their safety relies on certificate verification and the committee fault threshold. Their timely completion additionally depends on the liveness of the current PBFT-based management path under its partial-synchrony deployment assumption.

In summary, the Anole framework guarantees the availability of the system by maintaining fault tolerance, supporting dynamic membership, and ensuring progress even in the presence of adversarial behavior.

Performance evaluation

This section evaluates three components of the prototype. The DTPKE microbenchmark isolates cryptographic computation costs across recipient-set sizes and message lengths. The regular-consensus experiments compare the latency and derived throughput of Anole, HoneyBadgerBFT, Dumbo, and HotStuff in LAN and WAN deployments. The certificate-request experiments measure the latency of Join, Leave, and Complain operations under the evaluated committee configurations.

DTPKE component evaluation

This microbenchmark evaluates the efficiency and node-count scaling trend of DTPKE on a single computer equipped with an Intel Core i5-13490F CPU and 32 GB of RAM. The Python implementation ran on Ubuntu 20.04 LTS and covered node counts from 4 to 52 and message lengths from 16 bytes to 16,384 bytes. The experiment isolates DTPKE cryptographic costs; distributed consensus latency is evaluated separately in the following subsection.

Figures 3, 4 report the encryption, decryption, and total execution times of DTPKE across the evaluated node counts and message lengths. Encryption time increases approximately linearly with node count, averaging 8.7 ms for 4 nodes and 112.7 ms for 52 nodes. Variations remain below 5% across message lengths from 16 bytes to 16,384 bytes, indicating that encryption time is influenced primarily by recipient-set size. In contrast, decryption time remains between 0.002 ms and 0.004 ms and is largely unaffected by node count or message length. The total execution time follows the encryption-time trend, increasing from 9.2 ms for 4 nodes to 113.8 ms for 52 nodes. Decryption contributes less than 1% of the total execution time. These measurements identify encryption as the dominant DTPKE computation cost as the recipient set grows.

Regular consensus process evaluation

We evaluate Anole’s regular consensus path against HoneyBadgerBFT and Dumbo, and include HotStuff as an additional baseline where measurements are available. Anole is the local-coin prototype implemented using the BEAT open-source library (Duan et al., 2018). The experiments cover 4, 7, 16, and 31 nodes for Anole, HoneyBadgerBFT, and Dumbo in LAN and WAN deployments; HotStuff is evaluated at all four LAN sizes and at 4 and 7 nodes in WAN. The WAN deployment distributes participants across Hangzhou, Japan, Virginia, London, Chengdu, and Hong Kong.

Consensus latency T c is measured in seconds from the start of a consensus instance until agreement is reached. Each consensus instance commits a batch B of 10 transactions in this experiment. We report derived throughput as the fixed batch size divided by the measured consensus latency: The derived throughput is calculated according to Equation 10.The resulting throughput is reported in transactions per second (tx/s). It is a latency-derived metric for the fixed batch configuration, rather than a saturation or peak-throughput measurement.

T h r o u g h p u t = B T c (10)

Figure 5 reports the LAN results. Dumbo records the lowest latency and highest derived throughput at 4, 7, and 31 nodes, while HotStuff records the lowest latency and highest derived throughput at 16 nodes. HotStuff also remains lower-latency than Anole across all evaluated LAN sizes, with latencies of 0.5262, 0.9950, 1.3178, and 3.3163 s at 4, 7, 16, and 31 nodes, respectively. HoneyBadgerBFT has lower latency than Anole at 4 nodes, recording 0.939 s compared with Anole’s 1.687 s. As the node count increases, HoneyBadgerBFT’s latency rises to 4.253, 18.687, and 48.191 s, while Anole records 2.646, 3.7351, and 25.441 s at 7, 16, and 31 nodes. Consequently, Anole provides higher derived throughput than HoneyBadgerBFT at these three larger LAN configurations.

Figure 6 reports the WAN results. HotStuff has WAN measurements for 4 and 7 nodes, where it records the lowest latency and highest derived throughput: 0.5855 s and 17.0794 tx/s at 4 nodes, and 0.4959 s and 20.1654 tx/s at 7 nodes. Among the protocols evaluated at all four WAN sizes, Dumbo provides lower latency and higher derived throughput than Anole at 7, 16, and 31 nodes, while Anole remains lower-latency than HoneyBadgerBFT at every evaluated WAN size. At 31 WAN nodes, HoneyBadgerBFT records 49.684 s, Anole records 25.849 s, and Dumbo records 10.812 s.

Across the evaluated configurations, Anole shows a more favorable latency trend than HoneyBadgerBFT as the node count increases, while Dumbo and the available HotStuff measurements achieve lower latency in several settings. Anole’s additional latency relative to these baselines may reflect the costs of DTPKE, local-coin ABA, dynamic-membership compatibility, and MSP-certificate-based reconfiguration. Because the comparison evaluates complete protocol implementations, it does not isolate the contribution of each mechanism, and the HotStuff WAN comparison is limited to the available 4- and 7-node measurements.

Certificate request evaluation

We evaluated the certificate-request process by measuring Join, Leave, complaint success (Com), and complaint failure (ComF) operations on Alibaba Cloud servers. The experiments used the same ECS environment and the LAN-4, WAN-4, and WAN-7 scenarios described above. Each scenario measured the time from submitting a certificate request to receiving the certificate, with the client node sending a fixed 128-byte message to initiate each request.

The experiments deployed Supervisor Committee nodes on separate Alibaba Cloud servers. A client on a dedicated server broadcast certificate requests to the committee, which used multi-round message forwarding to reach agreement and generate certificates. Each test was repeated multiple times, and the average was computed. Among the evaluated configurations, WAN-7 characterizes the coordination overhead at the largest committee size.

Figure 7 reports the certificate-request latency for the four operations across the three scenarios. In LAN-4, the measured times are 12.7 m for ComF, 37.1 m for Join, 36.3 m for Leave, and 38.4 m for Com. In WAN-4, the corresponding times increase to 241.3 m, 317.5 m, 302.8 m, and 327.9 m. WAN-7 records the highest latencies, with 585.8 m for ComF, 1976.6 m for Join, 1987.1 m for Leave, and 1984.2 m for Com. The increase from LAN-4 to WAN-4 and WAN-7 characterizes the coordination overhead introduced by wider-area communication and the larger evaluated committee.

Conclusion

This paper presented Anole, a reconfiguration-based protocol for dynamic asynchronous Byzantine fault tolerance. Anole integrates DTPKE, Bracha’s local-coin ABA, and MSP-certificate-based membership management to support Join, Leave, and Complain operations without a full system restart. Certificate and key-management decisions are replicated across the SC rather than assigned to an external single trusted third party. The asynchronous transaction-consensus core is separated from the PBFT-based management path, whose reconfiguration liveness depends on partial synchrony. The evaluation isolates DTPKE cryptographic costs, compares consensus latency and derived throughput with HoneyBadgerBFT, Dumbo, and HotStuff in LAN and WAN deployments of up to 31 nodes, and measures certificate-request latency for the evaluated committee configurations. Derived throughput is calculated using a fixed batch of 10 transactions per consensus instance. The security analysis states the confidentiality basis for encrypted proposals, while the membership-management design specifies state synchronization for joining nodes. Together, these results provide a practical basis for dynamic ABFT membership management. Broader deployment scales, additional baseline families, and further implementation-level validation can extend this evaluation.

Limitations of the study

This study evaluates Anole in representative LAN and WAN permissioned-blockchain settings, with consensus experiments up to 31 nodes and separate measurements for DTPKE and certificate-request operations. The reported throughput is derived from a fixed batch size and measured consensus latency, and is intended for consistent protocol comparison rather than saturation-throughput characterization. Anole separates the asynchronous transaction-consensus path from the replicated Supervisor Committee management path; the current PBFT-based SC implementation therefore follows a partial-synchrony assumption for timely reconfiguration. The complaint mechanism uses the w-round observation window as an evidence-based suspicion trigger, while actual membership removal requires committee confirmation and sufficient reconfiguration support. Future work will extend the evaluation to broader deployment scales, additional workloads, and further implementation-level validation of state synchronization and reconfiguration procedures.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Xiaojie Wang, Chongqing University of Posts and Telecommunications, China

Reviewed by: Lin Qiu, Northeastern University, China

Hao Xu, Tianjin University, China