arXiv CSopen access

AutoPilot: Learning to Steer High Speed Robust BFT

AutoPilot: Learning to Steer High Speed Robust BFT Liangrong Chen

Yue Zhang

Eric Zhou

City University of Hong Kong [email protected]

New York University Courant [email protected]

Troy High School [email protected]

Mohammad Javad Amiri

Ryan Marcus

Chenyuan Wu

Stony Brook University [email protected]

University of Pennsylvania [email protected]

City University of Hong Kong [email protected]

arXiv:2606.09120v1 [cs.DC] 8 Jun 2026

ABSTRACT Recent Byzantine Fault Tolerant (BFT) protocols achieve strong performance by combining the low-latency advantages of leader-based BFT protocols with the high-throughput benefits of DAG-based data dissemination. Despite exposing a wide spectrum of internal tunable parameters, these protocols typically rely on static and heuristic configurations, which leads to performance degradation under dynamic workloads, heterogeneous network conditions, and evolving adversarial behaviors. In this paper, we present AutoPilot, a reinforcement learning-based framework that continuously monitors runtime conditions and dynamically adjusts protocol parameters online to optimize consensus performance. To ensure robustness, AutoPilot coordinates learning in a decentralized manner, providing resilience against adversarial data pollution. We implement AutoPilot on top of Autobahn, a state-of-the-art, highspeed, robust BFT protocol, and evaluate it across diverse dynamic environments. Experimental results demonstrate that AutoPilot quickly converges to the optimal configuration under changing environments, reduces end-to-end latency by 49.8% compared to the default protocol configuration, and outperforms random configuration exploration by 73.3%.

1

INTRODUCTION

Byzantine Fault Tolerant (BFT) protocols are critical building blocks in untrustworthy distributed data management systems. By tolerating up to 𝑓 Byzantine adversaries, these protocols guarantee strong consistency through agreement on a common transaction order across replicas. BFT protocols have been widely deployed in distributed applications such as permissioned blockchains [17, 18, 28, 54, 73], permissionless blockchains [27, 60, 61, 66], confidential consortium frameworks [6], distributed file systems [13, 30, 34], locking services [35], firewalls [24, 46, 74, 76], certificate authority systems [88], SCADA systems [21, 59], key-value datastores [42, 48] and key management [67]. Traditional view-based BFT protocols [16, 29, 52, 62, 86] are optimized for responsiveness during fault-free, synchronous periods. However, they suffer from degraded performance when failures or network blips interrupt progress. This degradation persists even after the failure is resolved, as backlogged requests accumulate and delay subsequent transactions. Directed Acyclic Graph (DAG)based BFT protocols [33, 36–40, 55, 58, 68, 71, 75, 77, 78] alleviate this problem by decoupling data dissemination (i.e., building the DAG) from consensus (i.e., ordering the DAG) and propagating transactions asynchronously across replicas. This design enables high throughput and allows the system to continue making progress

even during network disruptions. DAG-based BFT protocols have consequently been widely adopted in practical decentralized systems, such as Aptos [1], Sui [11], Fantom [5], and Avalanche [3]. However, their ordering mechanisms typically require multiple structured rounds and introduce non-trivial latency overhead. State-of-the-art BFT protocols, like Autobahn [47], address both limitations simultaneously by combining a DAG-based asynchronous data dissemination layer with a low-latency, partially synchronous external consensus mechanism. In particular, Autobahn avoids the post-failure performance degradation of traditional BFT protocols, matches the high throughput of state-of-the-art DAGbased protocols, and achieves the low latency of traditional BFT protocols. Autobahn has been deployed in the latest production blockchains, including Sei Giga [8], Stable [10], and Somnia [9]. Despite these advances, Autobahn and other existing DAG-based BFT protocols face two major challenges. First, these protocols expose a wide spectrum of tunable configuration parameters, such as header size, round progression timeouts, and number of concurrent DAG instances [20, 78]. Optimally configuring these parameters is challenging due to the large parameter space and the intricate interactions among them. Second, these protocols are deployed in dynamic decentralized environments where workloads, network conditions and fault scenarios evolve, rendering any static configuration quickly suboptimal. For instance, raising the number of concurrent DAG instances 𝑑 can reduce expected queuing latency by allowing transactions to be proposed more quickly; yet it also increases metadata overhead per round, especially under large network sizes. Consequently, no single value of 𝑑 consistently dominates across all operating conditions. These observations suggest the need for an adaptive mechanism that can continuously adjust protocol configurations at runtime in response to changing environments. Recent studies [19, 22, 31, 41, 64, 65, 81–83] have shown the feasibility of machine learning-based approaches for optimizing distributed protocols. For instance, BFTBrain [83] demonstrates that learned policies can effectively adapt BFT protocol behavior to dynamic conditions, achieving significant performance improvements over static designs. However, existing approaches primarily target traditional BFT protocols and do not address the unique characteristics and optimization challenges of DAG-based BFT systems. Moreover, they focus on inter-protocol switching rather than fine-grained intra-protocol parameter tuning. To fill this gap, we propose AutoPilot, a reinforcement learning (RL)-based framework that automatically tunes protocol parameters at runtime. At a high level, given a performance metric to optimize, AutoPilot intelligently selects among a set of parameter configurations in response to dynamic changes in workload, network

conditions, and fault scenarios. AutoPilot brings three key operational benefits. First, AutoPilot adapts to changing environments, eliminating the need for manual parameter selection across a vast configuration space. Second, AutoPilot operates on a live system and reconfigures itself in real time, without a prolonged offline data collection phase prior to deployment. Third, AutoPilot performs this adaptation in a decentralized, Byzantine fault-tolerant manner, without relying on a centralized machine learning agent. To apply RL to this problem, AutoPilot collects performance metrics from all nodes in a distributed manner. Nodes share locally observed features and reward signals through a coordination protocol, ensuring that all benign nodes converge to the same learning output and maintain resilience even when Byzantine nodes equivocate or forge observations. These metrics serve as features for AutoPilot’s RL engine, which models the selection of parameter configurations as a contextual multi-armed bandit (CMAB) problem [87] and strategically switches among configurations at runtime to identify those best suited to current system conditions. Our evaluation demonstrates that AutoPilot significantly outperforms static parameter configurations under dynamic networks, workloads, and fault scenarios. Specifically, this paper makes the following contributions: • Learned adaptive DAG-based BFT protocols. AutoPilot is the first system that learns to automatically tune fine-grained parameters across both the DAG-based data dissemination layer and the external BFT consensus layer in hybrid BFT protocols such as Autobahn. Without requiring offline profiling or data collection prior to deployment, AutoPilot enables automatic adaptation to unforeseen system conditions at runtime. • Analysis of fine-grained parameters in DAG-based BFT protocols. We conducted systematic experiments across a wide range of tunable parameters in Autobahn, providing insights into how parameter choices should adapt to a changing environment and how parameter interactions affect performance. Our results highlight the breadth of the state and action space, demonstrating that manual tuning is both inefficient and impractical. • Prototype and experimental evaluation. We developed a prototype of AutoPilot and evaluated it on Google Cloud Platform. Experimentally, AutoPilot reduces latency by 49.8% compared to the default configuration under dynamic conditions, and outperforms the baseline without robust learning coordination by 27.6%–281.8% under data pollution attacks.

2

BACKGROUND

Autobahn is a novel partially synchronous BFT consensus protocol that offers high throughput, low latency, and performance robustness. The data dissemination layer in Autobahn loosely resembles the DAG structure. Specifically, each replica maintains a chain of certified records known as a lane. To extend its lane, a replica starts by creating a header containing a batch of transactions together with the certificate of the latest certified record in its own lane. The replica then broadcasts the header to all other replicas. Once the proposer collects 𝑓 + 1 votes from distinct replicas, it aggregates the votes with the header to form a CAR (Certified Availability Record). The resulting CAR becomes the latest vertex (i.e., the certified record) in the replica’s lane, and the proposer can proceed to

Figure 1: Example on Autobahn’s cuts. When cut condition is configured to 2𝑓 + 1, a cut will be created once every 3 new tips are generated. create the next header. A replica votes for another replica’s new header if and only if it has already voted for that header’s parent, a rule known as in-order voting. This mechanism ensures that the complete history of each lane is possessed by at least 𝑓 + 1 replicas and can be fetched at once, thereby reducing data synchronization latency. The latest CAR in a lane is referred to as the tip. The collection of tips across all replicas forms a cut, which represents the current frontier of the DAG. Autobahn orders transactions through a sequence of consensus slots. Each slot 𝑠 is assigned to a leader, which becomes responsible for proposing it once the previous slot 𝑠 − 1 commits. Within each slot, Autobahn follows a classical leader-based consensus [29]. To propose a new slot, the leader continuously monitors its local view of DAG and waits until the configured cut condition is satisfied, i.e., enough new tips have been collected. Upon satisfying the cut condition, the leader creates a new lane cut, as illustrated in Figure 1. All blocks between the new lane cut and the previous lane cut are then aggregated into a proposal for a new slot. If the current leader fails to make timely progress, replicas trigger a view change and elect a new leader to continue the consensus process. By repeating the above process, Autobahn eventually generates a consistent linear sequence of transaction data across all validators.

3

WHY DAG CONSENSUS NEEDS LEARNING

While DAG-based BFT protocols offer greater scalability than traditional leader-based protocols, they also introduce more internal parameters for configuration. In this section, we examine how these knobs affect system performance under different environments. Our experiments are conducted atop Autobahn [47], a representative DAG-based BFT protocol widely deployed in practice [8–10]. As illustrated in Table 1, we evaluate its performance across six scenarios (𝑆 1 –𝑆 6 ) that represent distinct runtime environment conditions, varying across three dimensions: node geographical distribution, workload imbalance across replicas, and adversarial behavior; all of which could change over time in realistic deployments. Table 2 defines the set of configurations that we evaluate in our experiment, including 𝐴1 –𝐴6 and a default baseline (DEF) used by the Autobahn repository. These configurations vary across five key parameters: (1) Fast path timeout controls how long the leader

Table 1: Scenarios representing various environmental conditions Scenario

Node Geographical Distribution

Affected Nodes, Duration, Change

Adversarial Behavior

𝑆1 𝑆2 𝑆3 𝑆4 𝑆5 𝑆6

2 in Asia-east and 2 in US-central 4 in Asia (2 in Asia-southeast and 2 in Asia-east) 2 in Asia-east, 1 in Europe-central, and 1 in ME-central 10 in Asia (All in Asia-east) 4 in Asia (All in Asia-east) 4 in Asia (All in Asia-east)

– – – 5, [0, 120], 10 × workload increase 1, [0, 120], 200ms delay –

– – – – Intentional Vote Delay Non-responsive

Table 2: Parameter configurations

Table 3: Latency comparison (increase compared to the best config.)

Action

FP Timeout

Cut Cond.

Parallel Proposal

