Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults
By Allen Clement, Edmund L. Wong, Lorenzo Alvisi, M. Dahlin, Mirco Marchetti. Symposium on Networked Systems Design and Implementation, 2009
514 citations recorded by the source corpus.
View Paper: https://www.semanticscholar.org/paper/a5d450963c754ce7a755de8285aa4218924c4790
How researchers see this paper
The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.
- Eleftherios Kokoris-Kogias
- Christian Cachin
- Srinath T. V. Setty
- Elaine Shi
- Yang Xiao
- Guy Golan-Gueta
- Benny Pinkas
- Dan Boneh
Citations in the corpus
- SBFT: A Scalable and Decentralized Trust Infrastructure (2018, methodology): “Following [26], SBFT uses public-key signed client requests and server messages.”
- Zyzzyva: Speculative Byzantine fault tolerance (2009, methodology): “All protocols are guaranteed to operate correctly in the presence of up to f faults and arbitrary delays, but they can pay signi.cantly higher overheads and latencies in such scenarios [Clement et al. 2009b].”
- RBFT: Redundant Byzantine Fault Tolerance (2013, methodology): “Although signatures are an order of magnitude more costly than MACs, they are necessary to prevent certain attacks [7].”
- The latest gossip on BFT consensus (2018, background): “Therefore, there is only a single mode of execution in Tendermint, i.e., there is no separation between the normal and the recovery mode, which is the case in other PBFT-like protocols (e.g., [8], [12] or [13]).”
- Blockchain Consensus Protocols in the Wild (2017, background): “Many research works have analyzed and improved aspects of it and made it more robust in prototypes [27].”
- Architecture of the Hyperledger Blockchain Fabric (2016, background): “The PBFT protocol [4] has been implemented as the first one in the fabric because of its prominence: it benefits from the experience of almost 20 years of systems-level research on Byzantine consensus, is closely related to well-known protocols like viewstamped replication and Paxos [7], has been an”
- State Machine Replication for the Masses with BFT-SMART (2014, background): “However, the system can be easily extended to support periodic leader changes to limit such damage [3].”
- A Survey of Distributed Consensus Protocols for Blockchain Networks (2019, background): “While in popular BFT-SMR schemes such as PBFT execution is integrated into the consensus process.”
- The Next 700 BFT Protocols (2015, methodology): “Finally, a third robust protocol that has been designed is Aardvark [Clement et al. 2009], also based on PBFT.”
- Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing (2016, background): “Like many BFT protocols in practice [15, 32], ByzCoin is vulnerable to slowdown or temporary DoS attacks that Byzantine nodes can trigger.”
- Security and Privacy for Green IoT-Based Agriculture: Review, Blockchain Solutions, and Challenges (2020, methodology): “Note that there are more variations of PBFT algorithm such as Aardvark [128], Zyzzyva [129], HQ [130], Q/U [131], and Abstract [132].”
- Depot: Cloud Storage with Minimal Trust (2010, background): “For example, quorum and replicated state machine approaches [Castro and Liskov 2002; Clement et al. 2009; Guerraoui et al. 2010] tolerate failures by a fraction of servers.”
- Algorand: Scaling Byzantine Agreements for Cryptocurrencies (2017, background): “Follow-on work has shown how to make Byzantine fault tolerance perform well and scale to dozens of servers [1, 17, 33].”
- The Honey Badger of BFT Protocols (2016, methodology): “[22] initiated a recent line of work [4, 6, 10, 21, 22, 50] by advocating improvement of the worst-case performance, providing service quality guarantees even when the system is under attack — even if this comes at the expense of performance in the optimistic case.”
- The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication (2015, unknown): “In contrast, modern BFT protocols have been confirmed to sustain tens of thousands of transactions with practically network-speed latencies, not only as prototypes (e.g., [35, 12, 3]) but also as practical systems [5].”