arXiv CSopen access

From Bracha to Coded MBRB: Benchmarking Byzantine Reliable Broadcast Implementations

· arxiv_cs

arXiv CS · Papers · License: Open Access

cloud distributed-computing parallel-computing

distributed computing, parallel computing, cloud

From Bracha to Coded MBRB: Benchmarking Byzantine Reliable Broadcast Implementations⋆ Yenan Wang1[0009−0004−1389−1196] , Jesper Kullberg1 , Fabian Paglianno Persson1 , Elad Michael Schiller1[0000−0003−3258−3696] , and Timothé Albouy2[0000−0001−9419−6646]

arXiv:2609.07521v1 [cs.DC] 7 Sep 2026

Chalmers University of Technology, Gothenburg, Sweden {yenan,jesperku,fabianpa,elad}@chalmers.se 2 IMDEA Software Institute, Madrid, Spain [email protected]

Abstract. Byzantine Reliable Broadcast (BRB) and Message-AdversaryTolerant Byzantine Reliable Broadcast (MBRB) are reliable-dissemination abstractions for fault-tolerant distributed systems. Yet their operational behavior is shaped not only by specifications and asymptotic communication bounds, but also by serialization, cryptography, buffering, orchestration, deployment environment, and fault-injection semantics. This paper implements and evaluates Bracha [Information and Computation, 1987], AFRT by Albouy et al. [TCS, 2023], and Coded MBRB by Albouy et al. [OPODIS, 2024]. We implement the algorithms in a shared Go codebase with common orchestration, instrumentation, parser-based specification checks, fault injection, and an open-source reproducibility artifact. The evaluation uses single-shot broadcasts in the Shadow network simulator, native profiling, a Google Cloud Platform deployment, and a distributed FABRIC testbed, covering controlled experiments up to 30 nodes, payloads up to 40 MB, 92,190 runs, and 2,361,600 parser-checked entries. The results show that Coded MBRB reduces transmitted data and improves latency in the evaluated cloud setting for larger payloads, but shifts cost to cryptographic and coding computation. Bracha and AFRT incur lower CPU costs at smaller payloads, but their full-payload dissemination increases processing, allocation, and network costs as payloads grow. Across the tested configurations, the parser found no duplicate deliveries, conflicting deliveries, or deliveries of values different from the sender’s payload. The paper contributes implementation-level evidence and an extensible artifact for benchmarking BRB and MBRB as executable distributed-system components, exposing bottlenecks and operational trade-offs that are hidden by algorithmic descriptions alone. Keywords: Byzantine reliable broadcast · Message-adversary · Benchmarking and Empirical Evaluation · Reproducible systems research. ⋆

This technical report complements the conference version of this work, which will appear in the proceedings of SSS 2026.

Y. Wang et al.

Introduction

Reliable broadcast (RB) is a fundamental communication abstraction at the center of many fault-tolerant distributed systems. RB lets a designated sender disseminate an application value m so that correct (non-faulty) nodes deliver at most one common value; and if the sender is correct, all correct nodes deliver m. RB plays a crucial role in many practical applications, such as event notification, state machine replication [1], or asset transfer [6,18]. Fault tolerance comes in multiple flavors: if faulty nodes can behave arbitrarily, we talk about Byzantine Reliable Broadcast (BRB); and if, in addition to Byzantine failures, a message adversary (MA) can suppress implementation messages exchanged between correct nodes, we talk about MA-Tolerant Byzantine Reliable Broadcast (MBRB). MBRB preserves safety but replaces the all-node termination of BRB with a quantified delivery-power guarantee. In an asynchronous message-passing system of n nodes, where up to t can be Byzantine and an MA that can omit up to d copies of each algorithm-generated broadcast to correct recipients, it has been shown that BRB (which assumes d = 0) can be solved if and only if n > 3t [15,34], and MBRB can be solved if and only if n > 3t + 2d [4]. Rather than proposing a new algorithm, we compare how implementations of these BRB and MBRB algorithms behave as executable systems, where software choices expose costs hidden by abstract algorithm descriptions. Algorithms and scope. We implement Bracha’s BRB [15,34], AFRT [4], and Coded MBRB [3]. Bracha is the classical BRB baseline, whereas AFRT and Coded MBRB both implement MBRB. In particular, Bracha assumes reliable channels (d = 0) and tolerates Byzantine nodes, whereas the MBRB algorithms additionally tolerate bounded omissions of implementation messages, and Coded MBRB uses erasure-coded fragments and cryptographic evidence to reduce the resulting data movement. Thus, Bracha provides a reference for the cost of adding message-adversary tolerance, while AFRT versus Coded MBRB is the direct likefor-like comparison. AFRT forwards full payloads with accumulated signatures, whereas Coded MBRB uses erasure coding and cryptographic evidence to reduce payload movement. Recent communication-efficient BRB work shows that the design space remains active [26,27,29]; we therefore treat the studied algorithms as representative implementation points focused on BRB and MBRB under Byzantine faults and message-adversary assumptions, not as exhaustive coverage of all BRB designs. Recent coded BRB algorithms address communication efficiency under the classical reliable-channel model [5,20]; our direct comparison instead focuses on AFRT and Coded MBRB, which implement the same MBRB abstraction. Our implementations support single-shot broadcast instances. This choice isolates the cost of one invocation of the broadcast primitive and avoids confounding the measurements with batching, sequence-number management, sliding windows, concurrent instances, admission control, or garbage collection across repeated broadcasts. Consequently, the paper characterizes per-broadcast com-

Reliable Broadcast Benchmarking

munication, CPU, memory, latency, and delivery behavior, but does not measure sustained throughput of a long-running dissemination service. Approach. The algorithms are implemented in a shared Go codebase as peerto-peer nodes coordinated by a centralized experiment controller [25]. The controller distributes configuration, peer lists, cryptographic material, payload size, selected algorithm, and fault-injection roles, and acts as a synchronization point for registration, readiness, execution, completion, and metric collection. Nodes use persistent pairwise TCP connections and a manager layer that records message and byte counters, timestamps delivery, routes incoming messages to the selected algorithm, and provides the common interception point for fault injection. The implementation uses established libraries for erasure coding and cryptographic operations [14,33]. The evaluation combines Shadow, which is a discrete-event network simulator, native profiling, Google Cloud Platform (GCP) deployment, and supplementary FABRIC measurements. Shadow executes the same Go binaries over a deterministic simulated topology for communication-cost and fault-injection experiments [23,24]. Native profiling measures user-space CPU instructions with Linux perf and Go runtime memory statistics. GCP provides the primary deploymentoriented latency measurements using controller-measured timing over private VPC communication, while FABRIC provides supplementary latency evidence over a more distributed infrastructure. Fault injection covers silent nodes, randomized omission of implementation messages, and one partition-based equivocatingsender scenario inspired by Twins [9]. Parser checks detect duplicate delivery, conflicting delivery, invalid delivery, and spurious delivery; these consistency tests provide implementation-level evidence, not exhaustive Byzantine testing. Findings. The experiments expose a concrete systems trade-off. In Shadow at n = 30 with a 1 MB payload, Coded MBRB transmits approximately 128 MB, whereas Bracha and AFRT transmit about 1.7 GB, giving roughly a 14× reduction in transmitted data. Under payload scaling at n = 30, Bracha and AFRT reach about 14 GB at an 8 MB payload, while Coded MBRB remains around 1 GB. This communication advantage is not free: in native profiling at n = 30 with a 1 MB payload, Coded MBRB executes about 800 million CPU instructions per node, compared with roughly 250 million for Bracha and AFRT. However, this computational disadvantage reverses at larger payloads, with Bracha overtaking Coded MBRB in CPU cost around 6 MB. Full-payload dissemination also creates substantial memory pressure: at an 8 MB payload, Bracha and AFRT exceed 800 MB peak heap per node, while Coded MBRB remains around 350 MB. In the GCP deployment at n = 5 and an 8 MB payload, Bracha and AFRT reach about 900 ms completion latency, while Coded MBRB remains below 400 ms. Across 92,190 runs and 2,361,600 parser-checked entries, the parser found no duplicate delivery, conflicting delivery, invalid delivery, or spurious delivery in the tested configurations. These results provide reproducible implementation-level evidence about selected operating regimes.

Y. Wang et al.

Our contributions. This paper contributes the following. 1. We present an implementation architecture for evaluating Bracha’s BRB, AFRT, and Coded MBRB algorithms as executable distributed systems, including reusable orchestration, transport, message-management, metriccollection, and fault-injection components. 2. We provide an open-source reproducibility artifact, including code, configurations, automation scripts, raw-output processing, parser-based consistency tests, and plotting support [25]. 3. We conduct an empirical study of Bracha’s BRB, AFRT, and Coded MBRB across simulation, native profiling, and deployments on GCP and FABRIC, characterizing communication cost, local computation, memory behavior, latency, delivery behavior, and consistency-check outcomes under controlled parameter scaling and selected injected faults. To facilitate reproducibility, our implementation and artifacts can be found in our open-source code repository [25].

Related Work

In this section, we present and expand the compact related-work positioning given in the introduction. The goal is not to provide a complete survey of reliable broadcast, but to clarify how the present implementation-driven study relates to algorithmic BRB and MBRB work, communication-efficient broadcast, implementation artifacts, larger BFT systems, and benchmarking or testing methodology. 2.1

Reliable-Broadcast Abstractions and Algorithmic Variants