Header Size

Max Header /Batch Delay

𝐴1 𝐴2 𝐴3 𝐴4 𝐴5 𝐴6

100ms 100ms 500ms 0ms 100ms 0ms

2f+1 2f+1 2f+1 2f+1 2f+1

1 4 4 4 4 4

32B 32B 32B 32B 32B 128B

5000ms 5000ms 5000ms 5000ms 5000ms 5000ms

DEF

200ms

2f+1

4

32B

200ms

⌈

3𝑓 +1 2 ⌉

waits for 3𝑓 + 1 votes before falling back to the slow path, where a timeout value of 0 indicates that the fast path is disabled; (2) Cut condition determines the minimum number of lane tips required to initiate a new proposal; (3) Number of parallel proposals decides how many consensus slots are allowed to pipeline concurrently; (4) Header/Batch size sets the maximum number of transactions per batch and batches per header. (5) Max header/batch delay bounds the waiting time for assembling a header or batch before it is forcibly emitted. We note that these parameters are also present in other protocols, like Narwhal [44] and HotStuff [56]. We evaluate the configuration parameters listed in Table 2 under each scenario. Each experiment runs for 120 seconds and is repeated twice; reported latency values are averaged across both runs. Details about the experimental setup can be found in Section 7. Table 3 reports the best-performing and second-best configuration choices for each scenario, along with the default configuration. For each configuration, it reports the corresponding end-to-end latency and the percentage latency increase relative to the bestperforming one. Importantly, it demonstrates that no single configuration works well across all scenarios, underscoring the need for adaptive parameter tuning. In the rest of this section, we explore why DAG-based BFT protocols require configuration changes as geography, workload, and adversarial behavior vary.

3.1

Geographic Distribution

Scenarios 𝑆 1 , 𝑆 2 , and 𝑆 3 demonstrate that both the proposal pipelining and the fast path mechanism are strongly influenced by the geographical distribution of replicas. Number of Parallel Proposals (𝑘). Normally, increasing 𝑘 improves performance by executing multiple proposals concurrently: with 𝑘 > 1, up to 𝑘 − 1 slots can begin as soon as the prepare phase of the previous slot completes. For instance, in 𝑆 1 , choosing action 𝐴1 (𝑘 = 1) leads to 28.1% higher latency compared to 𝐴2 (𝑘 = 4),

Scenario

Best Config.

Default Config.

2nd Best Config.

𝑆1 𝑆2 𝑆3 𝑆4 𝑆5 𝑆6

𝐴2 , 658ms 𝐴1 , 158ms 𝐴3 , 1143ms 𝐴5 , 815ms 𝐴4 , 60ms 𝐴6 , 622ms

748ms (+13.6%) 532ms (+236.8%) 1425ms (+24.6%) 1232ms (+51.2%) 248ms (+313.3%) 1262ms (+102.9%)

DEF 𝐴6 , 219ms (+38.6%) 𝐴2 , 1398ms (+22.3%) 𝐴4 , 1224ms (+50.1%) 𝐴2 , 144ms (+140.0%) 𝐴1 , 801ms (+28.8%)

demonstrating the benefit of pipelining. However, setting a larger 𝑘 is not always beneficial: in 𝑆 2 , where consensus rounds are shorter than 𝑆 1 due to low RTTs, aggressive pipelining causes proposals to be generated more frequently, with each proposal carrying only a small number of blocks. This reduces the amortization of consensus costs across transactions while increasing communication overhead, ultimately degrading performance. In this case, 𝐴1 (𝑘 = 1) achieves the best performance. Increasing header size as in 𝐴6 partially mitigates the overhead of frequent proposal initialization but still incurs 38.6% higher latency compared to 𝐴1 . Therefore, 𝑘 must be tuned carefully to balance the benefits of parallelism against the overhead of frequent proposal initialization. Fast Path Timeout. Autobahn’s linear consensus protocol follows the classic PBFT-style pattern, augmented with a fast path that reduces latency from the two-round slow path (5 message delays) to a single round (3 message delays). Specifically, upon collecting 2𝑓 + 1 matching Prepare votes for a proposal, the leader waits for a fast path timeout to determine whether 3𝑓 + 1 matching votes can be gathered. If so, the proposal is committed immediately via the fast path; otherwise, consensus falls back to the slow path and proceeds through an additional round of 2𝑓 + 1 quorum collections. This mechanism represents a fundamental trade-off between communication overhead and responsiveness. In both 𝑆 1 and 𝑆 2 , the network is organized into two clusters containing half of nodes respectively, such that intra-cluster communication is fast while cross-cluster communication is expensive. Since no single cluster has a sufficient number of nodes (2𝑓 + 1) to establish consensus, the fast path typically requires one round of cross-cluster communication and collecting additional 𝑓 votes within the cluster, while the slow path needs to perform two rounds of cross-cluster communication. Under such conditions, taking the fast path is always beneficial. Accordingly, 𝐴2 and 𝐴1 with a fast path timeout of 100 ms achieve the best performance in 𝑆 1 and 𝑆 2

respectively, while disabling the fast path entirely, as in 𝐴4 proves suboptimal in both scenarios. However, under slight network fluctuations where some slot fails to complete the fast path, the protocol is forced to wait for the full fast path timeout before falling back to the slow path. As a result, an excessively long timeout, as in DEF and 𝐴3 , directly increases the duration of this unnecessary waiting period, leaving more transactions blocked and increasing backlog, which in turn increases end-to-end latency. In 𝑆 3 , nodes are spread across three geographically distant regions, resulting in high RTTs. Here, the fast path remains beneficial, but 𝐴2 ’s shorter timeout leads to 22.3% higher latency compared to 𝐴3 ’s longer timeout. The reason is that short timeout causes frequent fallbacks, as the system is unable to gather the additional 𝑓 + 1 responses from distant nodes before the timer expires. 𝐴3 ’s extended timeout provides sufficient time to collect 3𝑓 +1 responses, suggesting that the optimal fast-path timeout depends strongly on the underlying network latency and stability. These results yield two key practical insights. First, in real-world deployments of DAG-based protocols such as public blockchains, nodes may join or leave dynamically, causing the network topology to change over time and necessitating continuous reconfiguration of protocol parameters. Second, the optimal fast path timeout depends on prevailing global network latency, which may fluctuate due to network failures or adversarial interference; the timeout must therefore adapt dynamically to current network conditions.

3.2

Imbalanced Workload

In 𝑆 4 , by scaling the system from 4 to 10 nodes and introducing five hotspot nodes that receive ten times more transactions than the remaining validators, we explore how workload imbalance across replicas affects the data dissemination and the initialization of proposals in the consensus layer. Cut Condition. The cut condition determines when a new proposal can be initiated. In 𝑆 4 , five nodes receive ten times more transactions than the others, causing their lanes to grow significantly faster and producing an imbalance in tip generation rates. When the cut condition is set too high, consensus must wait for tips from slower lanes before performing a lane cut and initiating a new proposal, introducing unnecessary latency. Accordingly, by reducing the cut condition from 2𝑓 + 1 to ⌈(3𝑓 + 1)/2⌉, 𝐴5 allows proposal generation to proceed without waiting for progress from all slow lanes, reducing latency by 33.5% (from 1224 to 815) compared with the second-best configuration. In summary, the optimal cut condition must adapt dynamically to the number of fast lanes, minimizing unnecessary delays imposed by slower nodes. Header Size/Max Header Delay. Header/Batch Size and Max Header/Batch Delay control how quickly new lane tips are generated in the data dissemination layer. Under highly imbalanced workloads, consensus progress is often constrained by the slowest lanes rather than the fastest ones. Larger header sizes require slow lanes to accumulate more transactions before generating a new header, further delaying tip generation and making it harder to satisfy the cut condition. Accordingly, under 𝑆 4 , configuration 𝐴6 (3205ms) incurs 161.8% higher latency compared to 𝐴4 (1224ms) and 160.1% higher latency compared to the default configuration (1232ms), which uses a much smaller Max Header/Batch Delay.

Number of Parallel Proposals (𝑘). The effectiveness of proposal pipelining also depends on the cut condition. Although increasing 𝑘 allows multiple consensus instances to pipeline, a new proposal cannot be generated until the cut condition is satisfied. Under highly imbalanced workloads, proposal generation is frequently delayed by slow lanes, preventing the system from fully utilizing the available parallelism. For instance, the performance differences between 𝐴1 and 𝐴2 in 𝑆 4 remain relatively small despite their different pipelining configurations. This observation highlights a significant interaction between dissemination-layer and consensus-layer parameters: increasing parallelism alone does not guarantee better performance if proposal generation is bottlenecked by insufficient lane progress. The effectiveness of parallelism, therefore, depends on the setting of cut condition.

3.3

Adversarial Behavior

Beyond geographic distribution and workload imbalance, we examine the effect of adversarial behaviors in 𝑆 5 and 𝑆 6 . Intentional Vote Delay. In 𝑆 5 , 𝑓 nodes deliberately delay their consensus votes by 200 ms. Since the fast path requires 3𝑓 + 1 prepare votes, 𝑓 Byzantine replicas can deliberately delay their votes to prevent the leader from collecting a full quorum in time. As a result, the leader is forced to wait until the fast-path timeout expires before falling back to the slow path, introducing unnecessary delay. As shown in Table 3, under scenario 𝑆 5 , disabling the fast path as in 𝐴4 renders the best performance, whereas 𝐴2 and the default incur 145.0% and 313.3% higher latency, respectively. Non-responsive Nodes. In 𝑆 6 , 𝑓 Byzantine nodes cease responding entirely, leaving the protocol to rely on the remaining 2𝑓 + 1 honest nodes for progress. Gathering 3𝑓 + 1 prepare votes is impossible when 𝑓 nodes are silent, causing all fast path waits and falling back to the slow path. Consequently, 𝐴6 that disables the fast path entirely achieves the best performance. The larger header size further helps amortize consensus overhead across more transactions, providing an additional performance benefit. Additionally, since the non-responsive nodes cease proposing new blocks, any cut condition requiring more than 2𝑓 + 1 new tips becomes unsatisfiable, preventing new proposal initialization and potentially triggering view changes that severely degrade throughput.

3.4

The Case for Learning

Our motivating experiments above demonstrate that while the correctness of DAG-based BFT protocols is never impacted by a configuration or environmental change, such changes can have large performance impacts. We make two concrete observations. First, no single configuration is universally optimal: a configuration that maximizes performance under one environmental condition often performs poorly under another. In dynamic environments, relying on a fixed default configuration inevitably leads to substantial performance degradation. Second, protocol parameters interact intricately with one another and with the environment, forming complex dependencies that are difficult to model explicitly. If there is a simple heuristic or hand-crafted cost model that can correctly tune DAG-based BFT algorithms for a variety of different environmental conditions, we were unable to build it. Even if one were able to develop such a heuristic, it would be inherently limited

