Table of Contents
Fetching ...

Consensus Under Adversary Majority Done Right

Srivatsan Sridhar, Ertem Nusret Tas, Joachim Neu, Dionysis Zindros, David Tse

TL;DR

This work resolves apparent contradictions around adversary-majority resilience in Byzantine SMR by focusing on a detailed, four-dimensional client- and network-model space. It provides a complete characterization of safety and liveness resiliences across sixteen models formed by variations in client activity (sleepy vs always-on), interactivity (silent vs communicating), validator sleepiness, and network synchrony. The authors introduce new protocols (e.g., freezing gadgets, certifiable safety frameworks, and modified fork-choice rules) and impossibility results, demonstrating when high resilience is achievable and when it is not, both in synchronous and partially synchronous settings. The results have practical implications for permissioned and hybrid blockchain systems, showing how client behavior and communication assumptions fundamentally shape safety-liveness trade-offs and enabling more robust liveness guarantees without sacrificing safety under adversary majority.

Abstract

A specter is haunting consensus protocols--the specter of adversary majority. Dolev and Strong in 1983 showed an early possibility for up to 99% adversaries. Yet, other works show impossibility results for adversaries above 50% under synchrony, seemingly the same setting as Dolev and Strong's. What gives? It is high time that we pinpoint a key culprit for this ostensible contradiction: the modeling details of clients. Are the clients sleepy or always-on? Are they silent or communicating? Can validators be sleepy too? We systematize models for consensus across four dimensions (sleepy/always-on clients, silent/communicating clients, sleepy/always-on validators, and synchrony/partial-synchrony), some of which are new, and tightly characterize the achievable safety and liveness resiliences with matching possibilities and impossibilities for each of the sixteen models. To this end, we unify folklore and earlier results, and fill gaps left in the literature with new protocols and impossibility theorems.

Consensus Under Adversary Majority Done Right

TL;DR

This work resolves apparent contradictions around adversary-majority resilience in Byzantine SMR by focusing on a detailed, four-dimensional client- and network-model space. It provides a complete characterization of safety and liveness resiliences across sixteen models formed by variations in client activity (sleepy vs always-on), interactivity (silent vs communicating), validator sleepiness, and network synchrony. The authors introduce new protocols (e.g., freezing gadgets, certifiable safety frameworks, and modified fork-choice rules) and impossibility results, demonstrating when high resilience is achievable and when it is not, both in synchronous and partially synchronous settings. The results have practical implications for permissioned and hybrid blockchain systems, showing how client behavior and communication assumptions fundamentally shape safety-liveness trade-offs and enabling more robust liveness guarantees without sacrificing safety under adversary majority.

Abstract

A specter is haunting consensus protocols--the specter of adversary majority. Dolev and Strong in 1983 showed an early possibility for up to 99% adversaries. Yet, other works show impossibility results for adversaries above 50% under synchrony, seemingly the same setting as Dolev and Strong's. What gives? It is high time that we pinpoint a key culprit for this ostensible contradiction: the modeling details of clients. Are the clients sleepy or always-on? Are they silent or communicating? Can validators be sleepy too? We systematize models for consensus across four dimensions (sleepy/always-on clients, silent/communicating clients, sleepy/always-on validators, and synchrony/partial-synchrony), some of which are new, and tightly characterize the achievable safety and liveness resiliences with matching possibilities and impossibilities for each of the sixteen models. To this end, we unify folklore and earlier results, and fill gaps left in the literature with new protocols and impossibility theorems.

Paper Structure

This paper contains 36 sections, 26 theorems, 6 figures, 6 algorithms.

Key Result

theorem 1

In a synchronous network with always-on validators and always-on silent clients, no protocol can achieve resiliences $(t^{\mathrm{L}},t^{\mathrm{S}})$ such that $t^{\mathrm{L}}+t^{\mathrm{S}} \geq 1$.