Byzantine reliable broadcast originates from the need to disseminate a sender value in the presence of Byzantine behavior while preserving agreement-like delivery properties among correct processes. Bracha’s asynchronous construction established the echo/ready structure that remains a standard reference point for fully connected asynchronous systems [15]. Raynal’s treatment places Byzantine reliable broadcast among the basic communication abstractions of fault-tolerant message-passing systems and provides the formulation used as the classical baseline in this paper [34]. These works define the baseline abstraction but do not by themselves answer how executable implementations behave under concrete serialization, buffering, cryptographic, and deployment choices. Several later directions broaden the model. Dolev’s work on reliable communication in unknown and unreliable environments underlies reliable dissemination over non-complete networks [21]. Practical Byzantine reliable broadcast on partially connected networks combines Bracha-style broadcast with Dolevstyle communication and studies optimizations for graph connectivity and path diversity [12]. Other directions modify the delivery semantics or execution setting. Byzantine-tolerant causal broadcast layers causal delivery over Byzantinetolerant dissemination [7]. Set-constrained delivery broadcast constrains the sets

Reliable Broadcast Benchmarking

of values that can be delivered together [8]. Repeated and amortized broadcast work studies how repeated invocations, clients, or long-running services can change the average cost of broadcast [16,17,36,22]. These works define a broad algorithmic design space. Our study does not try to cover all reliable-broadcast abstractions, topologies, or repeated-execution variants. Instead, it uses Bracha, AFRT, and Coded MBRB as three representative points that expose different implementation regimes: classical fullpayload BRB, signature-based message-adversary-tolerant broadcast, and coded message-adversary-tolerant broadcast. Recent work on communication-efficient BRB shows that the design space remains active, including algorithms with low communication and time complexity [26], reduced cost in failed executions [27], and MiniCast-style long-message communication complexity [29]. This broader landscape motivates treating our three implementations as representative points focused on BRB and MBRB under Byzantine faults and message-adversary assumptions, rather than as exhaustive coverage of all reliable-broadcast designs. 2.2

Message-Adversary-Tolerant and Communication-Efficient Broadcast

The AFRT paper introduces message-adversary-tolerant Byzantine reliable broadcast (MBRB), where a network-level adversary may omit selected implementation messages and the abstraction is weakened from delivery by all correct processes to quantified delivery power [4]. The corresponding condition n > 3t + 2d makes both Byzantine faults and message-omission power explicit. Coded MBRB refines this line by targeting near-optimal communication under the messageadversary model, replacing repeated full-payload forwarding with erasure-coded fragments, vector commitments, and threshold signatures [3]. These two algorithms are central to our evaluation because they make a direct systems tradeoff visible: lower communication can require additional cryptographic and coding computation. We refer the interested reader to [2] for a monograph on the MBRB problem. Classical asynchronous BRB has also seen substantial progress in coded communication-efficient designs. Das, Xiang, and Ren [20] present an asynchronous data dissemination primitive that yields communication-efficient Byzantine reliable broadcast, while Alhaddad et al. [5] propose a balanced BRB protocol with near-optimal communication and improved computation. Unlike AFRT and Coded MBRB, these algorithms assume the classical reliable-channel model rather than the MBRB message-adversary model. Consequently, they complement our study rather than serving as direct algorithmic baselines for the AFRT versus Coded MBRB comparison. Beyond these coded BRB designs, recent work on communication-efficient Byzantine reliable broadcast further emphasizes that communication cost remains an active algorithmic concern. Locher’s work on low communication and time complexity studies asynchronous Byzantine reliable broadcast and reduces the overhead factor of coded reliable-broadcast designs under appropriate execution conditions [26]. Follow-up work on the failure case introduces reliable-

Y. Wang et al.

broadcast detectors and studies how to reduce communication cost when the sender fails or no value is delivered [27]. MiniCast minimizes long-message communication complexity for reliable broadcast, and later work aims to improve its round complexity [29,28]. These works are important for positioning because they show that the selected algorithms are not the final word on communication efficiency. The present paper is complementary to these algorithmic advances. We do not claim that Coded MBRB is the most communication-efficient BRB design known today, nor do we evaluate all recent low-communication BRB algorithms. Rather, we use Coded MBRB as a recent message-adversary-tolerant coded design whose implementation exposes the concrete cost of replacing full-payload dissemination with cryptographic and coding work. Adding Locher-style and MiniCast-style algorithms to the same harness is a natural next step enabled by the artifact. 2.3

Reliable-Broadcast Implementations and Artifacts

Implementation-oriented reliable-broadcast work is more limited than the algorithmic literature. Practical Byzantine reliable broadcast on partially connected networks reports a C++ implementation and evaluates optimized Bracha-Dolev combinations using a real C++ implementation and actual deployment [12]. Reliable Broadcast in Practical Networks provides a Go-based framework using Mininet to evaluate reliable-broadcast algorithms based on hashing and erasure coding [39]. These works are close in spirit to the present study because they treat reliable broadcast as executable software rather than only as pseudocode. Artifact availability also matters for MBRB. An earlier AFRT implementation is available in Rust [32], and an earlier Coded MBRB prototype was implemented in Python with Merkle-tree-based authentication structures rather than vector commitments [13]. These artifacts are useful engineering evidence, but they do not by themselves provide a common comparison framework for Bracha, AFRT, and Coded MBRB under shared orchestration, workloads, metrics, and fault-injection semantics. Our artifact is intended to narrow this implementation gap. Its contribution is not merely that three algorithms are implemented, but that they are implemented in one codebase with a common controller, persistent peer connections, manager-layer instrumentation, metric collection, parser checks, and fault-injection paths. This common infrastructure reduces confounding differences when comparing byte overhead, implementation-message count, CPU instructions, memory usage, latency, delivery behavior, and parser-checked safety outcomes. 2.4

Reliable Dissemination inside Larger BFT Systems

Reliable dissemination is also a core component of larger BFT systems. HoneyBadgerBFT uses reliable broadcast and asynchronous common subset machinery

Reliable Broadcast Benchmarking

to build practical asynchronous atomic broadcast [30]. Narwhal and Tusk separate reliable transaction dissemination from ordering, making dissemination a first-class bottleneck in high-throughput BFT system design [19]. Related DAGbased and asynchronous BFT systems similarly show that the cost of moving data reliably can dominate end-to-end system behavior even when consensus or ordering is the nominal abstraction. These systems motivate the operational importance of reliable broadcast, but they are not direct experimental baselines for this paper. They evaluate complete BFT stacks with additional batching, mempool, ordering, consensus, cryptographic, and deployment machinery. Our target is narrower: standalone BRB and MBRB implementations evaluated under common single-shot workloads so that the cost of the reliable-broadcast primitive itself is visible. 2.5

Benchmarking, Simulation, and Byzantine Testing

Systems work on BFT benchmarking and simulation provides important methodological context. BFT Protocols Under Fire showed that controlled experimentation can expose behavior not apparent from algorithm descriptions alone [35]. Later work on scalable BFT performance evaluation and simulation of unmodified BFT implementations demonstrates how network simulation can support reproducibility and larger-scale comparisons [10,11]. This methodological line motivates our use of controlled simulation for network overhead and fault injection, complemented by native profiling and deployment-oriented latency measurements. Byzantine testing tools provide a second methodological reference point. Twins generates Byzantine behaviors by duplicating identities and controlling communication partitions [9]. ByzzBench benchmarks testing algorithms for BFT implementations [31]. ByzzFuzz applies randomized testing and message perturbation to BFT implementations [38]. BFTDiagnosis studies diagnosis and security indicators for BFT systems [37]. These works support the importance of controlled adversarial testing, but their goals differ from benchmarking standalone reliable-broadcast implementations. Our fault injection is deliberately narrower than these general Byzantinetesting frameworks. Silent nodes, randomized message omissions, and a partitionbased equivocating sender are controlled experimental scenarios used to evaluate implementation behavior against expected thresholds and parser-checked safety conditions. They do not constitute an exhaustive Byzantine campaign, and they are not presented as a replacement for general-purpose BFT testing tools. 2.6

Positioning of This Work

The present paper sits between formal reliable-broadcast algorithms and fullsystem BFT benchmarking. It does not propose a new broadcast algorithm, a production-ready dissemination layer, or a complete benchmark standard. Instead, it asks how three existing algorithms behave when implemented, orchestrated, instrumented, and executed under comparable workloads and selected

Y. Wang et al.

fault-injection scenarios. This perspective exposes costs that are abstracted away in pseudocode and asymptotic bounds: serialization, cryptographic verification, erasure coding, buffering, payload copying, memory allocation, and the semantics of injected faults. This positioning also explains the algorithm selection. Bracha represents the classical asynchronous BRB baseline. AFRT represents signature-based messageadversary-tolerant broadcast. Coded MBRB represents a coded message-adversarytolerant design that targets lower communication cost. Newer communicationefficient BRB algorithms, partially connected reliable-broadcast algorithms, large BFT stacks, and general Byzantine-testing frameworks are related but not direct experimental baselines. The artifact is intended to make such future comparisons easier by preserving a shared transport, manager, configuration, metric, parser, and plotting interface.

Methodology

We define the evaluation methodology. Bracha serves as a cross-abstraction BRB reference, whereas the AFRT–Coded MBRB comparison isolates implementation differences within MBRB. The evaluation is a systems study rather than a correctness proof. It therefore focuses on controlled comparability, reproducibility, resource costs, deployment-oriented latency, and behavior under selected injected faults. The implementations support single-shot broadcasts, isolating one invocation of the reliable-broadcast primitive from sequence-number management, batching, sliding windows, concurrent-instance scheduling, and multi-shot garbage collection.

3.1

Research Questions and Experiment Mapping