to past experience, possibly failing to generalize to unseen or adversarial conditions. Collectively, these observations point toward a clear direction: DAG-based BFT protocols must evolve toward an autonomous, learning-based framework to achieve robust performance across diverse and dynamic conditions.

4 4.1

OVERVIEW System Model

In AutoPilot, we consider a system consisting of 𝑛 = 3𝑓 + 1 replicas and a set of clients, where up to 𝑓 replicas may exhibit Byzantine behavior. Each replica simultaneously serves two roles: a validator and a learning agent. The validator is responsible for data dissemination and block ordering, while the learning agent operates off the critical path to collect runtime observations, train learning models, and recommend configuration adaptations during execution. A replica is considered correct if it follows the protocol specification; otherwise, it’s considered faulty. We assume a strong Byzantine adversary that can arbitrarily coordinate all faulty replicas but cannot violate standard cryptographic assumptions. When a replica is faulty, it can behave arbitrarily in any of its roles: faulty validators may exhibit Byzantine behaviors, including equivocation, double voting, and selective message suppression; faulty learning agents may launch learning-specific attacks by reporting manipulated local observations, such as forged state features or rewards, to interfere with distributed model training. AutoPilot assumes a partially synchronous network model [43]. Specifically, there exists an unknown Global Stabilization Time (GST), after which all messages between correct replicas are delivered within a bounded delay Δ. Participants communicate with each other through reliable, authenticated, point-to-point channels. For two different roles on the same node, we assume their communication in-between is always synchronous.

4.2

Design Overview

AutoPilot formulates the configuration tuning process as a reinforcement learning task with two key components: (i) a reinforcement learning agent that guides the selection of parameter configurations according to the changing environment, and (ii) a coordination protocol that orchestrates data collection in a distributed manner. AutoPilot operates in epochs, each consisting of the execution of ℎ slots (i.e., proposals in leader-based BFT protocols), during which the protocol configuration remains unchanged. Here, ℎ is a predefined system hyperparameter that controls how frequently AutoPilot adapts its configuration. Learning agent. Instead of relying on a centralized agent, AutoPilot equips each validator with a local learning agent. Each agent formulates the configuration tuning problem as a contextual multi-armed bandit (CMAB) problem. In AutoPilot, each agent periodically observes the current operating environment as the context, and selects one parameter configuration from a discrete set of candidate configurations (i.e., the arms). After the selected configuration takes effect, the agent observes the resulting system performance as the reward. Each observed (context, action, reward) tuple constitutes a training data point that is used to refine the agent’s policy over time. To be successful, AutoPilot must balance the exploration of new, untested configurations with exploiting past experiences to maximize performance. We adopt the CMAB

Figure 2: Overview of learning process on replica 𝑖. formulation rather than full reinforcement learning for two reasons. First, CMAB admits asymptotically optimal algorithms (e.g., Thompson Sampling [32]) with well-studied regret bounds [14], providing strong theoretical guarantees on convergence. Second, CMAB algorithms are significantly more sample-efficient than full reinforcement learning, which is critical in a production system where each configuration trial incurs real performance cost. Details about the learning algorithms are provided in Section 5. Since AutoPilot operates in a Byzantine environment where no centralized entity can be trusted, each validator only accepts configuration decisions from its co-located agent. The learning agents themselves collectively form a replicated state machine. Specifically, all agents are initialized from the same model state and random seed. For each epoch 𝑡, as detailed in Section 6, the underlying consensus protocol guarantees that all benign agents observe the same sequence of training inputs. With deterministic training, benign learning agents host the same model parameters for a given epoch. Since the learning process is replicated across all nodes, when different agents observe the same context at inference time, they independently derive the same configuration decision. Robust distributed data collection. To prevent Byzantine nodes from polluting or equivocating training data, AutoPilot introduces a robust coordination protocol. After executing a predefined watermark of 𝑗 blocks in epoch 𝑡 (where 𝑗 < ℎ), each agent measures its local context and reward and broadcasts them to other replicas. By leveraging Autobahn’s external consensus layer, the coordination protocol then establishes a globally consistent collection of reports, comprising inputs from at least a two-thirds quorum of agents. Each agent then applies an identical, deterministic filter to this agreedupon aggregation to construct an identical training data point for subsequent learning. Details about this learning-coordination protocol are provided in Section 6. AutoPilot workflow. Figure 2 illustrates the workflow of AutoPilot on replica 𝑖. Each replica in the system follows the same procedure. Step 1: Online data collection. After executing a predefined watermark of 𝑗 blocks in epoch 𝑡 (where 𝑗 < ℎ), each node 𝑖 measures its local context 𝑠𝑖,𝑡 in the current epoch and reward 𝑟𝑖,𝑡 −1 observed during the previous epoch. Each agent then broadcasts its local observations to all other agents. By leveraging the learning coordination protocol, it yields a Byzantine-robust global context 𝑆𝑡 and global reward 𝑅𝑡 −1 that all benign agents agree upon. Step 2: Model update. Each agent adds the newly observed tuple (𝑆𝑡 −1, 𝐴𝑡 −1, 𝑅𝑡 −1 ) to its experience bucket, which stores all of the

state-action-reward tuples observed at run-time. The agent then retrains the predictive model using the updated experience bucket. Step 3: Action selection. Each agent independently infers the action for the current epoch using 𝑀𝜃 based on the current global context 𝑆𝑡 . Since both 𝑆𝑡 and 𝑀𝜃 are consistent across all benign agents, the selected action 𝐴𝑡 is identical without requiring explicit coordination on action. After another 𝑙 ( 𝑗 + 𝑙 < ℎ) slots, each validator switches to the newly selected parameter configuration, and the resulting reward will be measured in the upcoming epoch. By repeating the above procedure in every epoch, each agent continuously refines 𝑀𝜃 , progressively establishing a mapping from observed system conditions to optimal configurations and enabling fully adaptive parameter tuning at runtime.

5

LEARNING ALGORITHM

This section presents AutoPilot’s learning approach in detail. We first formalize the learning problem and explain how Thompson sampling solves it. We then outline the state and action space design, followed by the predictive model used by AutoPilot.

5.1

Problem Formulation

Contextual multi-armed bandits. AutoPilot formulates configuration tuning as a contextual multi-armed bandit (CMAB) problem, where each learning agent observes the current system state 𝑠𝑡 , selects a configuration 𝑎𝑡 from a candidate action space, and observes the resulting performance 𝑟𝑡 as reward. The objective of the agent is to maximize the cumulative reward over time. Depending on the application that leverages BFT consensus, the reward function can be defined using different performance metrics, such as throughput, latency, or a weighted combination of both. CMABs assume that epochs are independent from each other, and the optimal action depends only on the current state. AutoPilot satisfies this assumption, as the current choice of parameter configuration does not affect the pattern of workloads, network, or faults in future epochs. Under this formulation, each epoch is modeled as an independent decision round conditioned on the observed state. Thompson sampling. AutoPilot adopts Thompson Sampling to solve contextual multi-armed bandit problems for its simplicity: at the beginning of each decision epoch, an agent retrains a predictive model using the experiences accumulated in its experience bucket, and then selects the best action predicted by the model. Rather than relying on a model that best fits the observed experience, the sample model parameters are proportional to their likelihood given the training data. More formally, we can define maximum likelihood estimation as finding the model parameters 𝜃 that maximize likelihood given experience 𝐸: arg max𝜃 𝑃 (𝜃 | 𝐸) (assuming a uniform prior). Instead of maximizing likelihood, Thompson sampling simply samples from the distribution 𝑃 (𝜃 | 𝐸). This means that regions of the parameter space strongly supported by the observed data are assigned higher posterior probability and therefore more likely to be sampled. In contrast, regions with less empirical support receive lower posterior probability and are sampled less frequently.

5.2

State, Action and Reward

Guided by the observations in Section 3, we identify the runtime factors that most significantly affect Autobahn’s performance and

use them to construct the state space. We define the action space based on the tunable protocol parameters exposed by Autobahn. 5.2.1 State Space To provide the predictive model with sufficient context, the state space should capture the operating environment of AutoPilot, such as workload characteristics and network conditions. Directly measuring low-level network conditions, however, is challenging in large-scale Byzantine environments due to potential adversarial behaviors. Instead, AutoPilot leverages signals naturally embedded in Autobahn’s local lane structure and consensus execution. Our state space consists of two components. State 1: Lane Growth Rate. We characterize Autobahn’s data dissemination layer as a lane-based structure rather than a strict DAG structure. At time 𝜏, node 𝑖 maintains a local view of the committed lane lengths: (𝑖 ) (𝑖 ) (𝑖 ) L𝜏(𝑖 ) = [𝑙 1,𝜏 , 𝑙 2,𝜏 , . . . , 𝑙𝑛,𝜏 ]

(1)

(𝑖 ) where 𝑙 𝑗,𝜏 denotes the number of committed blocks in validator