Figures (6)

  • Figure 1: Tight achievable () and impossible () safety resilience $t^{\mathrm{S}}$ and liveness resilience $t^{\mathrm{L}}$ bounds for different models (cf. \ref{['fig:models-hierarchy']}), each with four aspects: Network delay: synchrony vs. partial synchrony ; Validator sleepiness: always-on validators $\text{\notoemoji[height=1em]{desktop computer}}^{\text{!!!}}$ vs. sleepy validators $\text{\notoemoji[height=1em]{desktop computer}}^{\text{zZ}}$; Client sleepiness: always-on clients $\text{\notoemoji[height=1em]{person}}^{\text{!!!}}$ vs. sleepy clients $\text{\notoemoji[height=1em]{person}}^{\text{zZ}}$; Client interactivity: communicating $\text{\notoemoji[height=1em]{person}}_{}$ vs. silent $\text{\notoemoji[height=1em]{person}}_{}$. Citations with corollaries, or theorems, indicate previously known, or new results, respectively.
  • Figure 2: Hasse diagram illustrating the relative difficulty of consensus in all the different models we study (proof: \ref{['lem:hierarchy']}). Each small white box indicates a different model (see \ref{['fig:resilience-plots']} for icon legend). Models are grouped in a shaded circle when they share validator model and network model but the client model differs. Group $({}, \text{\notoemoji[height=1em]{desktop computer}}^{\text{zZ}}{})$ is faded out because consensus is impossible ebbandflowgilbert-lynch-cap-theorempye-roughgarden-cap-theorem.
  • Figure 3: A family of protocols that achieves any resilience $t^{\mathrm{L}} + t^{\mathrm{S}} < 1$ and $t^{\mathrm{S}} < t^{\mathrm{L}}$ for sleepy silent or always-on silent clients (lower right triangle of \ref{['fig:resilience-sync-sleepy-passive', 'fig:resilience-sync-alert-passive']}). The internal protocol $\Pi_{\mathrm{int}}$ is any SMR protocol achieving all resilience pairs $t^{\mathrm{S}} < 1/2, t^{\mathrm{L}} < 1/2$ for sleepy silent clients (e.g. Sync HotStuff synchotstuff). On receiving transaction $\mathsf{tx}$, validators sign it and broadcast the signature before processing it as an input to $\Pi_{\mathrm{int}}$. A client, on receiving transaction $\mathsf{tx}$ signed by $q > t^{\mathrm{S}} n$ validators, and after waiting $u_{\mathrm{int}}$ rounds (where $u_{\mathrm{int}}$ is the maximum latency of $\Pi_{\mathrm{int}}$), if $\mathsf{tx}$ is not included in the log $L_{\mathrm{int}}$ output by the client from $\Pi$, concatenates $\mathsf{tx}$ to $L_{\mathrm{int}}$ to output the final confirmed log $\pmb{L}_{}^{}$.
  • Figure 4: The freezing protocol $\Pi_{\mathrm{frz}}$ that achieves $t^{\mathrm{L}} < 1/2, t^{\mathrm{S}} = 1$ for sleepy communicating clients. The internal protocol $\Pi_{\mathrm{int}}$ is any certifiable SMR protocol that can achieve all $t^{\mathrm{S}}, t^{\mathrm{L}} < 1/2$. On seeing a log $L_{\mathrm{int}}$ from $\Pi_{\mathrm{int}}$ or the network, the client gossips $L_{\mathrm{int}}$ (formally, the corresponding certificate ), and waits for $\Delta$ rounds. The conflict resolution component remembers the set $\CS$ of all logs it ever received at the input port on its top. On receiving $L$ at the input port on its left, this component outputs $L$ if there were no conflicting logs in $\CS$ (see \ref{['alg:freezing']}\ref{['loc:freezing-check-conflict', 'loc:freezing-output']}).
  • Figure 5: Illustration for the freezing protocol's safety which is maintained during adversary majority (\ref{['thm:freezing-resilience']}). Suppose that at round $r$, a client $p$ outputs a log $L$. The client must have seen $L$ (and its certificate $C certificate\xspace$) either from the internal protocol $\Pi$ or from the network latest by round $r - \Delta$, at which point it must have sent $L$ (and $C certificate\xspace$) to all other clients. Thus, by round $r$, all clients must have seen $L$ and thereafter will never output a log that conflicts with $L$.
  • ...and 1 more figures

Theorems & Definitions (55)

  • definition 1: Safety
  • definition 2: Liveness
  • definition 3: Resilience
  • theorem 1
  • corollary 1
  • corollary 2
  • theorem 2
  • theorem 3
  • definition 4: Certifiable protocol
  • theorem 4
  • ...and 45 more