The evaluation is organized around four research questions. RQ1: Communication scalability. How do the three implementations scale in transmitted data as the number of nodes and payload size increase, and how does the implementation-message count scale with the number of nodes? RQ2: Local resource cost. How do CPU instruction count and memory usage scale, and when does Coded MBRB’s cryptographic and coding cost become preferable to the full-payload processing costs of Bracha and AFRT? RQ3: Deployment latency. Do the communication savings of Coded MBRB translate into lower broadcast completion latency in deployment-oriented environments?

Reliable Broadcast Benchmarking

Table 1. Research-question to experiment mapping. RQ

Experiment

Testbed(s)

Measured quantities

Detailed evidence

RQ1

Experiment 1: Controlled Scalability and Resource Costs Experiment 1: Controlled Scalability and Resource Costs Experiment 2: Deployment Latency

Shadow simulation

Section 4.1

Experiment 3: Fault Injection, Threshold Behavior, and Parser Checks

Shadow simulation, native profiling and parser pipeline

Total transmitted data node and payload scaling, and implementation-message count under node scaling User-space CPU instructions, peak heap, and cumulative allocation under node and payload scaling Controller-measured broadcast completion latency under payload and node scaling; RTT context for deployment measurements Delivery counts, delivery ratio, delivered hashes, sender hashes, duplicate-delivery flags, conflicting-delivery flags, spurious-delivery flags and validity flags

RQ2

RQ3

RQ4

Native profiling

GCP and FABRIC

Section 4.1

Section 4.2

Sections 4.3 and 4.4

RQ4: Fault-injection behavior. Do the implementations behave consistently with their expected safety, liveness, and threshold behavior under the tested silentnode, randomized message-omission, and partition-based equivocation scenarios? Table 1 maps each research question to the corresponding experiment, testbed, and metric group. The purpose of this table is to provide a detailed record supporting the three experiments reported in the paper. 3.2

Orchestration and Node Architecture

The benchmark consists of a centralized controller and a set of peer-to-peer nodes. The controller is not part of the reliable-broadcast algorithm being evaluated. It is used to distribute configuration, synchronize the beginning and end of each run, and collect metrics after the algorithm has terminated. This design makes the experiments repeatable and makes it possible to execute the same algorithms across Shadow, native profiling, GCP, and FABRIC. Controller lifecycle. At startup, the controller exposes an HTTP REST interface. Each node registers with the controller by sending its node identifier, public key, and listening address. The controller holds these registration requests until the expected number of nodes have registered. This registration barrier prevents a node from starting the experiment before the full network membership and cryptographic material are known. Once all nodes have registered, the controller returns the configuration for each node. The configuration includes the selected algorithm, the peer list, payload size, cryptographic material, and fault-injection role. The controller validates configuration consistency, including that the requested injected faults do

Y. Wang et al.

not exceed the run’s configured t and d threshold values. After receiving the configuration, nodes establish pairwise peer-to-peer TCP connections. To avoid duplicate connections, a node initiates a connection only to peers with larger identifiers; this yields one bidirectional connection between each pair. After the peer-to-peer network has been established, nodes notify the controller through a readiness endpoint. The controller again acts as a barrier and releases all nodes only when the expected number of nodes are ready. The designated sender then initiates the broadcast. Upon local delivery, each node reports completion to the controller. In fault-injection experiments, silent nodes are configured to signal completion even though they suppress algorithmic messages. After all expected completion signals have been received, the controller waits for a configurable grace period, set to three seconds by default, before asking nodes to upload metrics. The grace period allows in-flight algorithmic messages to be logged before the final metric snapshot is taken. Node layers. Each node separates transport, management, metrics, and algorithm logic. The Transport layer establishes the peer-to-peer connections and provides byte-stream send and receive functionality. The Manager layer exposes two primitives to the algorithm implementation: a broadcast primitive for sending the same implementation message to all peers, and a per-recipient send primitive for sending distinct implementation messages to selected peers. The algorithm layer is responsible for serializing and deserializing algorithm-specific message structures. The Manager layer is also the common measurement and interception point. It records sent and received implementation messages, byte counts, and delivery timestamps. It also hosts the fault-injection wrappers used to suppress outgoing or incoming messages in selected experiments. This design is important for comparability: Bracha, AFRT, and Coded MBRB are evaluated through the same orchestration, transport, metric, and fault-injection interfaces. Metric snapshot. At the end of each execution, every node reports a structured metric object to the controller. This object contains the node identifier, role, delivery status, delivery count, sent and received byte counts, sent and received implementation-message counts, algorithm initiation and delivery timestamps, memory statistics, and hashes. If the node delivered a payload, it reports the SHA-256 hash of the delivered payload. The designated sender additionally reports the SHA-256 hash of the original application payload. These hashes are used by the parser to detect inconsistent or invalid delivery outcomes.

3.3

Implementation Details Affecting Evaluation

This subsection records implementation choices that directly affect measurement validity or interpretation. It is not intended as a complete implementation manual.

Reliable Broadcast Benchmarking Controller

Node i

Node j (j > i)

Start and listen for requests

Start P2P server (Prepare communication)

BARRIER: Wait for n nodes to be registered

Config (Algorithm, Role, Peer List, Crypto, ...) Config (Algorithm, Role, Peer List, Crypto, ...)

Establish P2P Connection (i < j)

Ready Ready

BARRIER: Wait for n nodes to be ready

Algorithm execution

Local Delivery

Done Done

BARRIER: Wait for n nodes to be done

Push collected metrics Push collected metrics

Fig. 1. Detailed methodology: orchestration sequence used by the benchmark. The controller acts as a registration, readiness, completion, and metric-collection barrier, while algorithmic messages are exchanged directly among nodes.

Y. Wang et al.

Concurrency and locking. The algorithm implementations originally processed messages sequentially. To reduce avoidable latency, the implementation was later modified to process incoming messages concurrently. Algorithm state, such as collected signatures, fragments, quorums, and delivery status, is kept in shared state protected by mutual exclusion locks. Critical sections were kept as short as possible, especially for AFRT and Coded MBRB, whose cryptographic operations can be expensive. When possible, a node copies the state needed for a computation while holding the lock, releases the lock, and then performs the heavier cryptographic or coding operation outside the critical section. Serialization. The algorithms serialize their own implementation messages before passing byte streams to the Manager and Transport layers. Early versions used JSON serialization. The final evaluation uses Go’s gob encoding because JSON introduced substantial encoding overhead and additional processing cost. This matters for the network-overhead metric: the measured bytes are serialized implementation messages, including algorithmic metadata, signatures, fragments, commitments, and payload data when applicable. Cryptographic choices. AFRT uses Go’s crypto/ed25519 package for public-key signatures. Ed25519 was selected because it is simple to use and provides compact signatures. Coded MBRB uses gnark-crypto for KZG vector commitments and threshold-signature operations over BN254, and klauspost/reedsolomon for erasure coding. These choices affect both CPU instruction count and memory behavior. In particular, the high fixed CPU cost observed for Coded MBRB is tied to generating vector commitments, verifying inclusion proofs, producing and combining threshold-signature shares, and encoding or reconstructing fragments. Measurement boundary. The byte metric is collected immediately before an implementation message is passed from the Manager layer to the Transport layer. It therefore includes serialized algorithmic content but excludes TCP/IP headers, HTTP orchestration messages, and metric-upload traffic. CPU measurements in native profiling cover the node process from initialization to termination; because the same orchestration path is used for all algorithms, the common initialization and termination overheads are present across all measurements. Memory measurements are collected through Go’s runtime after the controller releases the termination barrier. 3.4

Single-Shot Scope

The implementation evaluates single-shot broadcast instances. Each run consists of one invocation of the selected reliable-broadcast algorithm for one application payload. This design intentionally isolates the implementation cost of the reliable-broadcast primitive itself. A multi-shot system would require additional mechanisms such as sequence numbers, batching, sliding windows, admission control, and garbage collection across many concurrent or repeated broadcast instances.

Reliable Broadcast Benchmarking

The single-shot design is therefore a methodological choice rather than a claim that deployed systems use reliable broadcast only once. It avoids confounding the measurements with wrapper-level engineering decisions. For example, a stop-and-wait wrapper would limit throughput to roughly one completed instance per round-trip time, while a sliding-window design would introduce buffer-management policies and possible resource-exhaustion behavior. Those effects are important for future work, but they are not part of the per-broadcast costs measured here. 3.5

Evaluation Environments

Table 2 summarizes the detailed role of each evaluation environment. The environments are complementary. Shadow provides controlled and reproducible network and fault-injection behavior. Native profiling isolates CPU and memory costs that Shadow does not accurately capture. GCP provides the primary deployment-oriented latency evidence. FABRIC provides supplementary latency evidence over a more distributed infrastructure. Unless otherwise stated, each configuration is repeated 10 times. Shadow simulation. The Shadow environment executes the compiled Go binaries over a simulated network topology. All nodes are connected through a simulated 1 Gbps switch. For each Shadow configuration, the experiment is repeated with 10 recorded seeds: {42, 286, 386, 407, 486, 1337, 6502, 8086, 25565, 68000}. This matters because the message-omission fault injector samples recipients randomly. Native profiling. The native profiling environment runs the same binaries on localhost. CPU instructions are collected with perf stat -e instructions:u and appended to the metric JSON. The :u suffix restricts counting to user-space instructions. Memory statistics are collected using Go’s runtime.ReadMemStats. The main memory metrics are peak heap, reported through HeapSys, and cumulative allocation, reported through TotalAlloc. Google Cloud Platform. The GCP deployment is the primary deployment-oriented latency environment. Nodes communicate over a private VPC. The controller measures completion latency as the elapsed time between releasing the ready barrier and receiving completion signals from all honest nodes. This avoids relying on synchronized clocks across VMs. In the GCP deployment, RTT measurements among nodes produced average RTTs between 0.25 ms and 0.86 ms, with peak delays below 3 ms. FABRIC. FABRIC is retained as supplementary deployment evidence. It is useful because it exercises a more distributed infrastructure and supports larger latency experiments than the small GCP setup. However, FABRIC measurements must be interpreted together with the placement of nodes across the five FABRIC sites used (TACC, UTAH, NCSA, MAX, and MICH) and the measured RTT distribution. The RTT between the nodes was measured before every

