Oracular Byzantine Reliable Broadcast [Extended Version]

TL;DR

This paper introduces Draft, an optimal resilient implementation of Client-Server Byzantine Reliable Broadcast that guarantees safety and liveness, achieving near-zero signature verification costs and minimal communication overhead in ideal conditions.

Contribution

Draft is the first implementation of CSB that is both optimally resilient and highly efficient, minimizing signature verifications and communication in asynchronous environments.

Findings

Draft achieves zero signature verifications in ideal conditions.

Communication cost approaches the information-theoretic minimum.

Draft guarantees safety and liveness in asynchronous Byzantine settings.

Abstract

Byzantine Reliable Broadcast (BRB) is a fundamental distributed computing primitive, with applications ranging from notifications to asynchronous payment systems. Motivated by practical consideration, we study Client-Server Byzantine Reliable Broadcast (CSB), a multi-shot variant of BRB whose interface is split between broadcasting clients and delivering servers. We present Draft, an optimally resilient implementation of CSB. Like most implementations of BRB, Draft guarantees both liveness and safety in an asynchronous environment. Under good conditions, however, Draft achieves unparalleled efficiency. In a moment of synchrony, free from Byzantine misbehaviour, and at the limit of infinitely many broadcasting clients, a Draft server delivers a $b$-bits payload at an asymptotic amortized cost of $0$ signature verifications, and $\log_2(c) + b$ bits exchanged, where $c$ is the number of clients in the system. This is the information-theoretical minimum number of bits required to convey the payload ($b$ bits, assuming it is compressed), along with an identifier for its sender ($\log_2(c)$ bits, necessary to enumerate any set of $c$ elements, and optimal if broadcasting frequencies are uniform or unknown). These two achievements have profound practical implications. Real-world BRB implementations are often bottlenecked either by expensive signature verifications, or by communication overhead. For Draft, instead, the network is the limit: a server can deliver payloads as quickly as it would receive them from an infallible oracle.