Revisiting Fast Practical Byzantine Fault Tolerance
arXiv:1712.01367
Abstract
In this note, we observe a safety violation in Zyzzyva and a liveness violation in FaB. To demonstrate these issues, we require relatively simple scenarios, involving only four replicas, and one or two view changes. In all of them, the problem is manifested already in the first log slot.
Cited by in corpus (17)
- ResilientDB: Global Scale Resilient Blockchain Fabric
- The Consensus Number of a Cryptocurrency (Extended Version)
- The Istanbul BFT Consensus Algorithm
- Blockchain Transaction Processing
- Mir-BFT: High-Throughput Robust BFT for Decentralized Networks
- Proof-of-Execution: Reaching Consensus through Fault-Tolerant Speculation
- Formalizing Nakamoto-Style Proof of Stake
- Aleph: Efficient Atomic Broadcast in Asynchronous Networks with Byzantine Nodes
- AT2: Asynchronous Trustworthy Transfers
- FnF-BFT: Exploring Performance Limits of BFT Protocols
- Online Payments by Merely Broadcasting Messages (Extended Version)
- Brief Note: Fast Authenticated Byzantine Consensus
- Can 100 Machines Agree?
- No Need for Recovery: A Simple Two-Step Byzantine Consensus
- Verification of Threshold-Based Distributed Algorithms by Decomposition to Decidable Logics
- Revisiting Optimal Resilience of Fast Byzantine Consensus (Extended Version)
- Que Sera Consensus: Simple Asynchronous Agreement with Private Coins and Threshold Logical Clocks