Y. Wang et al.

Table 2. Evaluation environments and their role in the benchmark. Because the benchmark uses a shared manager layer, all executions generate a unified JSON schema containing: algorithm, n, t, d, payload size, fault configurations, controller timestamps, delivery status, hashes, message/byte counts, and memory statistics. Env.

Setup

Shadow simulation

Shadow v3.3.0 in Ubuntu 24.04 container, simulated 1 Gbps switch

Native profiling

Parameters Measured varied quantities

n, payload size, silent nodes, message drops, sender equivocation Fedora 44 x86-64 n, payload localhost, Linux size, silent perf, Go nodes ReadMemStats

Transmitted bytes, implementation messages, delivery counts User-space CPU instructions, peak heap, cumulative allocation Controllermeasured broadcast completion latency

Google Cloud Platform

VM deployment with private VPC communication

n, payload size

FABRIC testbed

Distributed multi-site testbed deployment

n, payload size

Controllermeasured broadcast completion latency

All generated runs

Delivery count, delivered hash, sender hash, violation flags

Post– processing consistency checks

Purpose

Main limitation

Controlled communication and fault-injection experiments using the same Go binaries Isolate local processing and memory costs outside Shadow

Simulated time does not capture local CPU delay

Deploymentoriented latency under Virtual Machine (VM) and Virtual Private Cloud (VPC) execution Supplementary deploymentoriented latency evidence over a distributed infrastructure

Small cloud deployment; not a production or wide-area study

Checking of safety-related outcomes and aggregation of raw JSON outputs

Checks executions generated by the test campaign; not exhaustive verification

Localhost execution does not model network latency

Site placement and RTT distribution affect comparability

single broadcast execution during the initial P2P connection phase. These measurements were conducted across the approximately 3 hours and 50 minutes it took to execute all performed algorithm tests on FABRIC. The results of these measurements are detailed in Section 4.2.

3.6

Data Collection Pipeline

The evaluation workflow is automated by scripts included in the public artifact. The controller aggregates node-level metrics into one JSON file per run. Each JSON file records both node metrics and global experiment parameters, including algorithm, network size, Byzantine threshold t, message-adversary power d, payload size, sender identifier, number of silent nodes, number of message drops, and controller-measured start and end timestamps.

Reliable Broadcast Benchmarking

Environment-specific metadata is appended to the raw output by these scripts. Shadow outputs include the seed used for the run, while native profiling and deployment-oriented outputs include the iteration index. Native-profiling includes parsed perf instruction counts for each node. A secondary parser converts raw JSON files into structured CSV files and checks safety-related outcomes. The parser checks whether an honest node delivered more than once, whether delivering honest nodes delivered different hashes, whether the delivered hash matches the sender hash when the sender is correct, and whether a node delivered when no broadcast was initiated. These checks are deterministic post-processing checks over the generated experiment outputs; they are not formal verification and they do not exhaustively explore all Byzantine executions. Plots are generated after two aggregation stages. First, node metrics are aggregated within each broadcast execution. For example, total transmitted data is summed over nodes, while CPU instruction count can be averaged per node. Second, the resulting execution-level values are aggregated over the 10 repetitions for the configuration. Unless explicitly stated otherwise, figures report the arithmetic mean over 10 runs, and shaded regions represent one standard deviation. We do not remove outliers because the observed distributions were consistently narrow.

3.7

Metric Definitions

This subsection gives the metric boundaries used throughout the paper. Network overhead. Let Bi denote the number of bytes of implementation messages P sent by node i during one broadcast instance. Total network overhead is i Bi . The metric includes serialized implementation messages encoded with gob; this includes payloads, fragments, signatures, vector commitments, inclusion proofs, threshold-signature shares, and other algorithmic metadata. It excludes TCP/IP headers, HTTP orchestration traffic, and metric-upload traffic. Implementation-message count. Implementation-message count is the number of algorithm-generated messages sent by the nodes. This metric is intentionally separate from total transmitted bytes. Coded MBRB may transmit many lightweight implementation messages while still transmitting substantially fewer bytes than full-payload algorithms. CPU instruction count. Computational cost is measured as user-space CPU instructions per node using perf stat -e instructions:u. Because this profiles the full node process from initialization to termination, the measurement includes common orchestration overhead. However, the same initialization and termination path is used across algorithms, making the metric useful for relative comparison.

Y. Wang et al.

Memory usage. Peak heap is reported using Go’s HeapSys. Cumulative allocation is reported using TotalAlloc. Peak heap captures the maximum memory pressure reached during the execution, while cumulative allocation captures allocation churn during the run. We emphasize peak heap, but we include cumulative allocation because it helps explain payload-copying and buffering costs. Broadcast completion latency. Deployment latency is measured at the controller. Let tstart be the time at which the controller releases the ready barrier, and let tend be the time at which the controller has received completion signals from all honest nodes. Completion latency is tend −tstart . This avoids clock-skew artifacts but includes controller-node transit time. Delivery ratio. Let H be the set of honest nodes and let D ⊆ H be the honest nodes that deliver before the timeout. The delivery ratio is |D|/|H|. In the fault-threshold experiments, the absolute numbers of delivering nodes are often reported because the theoretical guarantees for MBRB are stated in terms of delivery power. Safety checks. The parser records delivery count, delivered hash, and sender hash. A duplicate-delivery violation is flagged if an honest node delivers more than once. A conflicting-delivery violation is flagged if two honest nodes deliver different hashes for the same broadcast. A validity violation is flagged if a delivered hash differs from the sender hash in a correct-sender execution. A spurious-delivery violation is flagged if a node delivers when no broadcast was initiated. 3.8

Fault-Injection Mechanisms

Fault injection is implemented at the Manager layer so that the honest algorithm code remains unchanged. Silent nodes. A silent node remains alive but suppresses incoming and outgoing algorithmic messages. This differs from killing the process because killing the process would cause the operating system to close TCP connections and potentially reveal the failure at the transport layer. The silent-node mechanism instead approximates an undetectable crash from the algorithm’s perspective. This number of silent nodes is configured by the numSilent parameter. Randomized message omission. To simulate message omission, the Manager layer uses a parameter numMsgDrops. For each implementation-message broadcast, it uniformly samples up to numMsgDrops recipients among honest nodes without replacement and suppresses those outgoing messages before they reach the transport layer. This models message omission at the implementation-message level rather than packet loss at the TCP level. It is not a worst-case adaptive message adversary because it does not select messages based on global real-time knowledge of the algorithm state.

Reliable Broadcast Benchmarking

Table 3. Experiment configurations. Experiment

RQs

Testbed(s)

Variables

Repetitions

Experiment 1: Controlled Scalability and Resource Costs

RQ1, RQ2

Shadow and native profiling

10 per configuration

Experiment 2: Deployment Latency

RQ3

GCP and FABRIC

Experiment 3: Fault Injection, Threshold Behavior, and Parser Checks

RQ4

Shadow, native profiling, and parser pipeline

Node scaling: n = 10, 15, 20, 25, 30 at 1 MB; payload scaling: 100 KB–1 MB and 1–8 MB at n = 30; extended CPU payload test: 10–40 MB at n = 10 GCP payload scaling at n = 5; GCP node scaling n = 4–11 at 1 MB; FABRIC node and payload scaling as supplementary evidence Silent nodes, randomized message omissions, partition-based equivocation, and additional parser-check permutations

10 per configuration

Partition-based equivocation. The equivocation experiment is Twins [9] inspired. The sender runs two algorithm instances through two SplitManager wrappers, each restricted to one partition of the network. The two instances broadcast different payloads to different halves of the network. This creates a controlled splitsender equivocation scenario without modifying the honest algorithm code. The experiment does not exhaustively characterize Byzantine behavior; it tests one reproducible scenario designed to expose conflicting-delivery risks. The partitionbased equivocation is enabled by the Boolean parameter twinsSender. Configured thresholds and injected faults. The benchmark separates the configured mathematical fault thresholds from the actual injected faults. For Bracha, the relevant threshold condition is n > 3t. For AFRT and Coded MBRB, the relevant threshold condition is n > 3t + 2d, where d is the message-adversary removal power. The experiment configuration records both the tolerated parameters and the actually injected numbers of silent nodes and dropped messages. Specifically, our threshold tests use t = numSilent and d = numMsgDrops, and vary these values across configurations. The injected faults target the two adversarial dimensions of our model: Byzantine-node behavior (silence and equivocation) and message-adversary omissions. In-transit modification of messages from correct nodes is outside the omission-only MA model, while AFRT and Coded MBRB additionally use cryptographic signatures to authenticate protocol evidence. 3.9

Experimental Configurations

The evaluation comprises three RQ-mapped experiments. Table 3 summarizes the configurations used by the three experiments. The results in Section 4 follow the same experiment numbering. Exp-1: Controlled scalability and resource costs (RQ1 and RQ2). This experiment runs without fault injection and measures communication, CPU, and mem-

Y. Wang et al.

