Nakamoto Consensus under Bounded Processing Capacity

TL;DR

A new analysis technique is developed to prove a refined security--performance tradeoff for PoW NC in a bounded-capacity model, and it is shown that, in contrast to the classic bounded-delay model, Nakamoto's private attack is no longer the worst attack, and a new attack, that exploits congestion, is strictly worse.

Abstract

For Nakamoto's longest-chain consensus protocol, whose proof-of-work (PoW) and proof-of-stake (PoS) variants power major blockchains such as Bitcoin and Cardano, we revisit the classic problem of the security-performance tradeoff: Given a network of nodes with finite communication- and computation-resources, against what fraction of adversary power is Nakamoto consensus (NC) secure for a given block production rate? State-of-the-art analyses of NC fail to answer this question, because their bounded-delay model does not capture the rate limits to nodes' processing of blocks, which cause congestion when blocks are released in quick succession. We develop a new analysis technique to prove a refined security-performance tradeoff for PoW NC in a bounded-capacity model. In this model, we show that, in contrast to the classic bounded-delay model, Nakamoto's private attack is no longer the worst attack, and a new attack we call the teasing strategy, that exploits congestion, is strictly worse. In PoS, equivocating blocks can exacerbate congestion, making traditional PoS NC insecure except at very low block production rates. To counter such equivocation spamming, we present a variant of PoS NC we call Blanking NC (BlaNC), which achieves the same resilience as PoW NC.

Figures (18)

• Figure 1: Regions of fraction $\beta$ of adversary nodes and block production rate $\lambda$ with security proofs () and attacks () for NC under a fixed processing capacity of $C=1$ block per second. Analysis in the bounded-delay model dem20tight_bitcoin (with $\Delta = 1\;\mathrm{s}$) proves that the private attack (\ref{['leg:comparison-bddelay-bdbandwidth-privateattack']}) succeeds () iff $\beta \geq \frac{1-\beta}{1+(1-\beta)\lambda}$, and that for all other values of $\beta,\lambda$, no attack succeeds (). Our teasing strategy exploits congested block processing and succeeds at lower adversary $\beta$ than the private attack (, ). Our analysis in a bounded-capacity model yields a security region () for PoW NC.
• Figure 2: For cautiously parameterized PoW NC (e.g., Bitcoin's $\lambda = 1/600\;\mathrm{blocks/s}$, block size $4\;\mathrm{MB}$, recommended min. per-node bandwidth $0.4\;\mathrm{Mbps}$bitcoin_requirementsDBLP:conf/fc/CromanDEGJKMSSS16), earlier analyses assuming bounded delay (\ref{['leg:bitcoin-cardano-resilience-bandwidth-pow-bd']}) predicted security against any adversary controlling up to 48% of hash power (\ref{['leg:bitcoin-cardano-resilience-bandwidth-pow-bd-mark']}), including Nakamoto's private attack nakamoto_paper, which was concluded to be worst-case. The teasing strategy still requires $46\%$ adversary (\ref{['leg:bitcoin-cardano-resilience-bandwidth-pow-teaser']}a, \ref{['leg:bitcoin-cardano-resilience-bandwidth-pow-teaser-mark']}). In contrast, PoW NC parameterized ambitiously (e.g., Bitcoin Cash's same $\lambda$, but max. block size $32\;\mathrm{MB}$, same bandwidth bitcoin_cash_requirements) withstands only a $37\%$ private attacker (\ref{['leg:bitcoin-cash-resilience-bandwidth-pow-bd-mark']}), while the teasing strategy resilience drops to $27\%$ (\ref{['leg:bitcoin-cash-resilience-bandwidth-pow-teaser-mark']}).
• Figure 3: The region of fraction $\beta$ of adversary nodes and block production rate $\lambda$ where PoS NC is secure according to bwlimitedposlc () shrinks as the NC confirmation depth increases, i.e., the desired consensus failure probability decreases (in order: to ). Thus, for the PoS NC protocol of bwlimitedposlc, security requires vanishing throughput. In contrast, our new BlaNC protocol achieves a security region () that is independent of the desired consensus failure probability. Thus, BlaNC is secure with non-vanishing constant throughput. (For all lines, processing capacity is fixed to $C=1$ block/s.)
• Figure 4: (a) Sleepy analysis sleepy is based on pivots. Pivots are special honest blocks ($\Rightarrow$ liveness) which by a combinatorial argument remain in the chain forever ($\Rightarrow$ safety), and by a probabilistic argument happen frequently. Equivalence of the pivot qualities required for each of both arguments follows from bounded delay DBLP:journals/iacr/BentovPS16. The bounded-capacity analysis of bwlimitedposlc also follows the same procedure by choosing a large enough delay parameter. (b) We (red) decompose pivots' probabilistic vs. combinatorial qualities into ppivots vs. cpivots. These are no longer equivalent under bounded capacity, but of many consecutive ppivots one is a cpivot (new combinatorial argument), and ppivots are abundant (new probabilistic argument).
• Figure 5: Private attack (recap): Based on the tip of the longest chain when the private attack starts, the adversary mines a privateadversary chain, while honest nodes jointly grow a publichonest chain. The adversary's goal is to deconfirm a transaction $\mathsf{tx}$ included on the honest chain just below where the adversary chain forks off. Adversary mining is perfectly coordinated so that the adversary chain grows at the adversary block production rate $\lambda_{\mathrm{adv}}$. Honest nodes suffer from forking due to network delay so that the honest chain grows at a lower rate $\lambda_{\mathrm{grwth}} < \lambda_{\mathrm{hon}}$ than the total block production rate $\lambda_{\mathrm{hon}}$ of honest nodes. The attack succeeds if the adversary chain grows faster than the honest chain ($\lambda_{\mathrm{adv}} > \lambda_{\mathrm{grwth}}$) and thus, irrespective of the confirmation depth $k_{\mathrm{conf}}$ chosen for NC, the adversary chain can eventually displace the honest chain as the longest chain and with that deconfirm $\mathsf{tx}$.

Theorems & Definitions (53)

• definition 1
• proposition 1
• definition 2
• definition 3
• proposition 2: Formal version: \ref{['prop:chain-growth']}
• lemma 1: Formal version: \ref{['lem:cps-stabilize']}
• lemma 2: Formal version: \ref{['lem:many-pps']}
• proposition 3
• proof
• lemma 3: Formal version: \ref{['lem:many-pps-one-cps']}