Trebiz: Byzantine Fault Tolerance with Byzantine Merchants

Dai, Xiaohai; Liping, Huang; Xiao, Jiang; Zhang, Zhaonan; Xie, Xia; Jin, Hai

doi:10.1145/3564625.3567976

Cited by 8 publications

(2 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Multi-threshold BFT [1] argues that some applications prefer a higher safety resilience than liveness resilience (t S ≥ t L ). The same problem is stated from another point of view in [3], [5], [14], [40], [41]: 'rational' adversaries may choose to attack safety but not liveness (cf. alivebut-corrupt faults [14], deceitful faults [5], Byzantine merchants [41]) because an adversary can expect sizeable profits from double spends by attacking safety, but stands to gain little and instead lose protocol rewards if it were to attack liveness.…”

Section: Related Workmentioning

confidence: 99%

“…The same problem is stated from another point of view in [3], [5], [14], [40], [41]: 'rational' adversaries may choose to attack safety but not liveness (cf. alivebut-corrupt faults [14], deceitful faults [5], Byzantine merchants [41]) because an adversary can expect sizeable profits from double spends by attacking safety, but stands to gain little and instead lose protocol rewards if it were to attack liveness. Tolerating alive-but-corrupt adversaries in addition to Byzantine adversaries is then equivalent to having a higher safety resilience than liveness resilience.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

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