ory costs. In Shadow, we measure total transmitted data and implementationmessage count. In native profiling, we measure CPU instructions and memory usage. We use two primary scaling dimensions: node scaling from n = 10 to 30 in increments of 5 with a fixed 1 MB payload, and payload scaling at n = 30 from 0.1 MB to 8 MB. An additional native profiling experiment scales payloads from 10 MB to 40 MB at n = 10 because 30-node configurations exceeded the host machine’s memory limits at these larger payload sizes.

Exp-2: Deployment latency (RQ3). We measure broadcast completion latency in deployment-oriented environments. The GCP experiments evaluate payload scaling up to 8 MB at n = 5 and node scaling from n = 4 to 11. Supplementary FABRIC experiments extend the deployment study to larger network sizes (up to n = 30) and broader payload ranges (100 KB to 40 MB).

Exp-3: Fault injection and consistency checks (RQ4). This experiment runs in Shadow and native profiling at n = 30 with a 1 MB payload for the main plotted delivery and parser-check results and tests varying numbers of silent nodes (numSilent), randomized message omissions (numMsgDrops), and the partitionbased sender equivocation scenario (twinsSender). For the threshold tests, we set t = numSilent and d = numMsgDrops. We compare observed delivery with the sufficient bounds n > 3t for Bracha and n > 3t + 2d for AFRT and Coded MBRB. The reported threshold scenarios use (t, d) = (9, 0), (10, 0) for Bracha and (5, 7), (7, 5) for AFRT and Coded MBRB; Section 4.4 details broader fault permutations and parser checks.

Table 4 summarizes the parser-check accounting. The parser-check campaign is important because it connects the raw metric outputs to the safety-related claims made in the paper. Table 4. Parser-check campaign accounting. The parser found zero duplicate-delivery, conflicting-delivery, invalid-delivery, or spurious-delivery violations in these checked outputs. Output group

Runs

Checked entries

Shadow plots

1,500

43,500

840 480 870 900

19,500 3,000 24,600 27,000

87,600

2,244,000

92,190

2,361,600

Native profiling plots GCP deployment plots FABRIC deployment plots Native profiling fault-injection tests Additional Shadow fault permutations Total

Purpose Network overhead, message counts, and selected fault-injection plots CPU and memory measurements GCP latency measurements FABRIC latency measurements CPU and memory degradation under silent nodes Additional silent-node, message-drop, and equivocation parser checks Full parser-check campaign

Reliable Broadcast Benchmarking

Evaluation Results

Across all generated outputs and test configurations, the parser checked 2,361,600 entries over 92,190 runs and found zero parser-detected property violations. These checks provide implementation-level evidence over the tested executions; they do not replace the formal correctness arguments of the algorithms and do not constitute exhaustive Byzantine testing. For the payload-dependent communication term, Bracha and AFRT incur O(n2 |m|) total communication, whereas Coded MBRB targets O(n|m| + n2 κ) [3,4,15]. Exp-1 examines whether these asymptotic differences appear in the implementations. The results expose a consistent system trade-off. Coded MBRB reduces transmitted data, peak heap, and deployment latency when payload movement or network transit dominates. This advantage comes at a higher CPU cost due to erasure coding, vector commitments, inclusion proofs, and threshold-signature operations. Bracha and AFRT are computationally lighter for smaller payloads and local workloads, but their repeated full-payload dissemination becomes expensive as the system or payload grow. 4.1

Exp-1: Controlled Scalability and Resource Costs

Experiment 1 answers RQ1 and RQ2. It uses Shadow simulation for communication cost and native profiling for CPU and memory cost. No faults are injected in this experiment. Bracha

1750

AFRT Coded MBRB

Total Data Sent (MB)

1500 1250 1000 750 500 250 0 10

20 Network Size (n)

Fig. 2. Exp-1, Shadow: total transmitted data under node scaling with a 1 MB payload. Coded MBRB transmits substantially fewer bytes as n grows.

Shadow: total transmitted data under node scaling. Fig. 2 reports total transmitted data as the number of nodes increases from n = 10 to n = 30 with a fixed

Y. Wang et al.

1 MB payload. Bracha and AFRT increase much more aggressively than Coded MBRB. At n = 30, Bracha and AFRT transmit roughly 1.7–1.8 GB per single broadcast, while Coded MBRB remains close to 128 MB. This is the central communication-scaling result for RQ1. Bracha AFRT Coded MBRB

2500

Total Messages Sent

2000

1500

1000

500

20 Network Size (n)

Fig. 3. Exp-1, Shadow: implementation-message count under node scaling with a 1 MB payload. Coded MBRB sends more lightweight implementation messages even while transmitting fewer bytes.

Shadow: implementation-message count under node scaling. Fig. 3 reports the number of implementation messages under the same node-scaling configuration. Coded MBRB sends more individual implementation messages than Bracha and AFRT, reaching roughly 2500 messages at n = 30, compared with roughly 1750 messages for Bracha and AFRT. This result is important because it separates byte scalability from message-count scalability. Coded MBRB improves total transmitted data, but not because it sends fewer messages; rather, it sends more lightweight messages containing fragments and cryptographic evidence. Thus, Coded MBRB improves byte scalability, but not message-count. Shadow: total transmitted data under payload scaling. Fig. 4 reports total transmitted data at n = 30 while payload size grows. Bracha and AFRT grow approximately linearly with payload size because they repeatedly disseminate the full payload. Coded MBRB grows much more slowly because it disseminates coded fragments and compact cryptographic evidence. At an 8 MB payload, Bracha and AFRT transmit approximately 14 GB per single broadcast, while Coded MBRB is near 1 GB. Native profiling: CPU instructions under node scaling. Fig. 5 reports user-space CPU instructions per node while the network size grows with a fixed 1 MB payload. At n = 30, Coded MBRB executes approximately 800 million instructions

Reliable Broadcast Benchmarking 1750

Bracha AFRT Coded MBRB

14000 12000

1250

Total Data Sent (MB)

1500

Bracha AFRT Coded MBRB

1000 750 500 250

10000 8000 6000 4000 2000

0.2

0.4

0.6 Payload Size (MB)

(a) 100 KB–1 MB

0.8

1.0

4 5 Payload Size (MB)

(b) 1–8 MB

Fig. 4. Exp-1, Shadow: total transmitted data under payload scaling at n = 30. Fullpayload dissemination dominates Bracha and AFRT as payload size grows.

per node, compared with roughly 250 million for Bracha and AFRT. This is the main counterweight to the communication result: Coded MBRB’s byte savings are purchased with substantially higher local computation. Native profiling: CPU instructions under payload scaling. Fig. 6 reports CPU instructions at n = 30 while payload size grows from 100 KB to 8 MB. Coded MBRB has a high fixed computational cost, while Bracha and AFRT grow with payload size because they process full-payload messages repeatedly. Bracha overtakes AFRT around 500 KB and overtakes Coded MBRB around 6 MB. This result shows that the CPU ranking depends on payload size, not only on algorithm class. Native profiling: extended CPU payload scaling. Fig. 7 reports the extended CPU experiment from 10 MB to 40 MB at n = 10. The 30-node configuration exhausted the 32 GB host memory at these larger payloads, so the extended test uses fewer nodes. The result shows AFRT surpassing Coded MBRB around a 15 MB payload. This strengthens the RQ2 conclusion that cryptographic fixed cost is not the only relevant CPU cost: repeated allocation, copying, hashing, and serialization of large payloads can dominate as payloads increase. Native profiling: peak heap under node scaling. Fig. 8 reports peak heap as the number of nodes grows with a fixed 1 MB payload. All algorithms start near 40 MB at n = 10. At n = 30, Bracha and AFRT approach 100 MB, while Coded MBRB remains close to 50 MB. This result indicates that the memory advantage of fragment-based dissemination is visible even at a 1 MB payload. Native profiling: peak heap under payload scaling. Fig. 9 reports peak heap at n = 30 as the payload size grows. At an 8 MB payload, Bracha and AFRT exceed 800 MB peak heap, while Coded MBRB is approximately 350 MB.

Y. Wang et al.

Bracha AFRT Coded MBRB

Instructions per Node (Millions)

800

600

400

200

20 Network Size (n)

Fig. 5. Exp-1, native profiling: CPU instruction count under node scaling with a 1 MB payload. Coded MBRB pays a higher local computational cost due to coding and cryptographic operations.

1400

600

Bracha AFRT Coded MBRB

400

Instructions per Node (Millions)

800

Bracha AFRT Coded MBRB

1200

1000

800

600

400

200

0.2

0.4

0.6 Payload Size (MB)

(a) 100 KB–1 MB

0.8

1.0

4 5 Payload Size (MB)

(b) 1–8 MB

Fig. 6. Exp-1, native profiling: CPU instruction count under payload scaling at n = 30. The fixed cryptographic cost of Coded MBRB is high, but full-payload processing makes Bracha and AFRT grow with payload size.

Reliable Broadcast Benchmarking

3500

Bracha AFRT Coded MBRB

3000 Instructions per Node (Millions)

2500

2000

1500

1000

500 10

25 Payload Size (MB)

Fig. 7. Exp-1, native profiling: extended CPU instruction count under payload scaling at n = 10. The extended test is run at n = 10 because larger payloads exhausted the host memory at n = 30.

Bracha AFRT Coded MBRB

Peak Heap Memory per Node (MB)

100 90 80 70 60 50 40 10

20 Network Size (n)

Fig. 8. Exp-1, native profiling: peak heap under node scaling with a 1 MB payload. Coded MBRB grows more slowly in peak heap than Bracha and AFRT.

Peak Heap Memory per Node (MB)

100

Y. Wang et al.

