The Availability-Accountability Dilemma and Its Resolution via Accountability Gadgets

Neu, Joachim; Tas, Ertem Nusret; Tse, David

doi:10.1007/978-3-031-18283-9_27

Cited by 12 publications

(7 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Given the flexible consensus problem, it is natural to ask: What is the 'maximum' flexibility a protocol can provide? The classic impossibility result 2t L k + t S k ≤ 1 [12], [13] shows that we cannot hope to do better than for each client to achieve a resilience pair (t L k , t S k ) on the straight line between (0, 1) and ( 13 , 1 3 ), shown in Fig. 1 ( ).…”

Section: Quest For Optimal Flexible Consensusmentioning

confidence: 99%

“…Multi-threshold consensus: Multi-threshold Byzantine fault tolerance [1], [2], [3], [4] can be viewed as a degenerate case of flexible consensus in which all clients have the same resilience pair (t L , t S ) which may be different from ( 13 , 1 3 ). This is done for SMR consensus in [1], [4] and for reliable broadcast in [1], [2], [3].…”

Section: Related Workmentioning

confidence: 99%

“…The works [4], [9], [30], [60], [61], [62], [63], [64], [65] strengthen consensus protocols' safety property to accountable safety, which guarantees safety if few replicas deviate from the protocol, and if safety is ever violated, then a sizable number of replicas are identified to have provably violated the protocol. Our OFlex protocols provide flexible accountable safety: if two clients k, k ′ confirm inconsistent logs (a safety violation), then at least (t S k + t S k ′ )/2 replicas must have provably violated the protocol (see Sec.…”

Section: Flexible Accountable Safetymentioning

confidence: 99%

“…Byzantine-fault tolerant (BFT) consensus protocols guarantee these properties if the fraction f of adversary replicas out of all n replicas is not too large, where adversary replicas may deviate from the protocol in any arbitrary and coordinated fashion, and nonadversary honest replicas follow the protocol as specified. 1 Based on terminology of [1], [2], [3], [4], [5], a protocol's safety resilience t S is defined as the maximum fraction of adversary replicas the protocol can tolerate while still JN, SS, LY are listed alphabetically.…”

Section: Introduction 1flexible Consensusmentioning

confidence: 99%

“…However, users (i.e., clients) of a system may not desire equal resilience to safety and liveness faults [1], [2], [3], [4], [5]. In fact, different clients may prefer different (liveness-/safety-)resilience pairs altogether [14], [15]!…”

Section: Introduction 1flexible Consensusmentioning

confidence: 99%

See 4 more Smart Citations

Longest Chain Consensus Under Bandwidth Constraint

Neu

Sridhar

Yang

et al. 2022

Proceedings of the 4th ACM Conference on Advances in Financial Technologies

View full text Add to dashboard Cite

Classic BFT consensus protocols guarantee safety and liveness for all clients if fewer than one-third of replicas are faulty. However, in applications such as high-value payments, some clients may want to prioritize safety over liveness. Flexible consensus allows each client to opt for a higher safety resilience, albeit at the expense of reduced liveness resilience. We present the first construction that allows optimal safety-liveness tradeoff for every client simultaneously. This construction is modular and is realized as an add-on applied on top of an existing consensus protocol. The add-on consists of an additional round of voting and permanent locking done by the replicas, to sidestep a sub-optimal quorum-intersection-based constraint present in previous solutions. We adapt our construction to the existing Ethereum protocol to derive optimal flexible confirmation rules that clients can adopt unilaterally without requiring systemwide changes. This is possible because existing Ethereum protocol features can double as the extra voting and locking. We demonstrate an implementation using Ethereum's consensus API.

show abstract

Section: Quest For Optimal Flexible Consensusmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Flexible Accountable Safetymentioning

confidence: 99%

Section: Introduction 1flexible Consensusmentioning

confidence: 99%

Section: Introduction 1flexible Consensusmentioning

confidence: 99%

See 3 more Smart Citations

Longest Chain Consensus Under Bandwidth Constraint

Neu

Sridhar

Yang

et al. 2022

Proceedings of the 4th ACM Conference on Advances in Financial Technologies

View full text Add to dashboard Cite

show abstract

Scaling Blockchains and the Case for Ethereum

Asgaonkar¹

2022

Handbook on Blockchain

View full text Add to dashboard Cite

A Confirmation Rule, within blockchain networks, refers to an algorithm implemented by network nodes that determines (either probabilistically or deterministically) the permanence of certain blocks on the blockchain. An example of Confirmation Rule is the Bitcoin's longest chain Confirmation Rule where a block b is confirmed (with high probability) when it has a sufficiently long chain of successors, its siblings have notably shorter successor chains, and network synchrony holds.In this work, we devise a Confirmation Rule for Ethereum's consensus protocol, Gasper. Initially, our focus is on developing a rule specifically for LMD-GHOST-the component of Gasper responsible for ensuring dynamic availability. This is done independently of the influence of FFG-Casper, which is designed to finalize the blocks produced by LMD-GHOST. Subsequently, we build upon this rule to consider FFG-Casper's impact, aiming to achieve fast block confirmations through a heuristic that balances confirmation speed with a trade-off in safety guarantees. This refined Confirmation Rule could potentially standardize fast block confirmation within Gasper. * Work done while at the Ethereum Foundation. † Work done while at Consensys.Gossiping. We assume that any honest validator immediately gossip (i.e., broadcast) any message that they receive.View. Thew view of a validator corresponds to the set of all the messages that the validator has received. More specifically, we use V v,t to denote the set of all messages received by validator v at time t. GasperGasper is a proof-of-stake consensus protocol made of two components [18], namely LMD-GHOST-HFC and FFG-Casper [7]. The former is a synchronous consensus protocol that works under dynamic participation and outputs a canonical chain, while the latter is a partially synchronous protocol, also referred to as finality gadget, whose role is to finalize blocks in the canonical chain and preserve safety of such finalized blocks during asynchronous periods. In the following, we summarise the concepts and properties pertaining to Gasper that are need in the remaining part of this work. Time and Slots. Time is organized into a consecutive sequence of slots. We denote the time at which a slot s begins with st(s), and use slot(t) to denote the slot associated with time t, i.e., slot(t) = s implies that t ∈ [st(s), st(s + 1)). Epochs. A sequence of E consecutive slots forms an epoch where E ≥ 2. Epochs are numbered starting from 0. We use first slot(e) and last slot(e) to denote the first slot and last slot of epoch e, respectively, i.e., first slot(e) := eE and last slot(e) := (e + 1)E − 1. We write epoch(s) for the epoch associated with slot s, i.e., epoch(s) = e implies s ∈ [first slot(e), last slot(e)]. Also we define epoch(t) := epoch(slot(t)). Finally, we let st(e) := st(first slot(e)).Validator Sets and Committees. According to the view of an honest validator v at time t, only a finite subset of all the validators are active for each epoch e. We denote such set as Ŵe,v,t and refer to it as the valdiat...

show abstract