𝑗’s lane as observed by node 𝑖. To capture the dissemination progress, AutoPilot computes the lane growth-rate vector at time 𝜏 over a sliding observation window of duration Δ𝜏: R𝜏(𝑖 ) =

) L𝜏(𝑖 ) − L𝜏(𝑖−Δ𝜏 Δ𝜏

(2)

(𝑖 ) where each entry 𝑟 𝑗,𝜏 represents the average growth rate of

validator 𝑗’s lane during the observation window. Intuitively, lane growth rate is jointly determined by (i) workload assigned to each node, (ii) the latency required to collect the first 𝑓 + 1 votes for a newly proposed header, and (iii) node processing capability that affects header production rate. Replicas with higher transaction arrival rates, lower communication latency to neighboring replicas, or better processing capability tend to extend their lanes more rapidly, while the remaining nodes might fall behind. Although the growth rate of an individual lane only reflects the operating conditions of a particular replica, the lane growth-rate vector R𝜏(𝑖 ) captures the growth rate of all lanes, providing an overall view of workload distribution, network conditions, and replica heterogeneity across the system. State 2: Fast-path ratio. We define the fast-path ratio as the proportion of slots finalized through the fast path of Autobahn’s external consensus within the observation window. This metric reflects the network condition of the system: a high fast-path ratio indicates that the communication delays among replicas are generally bounded by the configured fast-path timeout, allowing the required 3𝑓 + 1 votes to be collected before the timeout expires. Conversely, a low fast-path ratio implies slower communication for some nodes, causing requests to fall back to the slow path more frequently. The feature also captures the impact of faults, such as omission failures, leader equivocation, and network partitions, which can all reduce fast-path success and thereby degrade performance. Together, these two state features provide an expressive representation of AutoPilot’s operating environment. Importantly, these signals are naturally observable from the standard execution of the consensus protocol without any additional instrumentation, explicit network measurement, or extra communication overhead.

This makes the state construction lightweight and efficient when deployed in high-performance BFT systems. 5.2.2 Action Space We define the action space by selecting representative and influential tunable knobs divided into two categories according to the protocol structure: data dissemination and consensus. Each action dimension is discretized into a finite set of candidate values, resulting in a total of 72 possible actions. Data dissemination. This category controls how transactions are propagated and how lanes are built. Actions 1&2: Batch size and Max batch delay. These two parameters jointly determine the transaction batching behavior before dissemination. Batch size determines how many transactions are aggregated into a batch, while max batch delay bounds the waiting time before a partially filled batch is sealed and broadcast. Together, they balance responsiveness against communication and cryptographic overhead. Small values lead to frequent dissemination of partially filled batches, increasing network and signature verification overhead. Conversely, overly large values increase transaction queuing delay before dissemination, increasing end-to-end latency. Actions 3&4: Header size and Max header delay. These two parameters primarily affect how fast the lane grows and how frequently consensus is triggered. Header size determines how many batches are aggregated into a header, while max header delay limits how long it can be postponed before a header is sealed. Aggressive configurations generate headers rapidly, causing frequent consensus executions with limited useful payload per proposal and poor amortization of consensus overhead. In contrast, conservative configurations slow lane expansion and delay proposal generation, increasing the time transactions remain pending before execution. Therefore, these parameters govern the trade-off between consensus efficiency and proposal responsiveness. Since both batch size and max batch delay play similar roles in determining when a batch is sealed, jointly tuning parameters concurrently would introduce an additional action dimension while providing limited additional control over the batching behavior. We therefore fix the max batch delay to a sufficiently large value (e.g., 4000 ms), making batch formation primarily driven by batch size. Similarly, we fix the max header delay to 4000 ms and focus on dynamically tuning the header size instead. Consensus. This category comprises parameters for optimizing the performance of the linear BFT consensus layer. Action 5: Cut condition. This parameter defines the number of new tips required to propose a new lane cut. A more aggressive cut condition may increase proposal frequency and responsiveness, but is at the cost of increasing the overhead amortized to transactions. In contrast, a conservative cut condition may commit more transactions each time, but is at the risk of excessive waiting time, especially under skewed DAG growth. Action 6: Fast-path timeout. This parameter determines the maximum waiting time for collecting 3𝑓 + 1 prepare votes in the fast path. If the timeout expires before enough votes are received, the protocol falls back to the expensive slow path. Setting this value to zero effectively disables the fast path. Its optimal configuration heavily depends on communication latency and network stability. Action 7: Number of parallel proposals. This parameter controls the number of consensus slots allowed to be processed concurrently.

Normally, increasing the degree of parallelism allows multiple slots to make progress concurrently, reducing latency and improving resource utilization. However, since proposals are ultimately committed in sequence, excessive pipelining can increase contention for CPU, network, and memory resources, causing the benefits of additional parallelism to decrease or even backfire. 5.2.3 Reward Function Modern DAG-based consensus protocols have substantially improved throughput via highly parallelized data dissemination. As a result, system performance is often no longer primarily limited by throughput, but by end-to-end latency, which becomes the dominant bottleneck for production use cases (e.g., latency-sensitive decentralized finance applications). Therefore, we define a reward function to optimize end-to-end latency as follows: 1 𝑟= (3) 𝑙𝑎𝑡𝑒𝑛𝑐𝑦 where latency is measured in seconds. Our objective is to maximize the reward 𝑟 , i.e., to minimize end-to-end latency.

5.3

Predictive model

AutoPilot chooses random forests [26] as the predictive model due to their good performance on data sets of moderate sizes and fast inference. Each learning agent hosts a predictive model that follows the value-based RL approach: given the featurized state, predict the performance (i.e., reward) of each parameter configuration (i.e., action). If there is a tie on the best-predicted performance, AutoPilot breaks the tie randomly to avoid local maxima. Integrating a predictive model with Thompson sampling requires the ability to sample model parameters from 𝑃 (𝜃 |𝐸), the distribution of model parameters given the current experience. The simplest technique (which has been shown to work well in practice [72]) is to train the model as usual, but only on a bootstrap [25] of the training data. More specifically, the predictive model is trained on a bootstrap dataset, constructed by randomly sampling |𝐸| experiences with replacement from the experience set. This mechanism naturally provides the exploration-exploitation trade-off required by contextual multi-armed bandits. During the early training stage, the experience set is relatively small and sparse, causing the bootstrap datasets to differ significantly from one another. As a result, the variance of prediction is large, and the agent may occasionally overestimate the reward of underexplored actions. Such variability encourages exploration of diverse configurations. As training progresses and more experiences are accumulated, the uncertainty of reward estimation gradually decreases. Consequently, predictions produced by different bootstrap models become increasingly consistent, causing the agent to repeatedly select configurations with the highest estimated rewards and thereby favor exploitation.

6

LEARNING COORDINATION PROTOCOL

Since AutoPilot collects observations from all participants to guide online learning, Byzantine nodes may manipulate their reported observations to misguide the learning process (e.g., over-reporting or under-reporting local measurements). To address this challenge, AutoPilot adopts a robust coordination protocol, aimed at constructing a consistent and accurate global view of observations despite the presence of up to 𝑓 faulty nodes. We further decompose the

observations into two categories: local and global. Local ones are observed independently by each node based on its view of the system. In contrast, global ones represent the consistent observations the whole system agrees upon, constructed by aggregating local observations across nodes through the coordination protocol. As illustrated in Algorithm 1, AutoPilot implements a lightweight coordination protocol that reuses Autobahn’s external BFT consensus layer without introducing additional consensus rounds. The only additional communication occurs when each node broadcasts a 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡 once per epoch. At epoch 𝑡, when replica 𝑖 reaches the observation threshold 𝑗, it computes its local runtime measurements 𝐿𝑜𝑐𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑖 and 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑖 , and broadcasts 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 to all other replicas. The node simultaneously starts a local collection timer 𝑇𝑖𝑡 (Lines 2-6). Each node maintains a local report buffer 𝑅𝑒𝑝𝑜𝑟𝑡𝑠𝑖𝑡 containing all received 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 s. Once a node collects 3𝑓 + 1 reports for epoch 𝑡, or the local collection timer 𝑇𝑖𝑡 expires after receiving at least 2𝑓 + 1 reports, it locally constructs a 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 by assembling the collected reports, without any need to forward reports to a designated aggregator (Lines 7-11). Any honest leader can immediately embed its locally available 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 into a proposal upon obtaining a proposal opportunity under the round-robin scheme. The 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 is then piggybacked onto the next proposal in Autobahn’s consensus layer. Once the proposal is committed, all correct replicas obtain the same certified aggregation of reports, denoted as 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 (Lines 12–19). Once the 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 is obtained, each node deterministically extracts global states and rewards from the set of reports. Specifically, AutoPilot applies different aggregation strategies to different observations for robustness. For lane growth rates, AutoPilot uses max aggregation to reconstruct the most up-to-date lane progression. For 𝑓 𝑎𝑠𝑡 𝑝𝑎𝑡ℎ 𝑟𝑎𝑡𝑖𝑜𝑠 and rewards, AutoPilot adopts median aggregation to tolerate Byzantine outliers. The aggregated observations constitute a globally consistent 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 , including 𝐺𝑙𝑜𝑏𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑡 and 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑡 for epoch 𝑡 (Lines 20–28).

6.1

Proof Sketch

6.1.1 Liveness There exists an epoch 𝑡, at which every honest learning agent is guaranteed to invoke its learning process. Step 1: Report Collection Progress. Under the partial synchrony model, there exists a GST after which all messages sent by honest replicas are delivered within a bounded delay Δ. Each honest replica broadcasts a 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡 once per epoch upon reaching the block execution threshold 𝑗. A replica constructs an 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡 upon either of the following two conditions: (i) it receives 3𝑓 + 1 local reports; or (ii) timer 𝑇𝑖𝑡 expires after a duration exceeding Δ. In case (ii), the partial synchrony assumption guarantees that all messages from honest replicas have been delivered, ensuring that at least 2𝑓 + 1 honest reports are included in the received set. Therefore, every honest replica eventually constructs a valid 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 . Step 2: Certification of Aggregated Reports. The epoch 𝑡 becomes learnable only after the 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 is certified via the consensus as the 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 . The main challenge is that Byzantine leaders may intentionally omit 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 from their proposals. Since Autobahn’s linear BFT consensus employs round-robin leader rotation and there are at most 𝑓 Byzantine replicas, within

Algorithm 1 Learning Coordination Protocol 1: State: epoch 𝑡 , node id 𝑖

⊲ Phase 1: Local Observation 2: Upon executed slots at node 𝑖 reach observation threshold 𝑗 3: 𝐿𝑜𝑐𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑖 ← ComputeState(𝑙𝑜𝑐𝑎𝑙 𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛 𝑙𝑜𝑔𝑠 ) 4: 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑖 ← ComputeReward(𝑙𝑜𝑐𝑎𝑙 𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛 𝑙𝑜𝑔𝑠 ) 5: broadcast 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡 (𝑡, 𝑖, 𝐿𝑜𝑐𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑖 , 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑖 ) 6: start local timer 𝑇𝑖

⊲ Phase 2: Local Report Collection // Each node independently assembles reports. 7: Upon receive 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡 (𝑡, 𝑗, 𝐿𝑜𝑐𝑎𝑙𝑆𝑡𝑎𝑡𝑒 𝑗 , 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑 𝑗 ) 8: if 𝑡 matches current epoch then 9: store report into buffer 𝑅𝑒𝑝𝑜𝑟𝑡𝑠𝑖𝑡 10: Upon |𝑅𝑒𝑝𝑜𝑟𝑡𝑠𝑖𝑡 | ≥ 3𝑓 + 1 or (𝑇𝑖 expires and |𝑅𝑒𝑝𝑜𝑟𝑡𝑠𝑖𝑡 | ≥ 2𝑓 + 1) 11: 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 ← AssembleReports(𝑅𝑒𝑝𝑜𝑟𝑡𝑠𝑖𝑡 )

⊲ Phase 3: Consensus Piggybacking // Disseminate and persist Aggregated Report 12: Upon node 𝑖 becomes proposer in Autobahn consensus 13: if 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 exists and is not yet committed then 14: Embed 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 into proposal 𝐵 15: Execute existing Autobahn linear consensus 16: Upon proposal 𝐵 committed 17: if 𝐵 contains 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 then 18: 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 ← 𝐵.𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 19: Garbage collect local 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 ⊲ Phase 4: Robust Extraction // Feature-specific aggregation 20: Upon 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 obtained (𝑖 ) 21: Extract {𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑖 }, {𝑟 𝑗 }, and { 𝑓 𝑎𝑠𝑡 _𝑝𝑎𝑡ℎ_𝑟𝑎𝑡𝑖𝑜𝑖 } 22: 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑡 ← Median( {𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑖 } ) 23: for each validator  lane 𝑗 do  (1) (2) (𝑛) 24: 𝑟ˆ𝑗 ← max 𝑟 𝑗 , 𝑟 𝑗 , . . . , 𝑟 𝑗 25: 26: 27: 28: 29:

R̂ = [𝑟ˆ1 , 𝑟ˆ2 , . . . , 𝑟ˆ𝑛 ] 𝐺𝑙𝑜𝑏𝑎𝑙𝐹𝑎𝑠𝑡𝑃𝑎𝑡ℎ𝑅𝑎𝑡𝑖𝑜𝑡 ← Median( { 𝑓 𝑎𝑠𝑡 _𝑝𝑎𝑡ℎ_𝑟𝑎𝑡𝑖𝑜𝑖 } ) 𝐺𝑙𝑜𝑏𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑡 = { R̂𝑡 , 𝐺𝑙𝑜𝑏𝑎𝑙𝐹𝑎𝑠𝑡𝑃𝑎𝑡ℎ𝑅𝑎𝑡𝑖𝑜𝑡 } 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 ← (𝐺𝑙𝑜𝑏𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑡 , 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑡 ) Export (𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 to the learning agent

at most 𝑓 + 1 consecutive views, there eventually exists an honest leader. Honest replicas hold all received reports locally until certification and never discard a valid 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 due to failed proposals, view changes, or leader replacement. Consequently, once an honest replica becomes the leader, it eventually includes 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 into a proposal block. By the liveness property of the underlying linear BFT consensus under partial synchrony, the proposal carrying a 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡 will eventually be committed, thereby producing a certified coordination state 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 . Step 3: Learning Invocation. Since 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 is derived from the committed block, the liveness of Autobahn’s underlying BFT consensus guarantees that every honest replica eventually receives and processes the same 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 . As a result, every honest learning agent eventually derives the same 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡𝑡 and invokes the learning process at the same epoch 𝑡.

6.1.2 Safety. Since each 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 is embedded in the consensus messages of Autobahn’s linear BFT protocol, the coordination protocol inherits the same safety guarantees. Consequently, all honest replicas derive the same 𝐶𝑒𝑟𝑡𝑖 𝑓 𝑖𝑒𝑑𝑅𝑒𝑝𝑜𝑟𝑡𝑡 for epoch 𝑡. Given the same certified input, deterministic aggregation produces identical 𝐺𝑙𝑜𝑏𝑎𝑙𝑆𝑡𝑎𝑡𝑒𝑡 and 𝐺𝑙𝑜𝑏𝑎𝑙𝑅𝑒𝑤𝑎𝑟𝑑𝑡 values at every honest replica. 6.1.3 Robustness. We prove here that the aggregated training data obtained by each learning agent is authentic and accurate despite the polluted reports from up to 𝑓 Byzantine nodes. First, we show that the max-based aggregation mechanism used to reconstruct lane structure correctly captures the newest progress achieved by honest replicas (Lemma 1). Second, we show that the aggregation mechanism used for other metrics (𝑓 𝑎𝑠𝑡 𝑝𝑎𝑡ℎ 𝑟𝑎𝑡𝑖𝑜 and reward) is robust to Byzantine behaviors: even when up to 𝑓 nodes report arbitrary values, median-based aggregation ensures that the resulting fast path ratio and reward remain within the range of honest inputs (Lemma 2). Together, these results guarantee that both states and reward signals used for learning accurately and honestly reflect the system condition, despite Byzantine interference. Lemma 1. Under max aggregation, the globally aggregated lane growth-rate is guaranteed to accurately reflect the true lane progress. Proof. Lane progression in Autobahn is cryptographically verifiable since every committed block must carry a valid Proof of Availability (PoA). Therefore, Byzantine replicas cannot over-report nonexistent lane progress because they are unable to forge valid certificates or signatures. A malicious replica may only under-report its locally observed lane progress by omitting valid committed blocks. The globally aggregated lane growth rate is defined as: 𝑟ˆ𝑗 =

max 𝑟 ∈𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡

𝑟 [ 𝑗].

(4)

Since Autobahn enforces in-order voting and requires at least 𝑓 + 1 votes before extending a lane (i.e., proposing a new CAR), at least one honest replica must possess the latest valid committed history for every lane. Moreover, under the partial synchrony assumption, there exists a bounded message delay Δ after GST such that all messages sent by honest replicas are delivered within Δ. During report collection, each replica starts a local collection timer after broadcasting its 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑝𝑜𝑟𝑡, which is configured to exceed the bounded network delay after GST. Therefore, by waiting for either all 3𝑓 + 1 reports or timeout expiration, every honest replica eventually collects all reports sent by honest nodes. In other words, there exists at least one honest report 𝑟 ★ ∈ 𝑅𝑒𝑝𝑜𝑟𝑡𝑠 𝑡 such that: 𝑟 ★ [ 𝑗] = 𝑟 𝑡𝑟𝑢𝑒 , 𝑗

(5)

where 𝑟 𝑡𝑟𝑢𝑒 denotes the true lane growth rate of validator lane 𝑗. 𝑗 Since Byzantine replicas can only under-report but cannot fabricate larger valid lane progress values, no report can exceed the true committed growth rate. Consequently, 𝑟ˆ𝑗 =

max 𝑟 ∈𝑅𝑒𝑝𝑜𝑟𝑡𝑠 𝑡

𝑟 [ 𝑗] = 𝑟 𝑡𝑟𝑢𝑒 . 𝑗

(6)

Therefore, the lane growth-rate vector produced by max aggregation strategy accurately captures the latest lane progress despite the presence of up to 𝑓 Byzantine replicas.

Lemma 2. Under median aggregation, if all honest 𝑓 𝑎𝑠𝑡 𝑝𝑎𝑡ℎ 𝑟𝑎𝑡𝑖𝑜/ reward values form a range [𝑟𝑎𝑛𝑔𝑒𝑙 , 𝑟𝑎𝑛𝑔𝑒ℎ ], then the global taken aggregated value is also guaranteed to always fall into this range. Proof. Byzantine replicas arbitrarily report extremely large or small values on 𝑓 𝑎𝑠𝑡 𝑝𝑎𝑡ℎ 𝑟𝑎𝑡𝑖𝑜 or reward values. Let 𝑅 denote the set of reports in 𝑅𝑒𝑝𝑜𝑟𝑡𝑆𝑒𝑡𝑡 , where |𝑅| ≥ 2𝑓 + 1, and at most 𝑓 values may be arbitrarily manipulated by Byzantine replicas. Let median(𝑅) denote the lower median of 𝑅, i.e., the ⌈|𝑅|/2⌉-th smallest element. We assume all honest values lie within the interval [𝑟𝑎𝑛𝑔𝑒𝑙 , 𝑟𝑎𝑛𝑔𝑒ℎ ], and that honest replicas always report valid (non-null, non-zero) values. Suppose the median value 𝑟𝑚 satisfies 𝑟𝑚 > 𝑟𝑎𝑛𝑔𝑒ℎ . Then at least ⌈|𝑅|/2⌉ elements in 𝑅 must be strictly greater than 𝑟𝑚 . However, since |𝑅| ≥ 2𝑓 + 1 and follows that ⌈|𝑅|/2⌉ > 𝑓 , at most 𝑓 Byzantine replicas alone to contribute 𝑓 +1 such values. This implies that at least one honest value must exceed [𝑟𝑎𝑛𝑔𝑒ℎ ], contradicting the assumption that all honest values lie within [𝑟𝑎𝑛𝑔𝑒𝑙 , 𝑟𝑎𝑛𝑔𝑒ℎ ]. A symmetric argument shows that 𝑟𝑚 ≥ 𝑟𝑎𝑛𝑔𝑒𝑙 . Therefore, the median is guaranteed to lie within the range of honest observations.

7

EVALUATION

Our evaluation aims to answer the following questions: (1) Can AutoPilot converge to the optimal configuration under a static scenario without pre-training? (Section 7.2) (2) How effectively does AutoPilot adapt to dynamically changing environment, compared with the optimal static configuration and default configuration? (Section 7.3) (3) How robust is AutoPilot against adversarial data pollution, and how much does its robust learning coordination protocol improve performance? (Section 7.4) (4) What overhead does AutoPilot introduce? (Section 7.5 ) In the rest of this section, we present the experimental setup and then answer each of the above questions.

7.1

Experimental Setup

Implementation. We have implemented a prototype of AutoPilot with Rust and Python, starting from the open source implementation of Autobahn[2]. It uses Tokio TCP[12] for networking, RocksDB [7] for persistent storage, and ed25519-dalek[4] signatures for authentication. On each node, AutoPilot runs three independent processes: a Rust-based consensus protocol, a Python metrics collector that periodically parses execution logs to compute runtime states and rewards, and a Python controller that hosts the online learning agent. Each consensus process communicates with its colocated Python processes through Unix domain socket channels. Our implementation is publicly available1 . Testbed. Our testbed consists of Google Cloud Platform (GCP) t2d-standard-4 instances equipped with 4 vCPUs, 16 GB of memory, and 10 Gbps network bandwidth. Our experiments are conducted with 𝑛 = 4 replicas, where one replica is deployed in asia-east2-a, one replica is deployed in us-central1-c, and the remaining two replicas are deployed in us-central1-f. Each replica is co-located with a client process that continuously submits no-op transactions consisting of 512 random bytes. Unless otherwise stated, clients generate transactions at a constant arrival rate throughout the experiments. All reported latency measurements correspond to end-to-end commit latency observed by clients. 1 https://github.com/ccclr/AutoPilot

1750

1200

1500

1000 AutoPilot Random Default Config Optimal Fixed Config

800 600

1000 750 500

200

250 0

30

60

Epoch

90

120

150

3000

1250

400 0

3500

Latency (ms)

2000

1400

Latency (ms)

Latency (ms)

1600

0

30

60

(a) Scenario 𝑆 1

Epoch

90

120

2000 1500 AutoPilot Random Default Config Optimal Fixed Config

1000

AutoPilot Random Default Config Optimal Fixed Config

0

2500

500 0

150

0

30

(b) Scenario 𝑆 2

60

Epoch

90

120

150

(c) Scenario 𝑆 3

Figure 3: Convergence of AutoPilot in three static scenarios. Each plot shows the performance of AutoPilot, the default configuration, random policy and the optimal fixed configuration for that scenario. While the optimal parameter configuration differs for each scenario, AutoPilot always reaches near-optimal performance. AutoPilot

S1

4000

Default

S2

Random (Average)

Global Optimal Config

S3

S4

Local Optimal Config

S5

S6

3500

Latency (ms)

3000 2500 2000 1500 1000 500 0

60

120

180

Time (min)

240

300

360

Figure 4: Adaptivity of AutoPilot under changing conditions. The vertical dashed lines indicate when environments change. Table 4: Static scenarios Scenario

Workload

Message Delay

S1 (Normal case) S2 (Imbalanced workload) S3 (Degraded network)

Uniform One node at 1/100 tx rate Uniform

None None 550 ms / 750 ms

7.2

Convergence under Static Conditions

Our first set of experiments evaluates whether AutoPilot can automatically converge to the optimal protocol configuration under different static scenarios, without relying on any prior training data. We pick three representative scenarios as illustrated in Table 4, each of which is associated with a different optimal configuration. In Scenario 𝑆 1 , all nodes receive transactions at the same arrival rate and no additional consensus message delay is injected. This setting represents a stable deployment environment. In Scenario 𝑆 2 , one node receives transactions at only 1/100 of the arrival rate of the remaining nodes, while no additional network delay is injected. This setting simulates workload imbalance and hotspot-style traffic distributions commonly observed in realistic deployments. In Scenario 𝑆 3 , all nodes receive transactions at the same arrival rate, while additional consensus message delays are injected into two

nodes (550 ms and 750 ms, respectively). This setting represents degraded network conditions arising from either network fluctuation or intentional delay by Byzantine nodes. For each scenario, we run AutoPilot for 160 epochs on a WAN and compare it against three baselines: (1) the optimal fixed configuration obtained via offline search, (2) a policy that randomly selects configurations, and (3) the default configuration used by Autobahn. Figure 3 illustrates the convergence behavior of AutoPilot under different scenarios by plotting the latency throughout online training. Each plotted point represents the average latency over the most recent 20 epochs. Despite starting without any pre-training or prior knowledge, AutoPilot consistently converges towards optimal parameter configurations across all scenarios. In our evaluation, convergence is defined as the point where the moving-average latency over the most recent 20 epochs remains consistently close to the best static configuration for multiple consecutive epochs. Under this definition, AutoPilot converges substantially earlier than exhaustive exploration across all scenarios. In 𝑆 1 , AutoPilot reaches stable near-optimal performance after approximately 60 epochs (about 12 minutes). In 𝑆 2 , convergence occurs after approximately 90 epochs and requires about 28 minutes due to the larger execution latency introduced by severe workload skew. In 𝑆 3 , AutoPilot

converges after approximately 60 epochs, yet the convergence time remains around 25 minutes because injected network delays increase the duration of each learning epoch to roughly 14 seconds. In the early stages, the bootstrap datasets constructed from limited experience differ substantially from one another, producing high predictive variance across configurations. This uncertainty drives exploration, but once a configuration demonstrates consistently high reward, its estimated reward remains high in the bootstrap samples that include it, causing Thompson Sampling to select it more frequently than unknown configurations. As a result, AutoPilot gradually concentrates on promising configurations rather than distributing equal budget across the entire action space as exhaustive searching or random selecting would. As experience accumulates, bootstrap variance decreases and predictions stabilize, shifting the agent toward exploitation of the best-identified configuration. Consequently, AutoPilot reaches near-optimal performance after evaluating only a fraction of the action space. Consequently, compared with random configuration selection, AutoPilot significantly reduces the average latency throughout execution.

7.3

1600 1400

Latency (ms)

1000 800 600 400 200 0

0

20

40

60

80

Iteration

100

120

140

(a) Data Pollution Strategy A 3000

Latency (ms)

2500

AutoPilot-Robust (polluted) AutoPilot-Mean (polluted) AutoPilot-Robust (clean) Optimal Fixed Arm

2000 1500 1000 500 0

0

20

40

60

80

Iteration

100

120

140

(b) Data Pollution Strategy B

Adaptivity under Changing Conditions

We next evaluate AutoPilot under continuously changing deployment conditions. To emulate a changing environment, we run Scenarios 𝑆 1 –𝑆 3 sequentially for 60 minutes each in a round-robin manner, and repeat the sequence after Scenario 𝑆 3 . We compare AutoPilot against four baselines: (1) the locally optimal fixed configuration for each individual scenario; (2) the globally optimal fixed configuration, selected as the configuration with the highest average performance across all three scenarios; (3) a random exploration policy; and (4) the default configuration used by Autobahn. Figure 4 shows the latency averaged over a sliding window of the most recent 20 epochs throughout the 6-hour experiment. As deployment conditions change, AutoPilot consistently adapts its configuration and converges toward the best-performing policy for the current environment. Overall, AutoPilot achieves a 13.2% reduction in average end-to-end latency compared with the fixed global optimal configuration, a 49.8% reduction compared with Autobahn’s default configuration, and a 73.3% reduction compared with the random exploration policy. These results demonstrate two important advantages of AutoPilot. First, AutoPilot not only outperforms both globally fixed configurations and Autobahn’s default policy, but also eliminates the need for expensive offline data collection and pre-training prior to deployment. Second, AutoPilot demonstrates strong adaptability across fundamentally different operating conditions, including workload heterogeneity (Scenario 𝑆 2 ) and faulty network environments with intentional delay injection (Scenario 𝑆 3 ). In particular, under highly heterogeneous workloads, AutoPilot achieves up to 44.9% lower latency compared to the best global fixed configuration. Conducting an exhaustive offline grid search to identify the optimal configuration is expensive since it requires evaluating a large number of candidate configurations under each deployment condition. In the worst case, the search procedure must explore nearly the entire action space before identifying the optimal configuration, resulting in a performance similar to random exploration. Compared with AutoPilot, the random exploration policy incurs significantly

AutoPilot-Robust (polluted) AutoPilot-Mean (polluted) AutoPilot-Robust (clean) Optimal Fixed Arm

1200

Figure 5: Robustness of AutoPilot against data pollution higher average latency across all scenarios: 129.4% higher in 𝑆 1 , 57.3% higher in 𝑆 2 , and 50.3% higher in 𝑆 3 . To balance exploration and exploitation, we limit the experience set to the most recent 180 observations. This provides sufficient data for convergence under static scenarios while reducing the impact of outdated observations, enabling AutoPilot to adapt more effectively to changing operating conditions.

7.4

Robustness of AutoPilot

We evaluate the robustness of AutoPilot’s learning coordination protocol under two adversarial data pollution strategies. The baseline aggregates observations by simply averaging all reported values. Strategy A: Random noise injection. Malicious nodes independently scale their observed states and rewards up or down randomly before reporting them to other replicas. This attack injects noisy observations into the distributed training process. Strategy B: Reward manipulation attack. Malicious nodes randomly scale their observed states as in Strategy A, but craft their reward reports through a carefully designed process. Specifically, each malicious node first estimates the honest nodes’ reward reports based on its own local observations, then sets a target aggregated reward 𝑟 ∗ to make all actions appear equally effective. Concretely, given 𝑓 malicious nodesÍand 2𝑓 Í + 1 honest nodes, the mean aggregate ℎ 𝑟 ℎ + 𝑏 𝑟𝑚 is determined by , where 𝑟ℎ and 𝑟𝑚 denote the honest 3𝑓 +1 and malicious reports respectively. Each malicious node computes Í ℎ 𝑟 ℎ using its own local reward measurement as anÍapproximation (3𝑓 +1) ·𝑟 ∗ − ℎ 𝑟ℎ for honest nodes’ reports, then sets 𝑟𝑏 = such that 𝑓 the resulting mean aggregate equals the target reward 𝑟 ∗ . As shown in Figure 5(a), the mean aggregation baseline remains partially effective under data pollution strategy A, since the injected noise does not completely destroy the relative ranking between high-performing and low-performing actions. Although the final

learned policy is suboptimal, the model can still distinguish better configurations from worse ones. However, as shown in Figure 5(b), the impact of strategy B is more severe. Once the learned reward estimates become indistinguishable, unlucky exploration may repeatedly drive the system toward poorly performing actions since the aggregated rewards still appear normal. These results also demonstrate that Byzantine attackers do not necessarily need to report extreme or obviously anomalous values to disrupt learning; instead, carefully crafted yet statistically plausible reports can be significantly more damaging. Under Strategy A, Byzantine nodes report randomly scaled states and rewards, producing values that deviate significantly from the true observations. Under Strategy B, Byzantine nodes must report a carefully crafted reward value to drive the mean aggregate toward 𝑟 ∗ : when the true reward falls below 𝑟 ∗ , the manipulated reward value must be increased beyond the true value, and vice versa. In both cases, the manipulated report values show as the statistical outliers relative to the honest majority. Since AutoPilot’s robust aggregation filters out extreme values, both the aggregated state and reward accurately reflect the true observations of the honest majority. Consequently, AutoPilot consistently converges to the optimal configuration under both attack strategies, as shown in Figure 5. Overall, AutoPilot with robust aggregation reduces runtime latency by 27.6% compared with the baseline under Strategy A, and by 281.8% under Strategy B.

7.5

Overhead of AutoPilot

Our final experiment evaluates the runtime overhead introduced by AutoPilot. Among all stages in the learning pipeline, only the coordination phase introduces additional network communication in the form of a single all-to-all Local_Report broadcast at each epoch, as illustrated in Section 6. All the remaining stages, including feature extraction, model inference, and online training, are purely local computations that do not affect inter-node communication. To evaluate the above costs, we repeat the static experiment from Section 7.2 and profile the overhead of each stage. The results are summarized in Table 5 together with the duration of an epoch. Among all stages, feature extraction contributes the largest overhead. This is expected since the learning agent continuously computes runtime execution statistics from recent protocol windows, which primarily involves runtime logging and I/O operations. Communication overhead remains consistently low across all scenarios, mainly since AutoPilot piggybacks coordination data onto Autobahn’s existing consensus pipeline and only introduces a round of broadcast overhead. Inference overhead is negligible (≈ 4 ms on average), while training overhead remains below 50 ms across all scenarios. Unlike deep neural network-based approaches, which often incur substantial online training and inference costs, AutoPilot employs lightweight random forest models with low computational overhead, making online adaptation practical for real-world deployments. Overall, the overhead introduced by AutoPilot remains modest compared with the duration of each learning epoch. Across all scenarios, the average total overhead is approximately 0.66 seconds, accounting for only 4.3% of the average epoch duration (15.05 seconds). Moreover, since AutoPilot runs asynchronously alongside

Table 5: Overhead of AutoPilot Featurization

Communication

Inference

Training

Epoch

𝑆1 𝑆2 𝑆3

0.371 ± 0.240s 0.496 ± 0.316s 0.674 ± 0.399s

0.090 ± 0.058s 0.105 ± 0.080s 0.102 ± 0.077s

0.004 ± 0.001s 0.004 ± 0.001s 0.004 ± 0.001s

0.044 ± 0.005s 0.042 ± 0.004s 0.043 ± 0.004s

6.805 ± 3.549s 15.597 ± 10.756s 22.741 ± 5.862s

Avg.

0.514 ± 0.318s

0.099 ± 0.072s

0.004 ± 0.001s

0.043 ± 0.004s

15.048 ± 6.72s

Autobahn, all stages in the pipeline are performed off the protocol’s critical path and thus introduce no blocking overhead.

8

RELATED WORK

Distributed protocol parameter tuning has attracted increasing attention due to the significant impact of system configurations on throughput and latency. Existing studies mainly focus on automatically optimizing protocol parameters using reinforcement learning or Bayesian optimization techniques. For example, Athena [65] proposes a multi-agent DRL framework for tuning permissioned blockchains such as Hyperledger Fabric [49], while Alzo [41] further extends this direction to DAG-based protocols using a hierarchical reinforcement learning framework. However, most existing works focus on coarse-grained system-level tuning and do not explore finegrained adaptation of the internal design parameters of consensus protocols under dynamic workloads and fault scenarios. At the core of AutoPilot, learning in untrusted distributed settings is made resilient against intentional data pollution via robust aggregation and agreement. Similar techniques have been explored in robust distributed learning studies [15, 23, 45, 51, 57, 85]. More generally, harnessing learning to enhance performance has been done successfully in many systems under the umbrella of machine programming [50]: indexing [63], query optimization [70, 84, 89], concurrency control [80], database tuning [79], software analysis [53], scheduling [69], transaction management in blockchains [82].

9

CONCLUSION

Existing BFT protocols lack flexibility and adaptability, leading to suboptimal performance in various scenarios. In this paper, we propose a practical reinforcement learning-based BFT system called AutoPilot, which dynamically selects the top-performing parameter configuration in real-time. AutoPilot operates without requiring offline profiling or prior data collection. Moreover, its decentralized, Byzantine fault-tolerant coordination protocol ensures that the learning process itself remains resilient to adversarial manipulation. Our extensive evaluation demonstrates that AutoPilot significantly outperforms existing solutions under various conditions, including dynamic environments and adversarial attacks. AutoPilot reduces end-to-end latency by 49.8% compared to the default protocol configuration, and outperforms random configuration exploration by 73.3%. While this paper focuses on Autobahn as the state-of-the-art DAG-based BFT protocol, the findings can be generalized to any protocol that combines a DAG-based data dissemination layer and an external leader-based consensus layer (e.g., Narwhal + HotStuff). We believe that AutoPilot establishes a compelling foundation for self-tuning distributed consensus systems, and that the integration of fine-grained learned adaptation into protocol design will become an increasingly important direction as decentralized systems scale to more complex and adversarial operating conditions.

REFERENCES [1] [2] [3] [4]

[n. d.]. Aptos. https://aptosnetwork.com/. [n. d.]. Autobahn Codebase. https://github.com/neilgiri/autobahn-artifact. [n. d.]. Avalanche. https://www.avax.network/. [n. d.]. Dalek elliptic curve cryptography. https://github.com/dalekcryptography/curve25519-dalek/tree/main/ed25519-dalek. [5] [n. d.]. Fantom. https://fantom.foundation/. [6] [n. d.]. MicrosoftCCF. https://github.com/microsoft/CCF. [7] [n. d.]. RocksDB, version 0.16.0. https://rocksdb.org/. [8] [n. d.]. Sei Giga. https://docs.sei.io/learn/sei-giga. [9] [n. d.]. Somnia. https://docs.somnia.network. [10] [n. d.]. Stable. https://docs.stable.xyz/. [11] [n. d.]. Sui. https://sui.io/. [12] [n. d.]. Tokio, version 1.5.0. https://tokio.rs/. [13] Atul Adya, William J Bolosky, Miguel Castro, Gerald Cermak, Ronnie Chaiken, John R Douceur, Jon Howell, Jacob R Lorch, Marvin Theimer, and Roger P Wattenhofer. 2002. 𝐹𝐴𝑅𝑆𝐼𝑇 𝐸 : Federated, Available, and Reliable Storage for an Incompletely Trusted Environment. In Symposium on Operating Systems Design and Implementation (OSDI). USENIX Association. [14] Shipra Agrawal and Navin Goyal. 2013. Further Optimal Regret Bounds for Thompson Sampling. In The International Conference on Artificial Intelligence and Statistics (2013) (AISTATS ’13). [15] Youssef Allouah, Rachid Guerraoui, Nirupam Gupta, Rafael Pinot, and Geovani Rizk. 2023. Robust Distributed Learning: Tight Error Bounds and Breakdown Point under Data Heterogeneity. In Conf. on Neural Information Processing Systems (NeurIPS). [16] Yair Amir, Brian Coan, Jonathan Kirsch, and John Lane. 2011. Prime: Byzantine replication under attack. Transactions on Dependable and Secure Computing 8, 4 (2011), 564–577. [17] Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. 2019. CAPER: a cross-application permissioned blockchain. Proc. of the VLDB Endowment 12, 11 (2019), 1385–1398. [18] Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. 2021. SharPer: Sharding Permissioned Blockchains Over Network Clusters. In SIGMOD Int. Conf. on Management of Data. ACM, 76–88. [19] Min An, Xuan Zhang, Jishu Wang, Qiyuan Fan, Chen Gao, Linyu Li, Cuizhen Lu, Nan Li, and Yingchen Liu. 2024. Rlchain: A drl approach for blockchain performance optimization toward iiot. IEEE Transactions on Network and Service Management 22, 2 (2024), 1629–1645. [20] Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegelman. 2025. Shoal++: High Throughput DAG BFT Can Be Fast and Robust!. In Symposium on Networked Systems Design and Implementation (NSDI). USENIX Association. [21] Amy Babay, John Schultz, Thomas Tantillo, Samuel Beckley, Eamon Jordan, Kevin Ruddell, Kevin Jordan, and Yair Amir. 2019. Deploying intrusion-tolerant SCADA for the power grid. In Int. Conf. on Dependable Systems and Networks (DSN). IEEE, 328–335. [22] Jean-Paul Bahsoun, Rachid Guerraoui, and Ali Shoker. 2015. Making BFT protocols really adaptive. In Int. Parallel and Distributed Processing Symposium. IEEE, 904–913. [23] Gilad Baruch, Moran Baruch, and Yoav Goldberg. 2019. A little is enough: Circumventing defenses for distributed learning. Advances in Neural Information Processing Systems 32 (2019). [24] Alysson Bessani, Miguel Correia, Bruno Quaresma, Fernando André, and Paulo Sousa. 2013. DepSky: dependable and secure storage in a cloud-of-clouds. Transactions on Storage (TOS) 9, 4 (2013), 12. [25] Leo Breiman. 1996. Bagging Predictors. In Machine Learning (1996) (Maching Learning ’96). [26] Leo Breiman. 2001. Random forests. Machine learning 45 (2001), 5–32. [27] Richard Gendal Brown, James Carlyle, Ian Grigg, and Mike Hearn. 2016. Corda: an introduction. R3 CEV, August 1, 15 (2016), 14. [28] Yehonatan Buchnik and Roy Friedman. 2020. FireLedger: a high throughput blockchain consensus protocol. Proceedings of the VLDB Endowment 13, 9 (2020), 1525–1539. [29] Miguel Castro and Barbara Liskov. 1999. Practical Byzantine fault tolerance. In Symposium on Operating Systems Design and Implementation (OSDI). USENIX Association, 173–186. [30] Miguel Castro and Barbara Liskov. 2002. Practical Byzantine fault tolerance and proactive recovery. Transactions on Computer Systems (TOCS) 20, 4 (2002), 398–461. [31] Jeeta Ann Chacko, Ruben Mayer, and Hans-Arno Jacobsen. 2023. How to optimize my blockchain? a multi-level recommendation approach. 1, 1 (2023), 1–27. [32] Olivier Chapelle and Lihong Li. 2011. An empirical evaluation of Thompson sampling. In Advances in neural information processing systems (2011) (NIPS’11). [33] Feng Cheng, Jiang Xiao, Cunyang Liu, Shijie Zhang, Yifan Zhou, Bo Li, Baochun Li, and Hai Jin. 2024. Shardag: Scaling dag-based blockchains via adaptive sharding. In Int. Conf. on Data Engineering (ICDE). IEEE, 2068–2081.

[34] Allen Clement, Manos Kapritsos, Sangmin Lee, Yang Wang, Lorenzo Alvisi, Mike Dahlin, and Taylor Riche. 2009. Upright cluster services. In Symposium on Operating Systems Principles (SOSP). ACM, 277–290. [35] Allen Clement, Edmund L Wong, Lorenzo Alvisi, Michael Dahlin, and Mirco Marchetti. 2009. Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults.. In Symposium on Networked Systems Design and Implementation (NSDI), Vol. 9. USENIX Association, 153–168. [36] Xiaohai Dai, Wei Li, Guanxiong Wang, Jiang Xiao, Haoyang Chen, Shufei Li, Albert Y Zomaya, and Hai Jin. 2024. Remora: A low-latency dag-based bft through optimistic paths. Transactions on Computers (2024). [37] Xiaohai Dai, Guanxiong Wang, Jiang Xiao, Zhengxuan Guo, Rui Hao, Xia Xie, and Hai Jin. 2024. LightDAG: A low-latency DAG-based BFT consensus through lightweight broadcast. In Int. Parallel and Distributed Processing Symposium (IPDPS). IEEE, 998–1008. [38] Xiaohai Dai, Zhaonan Zhang, Zhengxuan Guo, Chaozheng Ding, Jiang Xiao, Xia Xie, Rui Hao, and Hai Jin. 2024. Wahoo: A dag-based bft consensus with low latency and low communication overhead. Transactions on Information Forensics and Security (2024). [39] Xiaohai Dai, Zhaonan Zhang, Jiang Xiao, Jingtao Yue, Xia Xie, and Hai Jin. 2023. GradedDAG: An asynchronous DAG-based BFT consensus with lower latency. In Int. Symposium on Reliable Distributed Systems (SRDS). IEEE, 107–117. [40] George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2022. Narwhal and Tusk: a DAG-based mempool and efficient BFT consensus. In European Conf. on Computer Systems (EuroSys). 34–50. [41] Qiuyu Ding, Rongkai Zhang, Qinnan Zhang, Zhen Xiao, Jieyi Long, Mingchao Wan, Sen Liu, and Jin Dong. 2026. Alzo: Auto-Tuning with Reinforcement Learning for DAG-based Blockchains. In Proceedings of the ACM Web Conference 2026. 5474–5483. [42] Dan Dobre, Ghassan Karame, Wenting Li, Matthias Majuntke, Neeraj Suri, and Marko Vukolić. 2013. PoWerStore: Proofs of writing for efficient and robust storage. In Conf. on Computer and communications security (CCS). ACM, 285–298. [43] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988. Consensus in the presence of partial synchrony. Journal of the ACM (JACM) 35, 2 (1988), 288–323. [44] facebookresearch. 2026. Narwhal. https://github.com/facebookresearch/narwhal. Public code repository for Narwhal and Tusk. [45] Sadegh Farhadkhani, Rachid Guerraoui, Nirupam Gupta, Rafael Pinot, and John Stephan. 2022. Byzantine machine learning made easy by resilient averaging of momentums. In Int. Conf. on Machine Learning (ICML). PMLR, 6246–6283. [46] Miguel Garcia, Nuno Neves, and Alysson Bessani. 2016. SieveQ: A layered bft protection system for critical services. IEEE Transactions on Dependable and Secure Computing 15, 3 (2016), 511–525. [47] Neil Giridharan, Florian Suri-Payer, Ittai Abraham, Lorenzo Alvisi, and Natacha Crooks. 2024. Autobahn: Seamless high speed BFT. In Symposium on Operating Systems Principles (SOSP). ACM SIGOPS, 1–23. [48] Garth R Goodson, Jay J Wylie, Gregory R Ganger, and Michael K Reiter. 2004. Efficient Byzantine-tolerant erasure-coded storage. In Int. Conf. on Dependable Systems and Networks (DSN). IEEE, 135–144. [49] Christian Gorenflo, Stephen Lee, Lukasz Golab, and Srinivasan Keshav. 2019. Fastfabric: Scaling hyperledger fabric to 20,000 transactions per second. In Int. Conf. on Blockchain and Cryptocurrency (ICBC). IEEE, 455–463. [50] Justin Gottschlich, Armando Solar-Lezama, Nesime Tatbul, Michael Carbin, Martin Rinard, Regina Barzilay, Saman Amarasinghe, Joshua B. Tenenbaum, and Tim Mattson. 2018. The three pillars of machine programming. In Proceedings of the 2nd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages (Philadelphia, PA, USA, 2018-06-18) (MAPL 2018). Association for Computing Machinery, 69–80. doi:10.1145/3211346.3211355 [51] Rachid Guerraoui, Sébastien Rouault, et al. 2018. The hidden vulnerability of distributed learning in byzantium. In Int. Conf. on Machine Learning (ICML). PMLR, 3521–3530. [52] Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael K Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. 2019. SBFT: a Scalable Decentralized Trust Infrastructure for Blockchains. In Int. Conf. on Dependable Systems and Networks (DSN). IEEE/IFIP, 568–580. [53] Niranjan Hasabnis and Justin Gottschlich. 2021. ControlFlag: a self-supervised idiosyncratic pattern detection system for software control structures. In Proceedings of the 5th ACM SIGPLAN International Symposium on Machine Programming (New York, NY, USA, 2021-06-20) (MAPS ’21). Association for Computing Machinery, 32–42. doi:10.1145/3460945.3464954 [54] HyperLedger. 2019. https://github.com/hyperledger/ursa. [55] Dakai Kang, Junchao Chen, Tien Tuan Anh Dinh, and Mohammad Sadoghi. 2025. FairDAG: consensus fairness over multi-proposer causal design. Proceedings of the VLDB Endowment 19, 2 (2025), 265–278. [56] Dakai Kang, Suyash Gupta, Dahlia Malkhi, and Mohammad Sadoghi. 2025. Hotstuff-1: Linear consensus with one-phase speculation. Proceedings of the ACM on Management of Data 3, 3 (2025), 1–29. [57] Sai Praneeth Karimireddy, Lie He, and Martin Jaggi. 2021. Learning from history for byzantine robust optimization. In Int. Conf. on Machine Learning (ICML). PMLR, 5311–5319.

[58] Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman. 2021. All you need is dag. In Symposium on Principles of Distributed Computing (PODC). ACM, 165–175. [59] Roger M. Kieckhafer and Mohammad H. Azadmanesh. 1994. Reaching approximate agreement with mixed-mode faults. Transactions on Parallel and Distributed Systems 5, 1 (1994), 53–63. [60] Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. 2016. Enhancing bitcoin security and performance with strong consistency via collective signing. In Security Symposium. USENIX Association, 279–296. [61] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford. 2018. Omniledger: A secure, scale-out, decentralized ledger via sharding. In Symposium on Security and Privacy (SP). IEEE, 583–598. [62] Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. 2007. Zyzzyva: speculative byzantine fault tolerance. Operating Systems Review (OSR) 41, 6 (2007), 45–58. [63] Tim Kraska, Alex Beutel, Ed H. Chi, Jeffrey Dean, and Neoklis Polyzotis. 2018. The Case for Learned Index Structures. In Proceedings of the 2018 International Conference on Management of Data (New York, NY, USA, 2018) (SIGMOD ’18). ACM. doi:10.1145/3183713.3196909 [64] Binhong Li, Licheng Lin, Shijie Zhang, Jianliang Xu, Jiang Xiao, Bo Li, and Hai Jin. 2025. FlexIM: efficient and verifiable index management in Blockchain. IEEE Transactions on Knowledge and Data Engineering (2025). [65] Mingxuan Li, Yazhe Wang, Shuai Ma, Chao Liu, Dongdong Huo, Yu Wang, and Zhen Xu. 2023. Auto-tuning with reinforcement learning for permissioned blockchain systems. Proceedings of the VLDB Endowment 16, 5 (2023), 1000–1012. [66] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. 2016. A secure sharding protocol for open blockchains. In SIGSAC Conf. on Computer and Communications Security (CCS). ACM, 17–30. [67] Dahlia Malkhi and Michael K Reiter. 1998. Secure and scalable replication in Phalanx. In Symposium on Reliable Distributed Systems (SRDS). IEEE, 51–58. [68] Dahlia Malkhi, Chrysoula Stathakopoulou, and Maofan Yin. 2024. BBCA-CHAIN: Low latency, high throughput BFT consensus on a DAG. In Int. Conf. on Financial Cryptography and Data Security (FC). Springer, 51–73. [69] Hongzi Mao, Malte Schwarzkopf, Shaileshh Bojja Venkatakrishnan, Zili Meng, and Mohammad Alizadeh. 2018. Learning Scheduling Algorithms for Data Processing Clusters. (2018). arXiv:1810.01963 http://arxiv.org/abs/1810.01963 [70] Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Alizadeh, and Tim Kraska. 2021. Bao: Making Learned Query Optimization Practical. In Proceedings of the 2021 International Conference on Management of Data (China, 2021-06) (SIGMOD ’21). doi:10.1145/3448016.3452838 Award: ’best paper award’. [71] Heena Nagda, Sidharth Sankhe, Sakshi Sinha, Keon Attarha, Mohammad Javad Amiri, and Boon Thau Loo. 2026. DAG of DAGs: Order-Fairness Made Practical. In SIGMOD Int. Conf. on Management of Data. ACM. [72] Ian Osband and Benjamin Van Roy. 2015. Bootstrapped Thompson Sampling and Deep Exploration. (2015). http://arxiv.org/abs/1507.00300 [73] Apache ResilientDB. [n. d.]. Global-Scale Sustainable Blockchain Fabric. https://resilientdb.incubator.apache.org/. ([n. d.]). [74] Tom Roeder and Fred B Schneider. 2010. Proactive obfuscation. ACM Transactions on Computer Systems (TOCS) 28, 2 (2010), 1–54.

[75] Nibesh Shrestha, Rohan Shrothrium, Aniket Kate, and Kartik Nayak. 2024. Sailfish: Towards Improving the Latency of DAG-based BFT. In Symposium on Security and Privacy (SP). IEEE, 21–21. [76] Paulo Sousa, Alysson Neves Bessani, Miguel Correia, Nuno Ferreira Neves, and Paulo Verissimo. 2009. Highly available intrusion-tolerant services with proactive-reactive recovery. IEEE Transactions on Parallel and Distributed Systems 21, 4 (2009), 452–465. [77] Alexander Spiegelman, Balaji Arun, Rati Gelashvili, and Zekun Li. 2024. Shoal: Improving dag-bft latency and robustness. In Int. Conf. on Financial Cryptography and Data Security (FC). Springer, 92–109. [78] Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris KokorisKogias. 2022. Bullshark: Dag bft protocols made practical. In ACM SIGSAC Conf. on Computer and Communications Security (CCS). 2705–2718. [79] Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, and Bohan Zhang. 2017. Automatic Database Management System Tuning Through Large-scale Machine Learning. In Proceedings of the 2017 ACM International Conference on Management of Data (New York, NY, USA, 2017) (SIGMOD ’17). ACM, 1009–1024. doi:10.1145/ 3035918.3064029 [80] Jiachen Wang, Ding Ding, Huan Wang, Conrad Christensen, Zhaoguo Wang, Haibo Chen, and Jinyang Li. 2021. Polyjuice: {High-Performance} Transactions via Learned Concurrency Control (OSDI ’21). 198–216. https://www.usenix.org/ conference/osdi21/presentation/wang-jiachen [81] Chenyuan Wu, Mohammad Javad Amiri, Haoyun Qin, Bhavana Mehta, Ryan Marcus, and Boon Thau Loo. 2024. Towards Full Stack Adaptivity in Permissioned Blockchains. Proc. of the VLDB Endowment 17, 5 (2024), 1073–1080. [82] Chenyuan Wu, Bhavana Mehta, Mohammad Javad Amiri, Ryan Marcus, and Boon Thau Loo. 2023. AdaChain: A Learned Adaptive Blockchain. Proc. of the VLDB Endowment 16, 8 (2023), 2033–2046. [83] Chenyuan Wu, Haoyun Qin, Mohammad Javad Amiri, Boon Thau Loo, Dahlia Malkhi, and Ryan Marcus. 2025. { BFTBrain } : Adaptive { BFT } Consensus with Reinforcement Learning. In 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25). 1563–1583. [84] Zongheng Yang, Wei-Lin Chiang, Sifei Luan, Gautam Mittal, Michael Luo, and Ion Stoica. 2022. Balsa: Learning a Query Optimizer Without Expert Demonstrations. In Proceedings of the 2022 International Conference on Management of Data (New York, NY, USA, 2022-06-10) (SIGMOD ’22). Association for Computing Machinery, 931–944. doi:10.1145/3514221.3517885 [85] Dong Yin, Yudong Chen, Ramchandran Kannan, and Peter Bartlett. 2018. Byzantine-robust distributed learning: Towards optimal statistical rates. In Int. Confe. on Machine Learning (ICML). 5650–5659. [86] Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abraham. 2019. HotStuff: BFT consensus with linearity and responsiveness. In Symposium on Principles of Distributed Computing (PODC). ACM, 347–356. [87] Li Zhou. 2016. A Survey on Contextual Multi-armed Bandits. (2016). http: //arxiv.org/abs/1508.03326 [88] Lidong Zhou, Fred B Schneider, and Robbert Van Renesse. 2002. COCA: A secure distributed online certification authority. ACM Transactions on Computer Systems (TOCS) 20, 4 (2002), 329–368. [89] Rong Zhu, Wei Chen, Bolin Ding, Xingguang Chen, Andreas Pfadler, Ziniu Wu, and Jingren Zhou. 2023. Lero: A Learning-to-Rank Query Optimizer. 16, 6 (2023), 1466–1479. doi:10.14778/3583140.3583160