Bracha AFRT Coded MBRB Peak Heap Memory per Node (MB)

80 60 40

Bracha AFRT Coded MBRB

800 600 400 200

20 0.2

0.4

0.6 Payload Size (MB)

0.8

1.0

(a) 100 KB–1 MB

4 5 Payload Size (MB)

(b) 1–8 MB

Fig. 9. Exp-1, native profiling: peak heap under payload scaling at n = 30. Coded MBRB uses substantially less peak heap for larger payloads.

Cumulative Memory Allocation per Node (MB)

250

Bracha AFRT Coded MBRB

225 200 175 150 125 100 75 50

20 Network Size (n)

Fig. 10. Exp-1, native profiling: cumulative allocation under node scaling with a 1 MB payload. Cumulative allocation captures allocation churn caused by repeated fullpayload handling.

Reliable Broadcast Benchmarking

Native profiling: cumulative allocation under node scaling. Fig. 10 reports cumulative allocation as n grows. We additionally report cumulative allocation because it captures allocation churn that is not fully visible from peak heap alone. Bracha and AFRT show substantially larger cumulative allocation than Coded MBRB under node scaling. Native profiling: cumulative allocation under payload scaling. Fig. 11 reports cumulative allocation under payload scaling at n = 30. Bracha and AFRT increase sharply as payload size grows, while Coded MBRB remains much lower. This result supports the interpretation that full-payload dissemination affects not only network traffic but also allocation behavior. 2000

Bracha AFRT Coded MBRB

Cumulative Memory Allocation per Node (MB)

250 200 150 100 50

0.2

0.4

0.6 Payload Size (MB)

0.8

1.0

(a) 100 KB–1 MB

Bracha AFRT Coded MBRB

1750 1500 1250 1000 750 500 250 0

4 5 Payload Size (MB)

(b) 1–8 MB

Fig. 11. Exp-1, native profiling: cumulative allocation under payload scaling at n = 30. Bracha and AFRT allocate substantially more memory as payload size grows.

4.2

Exp-2: Deployment Latency

Experiment 2 answers RQ3. GCP is the primary deployment-oriented latency environment. FABRIC is retained as supplementary evidence because it exercises a more distributed infrastructure but requires RTT and site-placement context for careful interpretation. Google Cloud Platform Results. GCP: payload scaling. Fig. 12 reports broadcast completion latency at n = 5 as payload size grows to 8 MB. Bracha and AFRT reach approximately 900 ms at 8 MB, while Coded MBRB remains below 400 ms. This result shows that the communication savings observed in Shadow can translate into lower completion latency in the evaluated cloud deployment. GCP: node scaling. Fig. 13 reports completion latency from n = 4 to n = 11 with a fixed 1 MB payload. At n = 11, Coded MBRB is approximately 70 ms, compared with about 180 ms for Bracha and nearly 150 ms for AFRT. Although this

Y. Wang et al.

Broadcast Completion Latency (ms)

1000

Bracha AFRT Coded MBRB

800 600 400 200

4 5 Payload Size (MB)

Fig. 12. Experiment 2, GCP: broadcast completion latency under payload scaling at n = 5. Coded MBRB remains below 400 ms at 8 MB, while Bracha and AFRT reach approximately 900 ms.

is a small cloud deployment, it gives deployment-oriented evidence that Coded MBRB’s lower byte volume can outweigh its additional local cryptographic work. FABRIC Results. FABRIC: interpretation context. The FABRIC results are supplementary deployment evidence. They are included because they exercise a wider distributed infrastructure and larger configurations than GCP. However, the latency curve for node scaling exhibits a noticeable fluctuation around n = 15. Based on our RTT measurements, where inter-site RTT reach up to 81.00 ms compared to submillisecond intra-site RTT, this variance reflects the placement of nodes across distant geographic sites rather than a bottleneck in the algorithms themselves. Because of this environmental variability, we treat the FABRIC data as supplementary evidence and rely primarily on Shadow and GCP for our controlled scaling and cloud-latency conclusions. FABRIC: node scaling. Fig. 14 reports completion latency under node scaling at a 1 MB payload, demonstrating the algorithmic behavior across a geographically distributed testbed. FABRIC: micro-payload scaling. Fig. 15 reports FABRIC latency under payload scaling from 100 KB to 1 MB at n = 30. This range helps expose fixed overheads and small-payload behavior. FABRIC: macro-payload scaling. Fig. 16 reports FABRIC latency from 1 MB to 8 MB at n = 30. This range corresponds to the main macro-payload scaling interval used elsewhere in the evaluation.

Reliable Broadcast Benchmarking

Bracha AFRT Coded MBRB

180 Broadcast Completion Latency (ms)

160 140 120 100 80 60 40 4

7 8 Network Size (n)

Fig. 13. Experiment 2, GCP: broadcast completion latency under node scaling with a 1 MB payload. Coded MBRB has the lowest latency at n = 11 in the evaluated cloud setting.

Broadcast Completion Latency (ms)

900 800 700

Bracha AFRT Coded MBRB

600 500 400 10

20 Network Size (n)

Fig. 14. Experiment 2, FABRIC: supplementary broadcast completion latency under node scaling with a 1 MB payload. This figure should be interpreted together with FABRIC RTT and site-placement measurements.

Y. Wang et al.

Bracha AFRT Coded MBRB

Broadcast Completion Latency (ms)

900 800 700 600 500 400 300 200

0.2

0.4

0.6 Payload Size (MB)

0.8

1.0

Fig. 15. Experiment 2, FABRIC: supplementary latency under micro-payload scaling at n = 30.

4500

Bracha AFRT Coded MBRB

Broadcast Completion Latency (ms)

4000 3500 3000 2500 2000 1500 1000 500 1

4 5 Payload Size (MB)

Fig. 16. Experiment 2, FABRIC: supplementary latency under macro-payload scaling at n = 30.

Reliable Broadcast Benchmarking Bracha AFRT Coded MBRB

17500 Broadcast Completion Latency (ms)

15000 12500 10000 7500 5000 2500 10

25 Payload Size (MB)

Fig. 17. Experiment 2, FABRIC: supplementary latency under extended payload scaling at n = 30.

FABRIC: extended payload scaling. Fig. 17 reports FABRIC latency from 10 MB to 40 MB at n = 30, testing deployment latency under the geographic network conditions detailed previously. FABRIC RTT measurements. The RTT distribution among five FABRIC sites (TACC, UTAH, NCSA, MAX, and MICH) was measured immediately before every single broadcast execution during the initial startup handshake. Across the approximately 3 hours and 50 minutes it took to execute all performed algorithm tests on FABRIC, these measurements resulted in 690,900 individual RTT data points. Across all configurations, the minimum observed RTT was 0.06 ms, the median was 31.24 ms, the mean was 30.64 ms, and the maximum was 81.00 ms. Isolating the data by site reveals 118,500 intra-site pairs averaging 0.19 ms and 572,400 inter-site pairs averaging 36.95 ms. This results in high variance of 375.21 ms2 . 4.3

Exp-3: Fault Injection, Threshold Behavior, and Parser Checks

Experiment 3 answers RQ4. The result items in this subsection are from Shadow simulation, native profiling and parser post-processing. Shadow: silent-node threshold behavior. Fig. 18 reports the number of delivering nodes as the number of silent nodes increases at n = 30 and a 1 MB payload. For Bracha, the threshold condition n > 3t permits t = 9 faults at n = 30, leaving 21 non-silent nodes. At 9 silent nodes, the observed number of delivering nodes is 21. At 10 silent nodes, the threshold is exceeded and the observed number of delivering nodes drops to zero. AFRT and Coded MBRB follow the corresponding threshold behavior for their configured t and d values.

Y. Wang et al. Silent < n/3 Bracha AFRT Coded MBRB

Delivering Nodes

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Silent Nodes

Fig. 18. Exp-3, Shadow: delivering nodes under silent-node scaling at n = 30 and a 1 MB payload. Delivery follows the expected threshold behavior and drops to zero when the configured threshold is exceeded.

Shadow: average messages under silent nodes. Fig. 19 reports the average messages sent per node as the number of silent nodes increases. Message volume decreases as fewer active nodes participate in the broadcast. This supports the performance-degradation interpretation: injected silence reduces the amount of work generated by the algorithm rather than producing unexpected additional message storms. Shadow: message-distribution under silent nodes. Fig. 20 reports the distribution of messages sent per node. The distribution view shows whether work is balanced across the remaining active nodes or concentrated on selected nodes. In the tested configurations, the observed degradation is consistent with the reduction in active participants. Shadow: selected fault-scenario outcomes. Table 5 summarizes the selected threshold and equivocation scenarios at n = 30. Within the sufficient bounds, the delivery guarantee matches the observed count: 21 for Bracha and 18 for both AFRT and Coded MBRB. Beyond these bounds, and under the partition-based equivocation scenario, no delivery guarantee applies; zero deliveries were observed. These sufficient bounds are not claimed to be sharp empirical cutoffs. Our experiments evaluate representative configurations within and immediately beyond the proven thresholds, but do not systematically characterize delivery behavior outside the guaranteed region. Native profiling: performance degradation. The fault-injection results also show predictable performance degradation. As the number of silent nodes grows, message volume, total transmitted data, CPU instructions, and memory allocation

Reliable Broadcast Benchmarking

Silent < n/3 Bracha AFRT Coded MBRB

Messages Sent per Node

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Silent Nodes

Fig. 19. Exp-3, Shadow: average messages per node under silent-node scaling at n = 30 and a 1 MB payload. Message volume decreases as silent nodes suppress participation.

Silent < n/3 Bracha AFRT

Messages Sent per Node

Coded MBRB

0 0

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Silent Nodes

Fig. 20. Exp-3, Shadow: distribution of messages per node under silent-node scaling. The distribution complements the average-message plot by showing the spread across nodes.

Y. Wang et al.

Table 5. Exp-3, Shadow: consistency checks across selected fault scenarios at n = 30. Algorithm

Fault scenario

Theoretical status

Delivery guarantee

Bracha

numSilent=9, numMsgDrops=0 numSilent=10, numMsgDrops=0 numSilent=5, numMsgDrops=7 numSilent=7, numMsgDrops=5 numSilent=5, numMsgDrops=7 numSilent=7, numMsgDrops=5 twinsSender=true

Within n > 3t

Threshold exceeded Within n > 3t + 2d Threshold exceeded Within n > 3t + 2d Threshold exceeded Partition-based equivocation

No guarantee 18

Bracha AFRT AFRT Coded MBRB Coded MBRB All algorithms

No guarantee 18 No guarantee No guarantee

Observed Detected delivery violation

decrease because fewer nodes actively participate in the message exchange. At the maximum within-threshold silent-node configuration, average CPU instructions decrease by approximately 30% for Bracha and AFRT, and around 50% for Coded MBRB, peak heap usage decreases by 40–50%, and cumulative memory allocation by 45–60%. When the fault threshold is exceeded, local resource usage drops sharply because the protocols fail to reach required quorums and bypass execution phases. Figure 21 compares the CPU instructions, peak heap usage, and cumulative memory allocation under silent-node faults. This result does not change the main performance ranking; rather, it shows that the injected silent-node fault reduces work roughly in proportion to the number of active participants. 4.4

Additional Parser-Check Campaign

The parser-check campaign is a key part of the reproducibility evidence. It checks the raw outputs produced by both the plotted experiments and additional faultinjection configurations. The parser checks duplicate delivery, conflicting delivery, validity against the sender payload when applicable, and spurious delivery. The primary plotted results contribute 43,500 checked entries from 1,500 Shadow runs, 19,500 checked entries from 840 native profiling runs, 3,000 checked entries from 480 GCP deployment runs, 24,600 checked entries from 870 FABRIC deployment runs, and 27,000 checked entries from 900 native profiling faultinjection runs. Additional Shadow tests cover n ∈ {10, 20, 30}, a 100 KB payload, all relevant silent-node and message-drop permutations under maximal-t configurations with d = 0 and maximal-d configurations with t = 0, cases with and without the equivocating sender, and the 10 recorded seeds. These additional tests contribute 2,244,000 checked entries over 87,600 runs. Across the full campaign, the parser checked 2,361,600 entries over 92,190 runs. It found zero duplicate-delivery, conflicting-delivery, invalid-delivery, or

Reliable Broadcast Benchmarking Bracha AFRT Coded MBRB

800 Instructions per Node (Millions)

600

400

200

0 0

15 Silent Nodes

(a) CPU instructions. Bracha AFRT Coded MBRB

200 150 100 50

Bracha AFRT Coded MBRB

100 Peak Heap Memory per Node (MB)

Cumulative Memory Allocation per Node (MB)

250

80 60 40 20

0 0

15 Silent Nodes

(b) Cumulative allocation.

15 Silent Nodes

Fig. 21. Exp-3, native profiling: local resource usage under silent-node scaling at a 1 MB payload. The panels report CPU instruction count, cumulative allocation, and peak heap usage.

spurious-delivery violations in the tested configurations. This is implementationlevel evidence over the generated executions. It is not a formal proof and it is not exhaustive Byzantine testing. 4.5

Answers to the Research Questions

Answer to RQ1: Communication scalability. Compared with AFRT, the directly comparable MBRB baseline, Coded MBRB substantially improves byte scalability but not message-count scalability. In Shadow at n = 30 with a 1 MB payload, Bracha and AFRT transmit ca 1.7 GB, whereas Coded MBRB transmits close to 0.1 GB (Fig. 2). Under the same configuration, Coded MBRB sends roughly 2500 implementation messages, compared with ca 1750 for Bracha and AFRT (Fig. 3). Under payload scaling at n = 30, Bracha and AFRT reach ca 14 GB at an 8 MB payload, while Coded MBRB remains around 1 GB (Fig. 4). The answer to RQ1 is therefore that Coded MBRB is far more scalable in transmitted bytes than AFRT, while Bracha serves as the classical BRB reference and both Bracha and AFRT use fewer implementation messages. Answer to RQ2: Local resource cost. Compared with AFRT, Coded MBRB pays a higher local computational cost at smaller payloads, but avoids the largepayload CPU and memory growth caused by full-payload dissemination. In na-

Y. Wang et al.

tive profiling at n = 30 and a 1 MB payload, Coded MBRB executes ca 800 million CPU instructions per node, compared with roughly 250 million for Bracha and AFRT (Fig. 5). As payload size grows, Bracha overtakes Coded MBRB in CPU cost around 6 MB at n = 30, and AFRT overtakes Coded MBRB around 15 MB in the extended n = 10 experiment (Figures 6 and 7). Memory shows the same qualitative shift: at an 8 MB payload and n = 30, Bracha and AFRT exceed 800 MB peak heap per node, while Coded MBRB remains around 350 MB (Fig. 9). Thus, relative to AFRT, Coded MBRB becomes preferable for memory pressure and eventually for CPU cost in sufficiently large-payload regimes, although it remains more expensive in CPU at smaller payloads. Answer to RQ3: Deployment latency. The GCP deployment shows that Coded MBRB’s communication savings can translate into lower completion latency. At an 8 MB payload with n = 5, Bracha and AFRT reach ca 900 ms, whereas Coded MBRB remains below 400 ms (Fig. 12). At n = 11 with a 1 MB payload, Coded MBRB is roughly 70 ms, compared with about 180 ms for Bracha and nearly 150 ms for AFRT (Fig. 13). FABRIC provides additional deployment-oriented measurements up to n = 30 and larger payloads. Because the FABRIC nodes are geographically distributed across five US sites with high inter-site RTT (averaging 36.95 ms), these results naturally exhibit higher baseline latencies and higher variance. However, they show the same qualitative trend in the evaluated configurations: Coded MBRB achieves lower latency as payloads grow. The answer to RQ3 is affirmative in both deployment environments, GCP and FABRIC, where Coded MBRB achieved the lowest latency in our experiments. Answer to RQ4: Fault-injection behavior. The tested executions behaved consistently with the expected threshold behavior and produced no parser-detected specification violations. In the n = 30 silent-node experiment, with 9 silent nodes, all 21 non-silent nodes are guaranteed to deliver and did so, while 10 silent nodes exceed the threshold and yield zero deliveries (Fig. 18 and Table 5). For AFRT and Coded MBRB with numSilent=5 and numMsgDrops=7, both the guaranteed delivery and the observed counts are 18. In the threshold-exceeded and partition-based equivocation scenarios, no delivery guarantee applies, and zero deliveries were observed in the evaluated configurations. Across 92,190 runs and 2,361,600 parser-checked entries, the parser found zero duplicate-delivery, conflicting-delivery, invalid-delivery, or spurious-delivery violations. This answers RQ4 for the tested fault scenarios, while leaving exhaustive Byzantine testing outside the paper’s scope.

Conclusion

We evaluated Bracha’s BRB algorithm, AFRT, and Coded MBRB in a shared Go benchmark framework using Shadow simulation, native profiling, and deploymentoriented latency measurements. The results expose a concrete systems trade-off. Relative to AFRT, the directly comparable MBRB baseline, Coded MBRB reduces data movement and deployment latency for larger payloads, but shifts cost

Reliable Broadcast Benchmarking

to cryptographic and coding computation. Bracha serves as the classical BRB reference and exhibits similar full-payload communication behavior. At n = 30 with a 1 MB payload, Coded MBRB sends about 14× less data than AFRT (and similarly than Bracha), but executes about 3× more CPU instructions per node. At an 8 MB payload, Coded MBRB uses around 350 MB peak heap, whereas both AFRT and Bracha exceed 800 MB. In the GCP deployment, Coded MBRB remains below 400 ms while AFRT and Bracha reach about 900 ms, and the supplementary FABRIC experiments show the same qualitative large-payload latency advantage over a broader distributed testbed. Across 92,190 runs, the parser found none of the checked violations in the tested configurations. The artifact, found in our open-source repository [25], supports extending the benchmark to additional algorithms, workloads, environments, and fault-injection semantics.

References 1. Abraham, I., Nayak, K., Ren, L., Xiang, Z.: Good-case latency of byzantine broadcast: a complete categorization. In: Miller, A., Censor-Hillel, K., Korhonen, J.H. (eds.) PODC ’21: ACM Symposium on Principles of Distributed Computing, Virtual Event, Italy, July 26-30, 2021. pp. 331–341. ACM (2021) 2. Albouy, T.: Foundations of Reliable Cooperation under Asynchrony, Byzantine Faults, and Message Adversaries. Ph.D. thesis, University of Rennes, France (2024), https://tel.archives-ouvertes.fr/tel-04764046 3. Albouy, T., Frey, D., Gelles, R., Hazay, C., Raynal, M., Schiller, E.M., Taïani, F., Zikas, V.: Near-optimal communication Byzantine reliable broadcast under a message adversary. In: Bonomi, S., Galletta, L., Rivière, E., Schiavoni, V. (eds.) 28th International Conference on Principles of Distributed Systems, OPODIS 2024, Lucca, Italy, December 11-13, 2024. LIPIcs, vol. 324, pp. 14:1–14:29. Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2024) 4. Albouy, T., Frey, D., Raynal, M., Taïani, F.: Asynchronous Byzantine reliable broadcast with a message adversary. Theor. Comput. Sci. 978, 114110 (2023) 5. Alhaddad, N., Das, S., Duan, S., Ren, L., Varia, M., Xiang, Z., Zhang, H.: Balanced byzantine reliable broadcast with near-optimal communication and improved computation. In: Milani, A., Woelfel, P. (eds.) Symposium on Principles of Distributed Computing, PODC. pp. 399–417. ACM (2022) 6. Auvolat, A., Frey, D., Raynal, M., Taïani, F.: Money transfer made simple: a specification, a generic algorithm, and its proof. Bull. EATCS 132 (2020) 7. Auvolat, A., Frey, D., Raynal, M., Taïani, F.: Byzantine-tolerant causal broadcast. Theor. Comput. Sci. 885, 55–68 (2021) 8. Auvolat, A., Raynal, M., Taïani, F.: Byzantine-tolerant set-constrained delivery broadcast. In: Felber, P., Friedman, R., Gilbert, S., Miller, A. (eds.) 23rd International Conference on Principles of Distributed Systems, OPODIS 2019, Neuchâtel, Switzerland, December 17-19, 2019. LIPIcs, vol. 153, pp. 6:1–6:23. Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2019) 9. Bano, S., Sonnino, A., Chursin, A., Perelman, D., Li, Z., Ching, A., Malkhi, D.: Twins: BFT systems made robust. In: Bramas, Q., Gramoli, V., Milani, A. (eds.) 25th International Conference on Principles of Distributed Systems, OPODIS 2021, Strasbourg, France, December 13-15, 2021. LIPIcs, vol. 217, pp. 7:1–7:29. Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2021)

Y. Wang et al.

10. Berger, C., Toumia, S.B., Reiser, H.P.: Scalable performance evaluation of Byzantine fault-tolerant systems using network simulation. In: 28th IEEE Pacific Rim International Symposium on Dependable Computing, PRDC 2023, Singapore, October 24-27, 2023. pp. 180–190. IEEE (2023) 11. Berger, C., Toumia, S.B., Reiser, H.P.: Exploring scalability of BFT blockchain protocols through network simulations. Formal Aspects Comput. 36(4), 24:1–24:29 (2024) 12. Bonomi, S., Decouchant, J., Farina, G., Rahli, V., Tixeuil, S.: Practical Byzantine reliable broadcast on partially connected networks. CoRR abs/2104.03673 (2021) 13. Boshoer, B., Disatnik, Y.: Coded MBRB implementation repository. https:// github.com/BenjaminBoshoer/CE-Final-Project (2024), bachelor’s thesis implementation project, Bar-Ilan University 14. Botrel, G., Piellard, T., Housni, Y.E., Tabaie, A., Gutoski, G., Kubjas, I., Galteland, Y.J.: Consensys/gnark-crypto: v0.20.1 (Mar 2026) 15. Bracha, G.: Asynchronous Byzantine agreement protocols. Inf. Comput. 75(2), 130–143 (1987) 16. Camaioni, M., Guerraoui, R., Monti, M., Vidigueira, M.: Oracular Byzantine reliable broadcast. In: Scheideler, C. (ed.) 36th International Symposium on Distributed Computing, DISC 2022, Augusta, Georgia, USA, October 25-27, 2022. pp. 13:1–13:19. LIPIcs, Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2022) 17. Camaioni, M., Guerraoui, R., Monti, M., Vidigueira, M.: Oracular Byzantine reliable broadcast. CoRR abs/2209.13304 (2022) 18. Collins, D., Guerraoui, R., Komatovic, J., Kuznetsov, P., Monti, M., Pavlovic, M., Pignolet, Y., Seredinschi, D., Tonkikh, A., Xygkis, A.: Online payments by merely broadcasting messages. In: 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2020, Valencia, Spain, June 29 - July 2, 2020. pp. 26–38. IEEE (2020) 19. Danezis, G., Kokoris-Kogias, L., Sonnino, A., Spiegelman, A.: Narwhal and tusk: a dag-based mempool and efficient BFT consensus. In: Bromberg, Y., Kermarrec, A., Kozyrakis, C. (eds.) EuroSys ’22: Seventeenth European Conference on Computer Systems, Rennes, France, April 5 - 8, 2022. pp. 34–50. ACM (2022) 20. Das, S., Xiang, Z., Ren, L.: Asynchronous data dissemination and its applications. In: Kim, Y., Kim, J., Vigna, G., Shi, E. (eds.) SIGSAC Conference on Computer and Communications Security, CCS. pp. 2705–2721. ACM (2021) 21. Dolev, D.: Unanimity in an unknown and unreliable environment. In: 22nd Annual Symposium on Foundations of Computer Science, Nashville, Tennessee, USA, 28-30 October 1981. pp. 159–168. IEEE Computer Society (1981) 22. Duvignau, R., Raynal, M., Schiller, E.M.: Self-stabilizing Byzantine fault-tolerant repeated reliable broadcast. Theor. Comput. Sci. 972, 114070 (2023) 23. Jansen, R., Newsome, J., Wails, R.: Co-opting linux processes for high-performance network simulation. In: Schindler, J., Zilberman, N. (eds.) Proceedings of the 2022 USENIX Annual Technical Conference, USENIX ATC 2022, Carlsbad, CA, USA, July 11-13, 2022. pp. 327–350. USENIX Association (2022) 24. Jansen, R., et al.: The Shadow simulator, https://shadow.github.io/docs/guide/ 25. Kullberg, J., Persson, F.P.: Evaluating Byzantine reliable broadcast algorithms (2026), https://github.com/fabianPag/brb-eval 26. Locher, T.: Byzantine reliable broadcast with low communication and time complexity. In: Bonomi, S., Galletta, L., Rivière, E., Schiavoni, V. (eds.) 28th International Conference on Principles of Distributed Systems OPODIS. LIPIcs, vol. 324, pp. 16:1–16:17. Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2024)

Reliable Broadcast Benchmarking

27. Locher, T.: Efficient Byzantine reliable broadcast in the failure case. In: Arusoaie, A., Onica, E., Spear, M., Piergiovanni, S.T. (eds.) 29th International Conference on Principles of Distributed Systems OPODIS. LIPIcs, vol. 361, pp. 12:1–12:20. Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2025) 28. Locher, T., Shoup, V.: Improving the round complexity of minicast. IACR Cryptol. ePrint Arch. 2025, 779 (2025) 29. Locher, T., Shoup, V.: Minicast: Minimizing the communication complexity of reliable broadcast. In: Fehr, S., Fouque, P. (eds.) Advances in Cryptology - EUROCRYPT 2025 - 44th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Madrid, Spain, May 4-8, 2025, Proceedings, Part V. Lecture Notes in Computer Science, vol. 15605, pp. 96–115. Springer (2025) 30. Miller, A., Xia, Y., Croman, K., Shi, E., Song, D.: The honey badger of BFT protocols. In: Weippl, E.R., Katzenbeisser, S., Kruegel, C., Myers, A.C., Halevi, S. (eds.) Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016. pp. 31–42. ACM (2016) 31. Neto, J.M.L., Ozkan, B.K.: A benchmark framework for Byzantine fault tolerance testing algorithms (tool paper). In: Marmsoler, D., Xu, M. (eds.) 6th International Workshop on Formal Methods for Blockchains, FMBC 2025, Hamilton, Canada, May 4, 2025. pp. 13:1–13:11. OASIcs, Schloss Dagstuhl - Leibniz-Zentrum für Informatik (2025) 32. Picaud, T., Albouy, T.: mbrb-rs: Rust implementation of message-adversarytolerant Byzantine reliable broadcast. https://gitlab.inria.fr/WIDE/mbrb-rs/ (2021), research implementation artifact 33. Post, K., et al.: klauspost/reedsolomon: v1.13.3 (2026), https://github.com/ klauspost/reedsolomon 34. Raynal, M.: Fault-Tolerant Message-Passing Distributed Systems - An Algorithmic Approach. Springer (2018) 35. Singh, A., Das, T., Maniatis, P., Druschel, P., Roscoe, T.: BFT protocols under fire. In: Crowcroft, J., Dahlin, M. (eds.) 5th USENIX Symposium on Networked Systems Design & Implementation, NSDI 2008, April 16-18, 2008, San Francisco, CA, USA, Proceedings. pp. 189–204. USENIX Association (2008) 36. Wan, J., Momose, A., Ren, L., Shi, E., Xiang, Z.: On the amortized communication complexity of Byzantine broadcast. In: Oshman, R., Nolin, A., Halldórsson, M.M., Balliu, A. (eds.) Proceedings of the 2023 ACM Symposium on Principles of Distributed Computing, PODC 2023, Orlando, FL, USA, June 19-23, 2023. pp. 253–261. ACM (2023) 37. Wang, J., Zhang, B., Wang, K., Wang, Y., Han, W.: Bftdiagnosis: An automated security testing framework with malicious behavior injection for BFT protocols. Comput. Networks 249, 110404 (2024) 38. Winter, L.N., Buse, F., de Graaf, D., von Gleissenthall, K., Ozkan, B.K.: Randomized testing of Byzantine fault tolerant algorithms. Proc. ACM Program. Lang. 7(OOPSLA1), 757–788 (2023) 39. Wu, Y., Pan, H., Kumar, S., Tseng, L.: Reliable broadcast in practical networks: Algorithm and evaluation. CoRR abs/2007.14990 (2020)

Record · ID 667992 · SHA-256 c01f8a718f1a340f
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.