232 research outputs found
Liveness Checking of the HotStuff Protocol Family
Byzantine consensus protocols aim at maintaining safety guarantees under any
network synchrony model and at providing liveness in partially or fully
synchronous networks. However, several Byzantine consensus protocols have been
shown to violate liveness properties under certain scenarios. Existing testing
methods for checking the liveness of consensus protocols check for time-bounded
liveness violations, which generate a large number of false positives. In this
work, for the first time, we check the liveness of Byzantine consensus
protocols using the temperature and lasso detection methods, which require the
definition of ad-hoc system state abstractions. We focus on the HotStuff
protocol family that has been recently developed for blockchain consensus. In
this family, the HotStuff protocol is both safe and live under the partial
synchrony assumption, while the 2-Phase Hotstuff and Sync HotStuff protocols
are known to violate liveness in subtle fault scenarios. We implemented our
liveness checking methods on top of the Twins automated unit test generator to
test the HotStuff protocol family. Our results indicate that our methods
successfully detect all known liveness violations and produce fewer false
positives than the traditional time-bounded liveness checks.Comment: Preprint of a paper accepted at IEEE PRDC 202
Practical View-Change-Less Protocol through Rapid View Synchronization
The emergence of blockchain technology has renewed the interest in
consensus-based data management systems that are resilient to failures. To
maximize throughput of these systems, we have recently seen several prototype
consensus solutions that optimize for throughput at the expense of overall
implementation complexity, high costs, and reliability. Due to this, it remains
unclear how these prototypes will perform in real-world environments. In this
paper, we present the Practical View-Change-Less Protocol PVP, a
high-throughput, simple, and reliable consensus protocol. Central to PVP is the
combination of (1) a chained consensus design for replicating requests with a
reduced message cost; (2) the novel Rapid View Synchronization protocol that
enables robust and low-cost failure recovery; and (3) a high-performance
concurrent consensus architecture in which independent instances of the chained
consensus operate concurrently to process requests with high throughput and
without single-replica bottlenecks. Due to the concurrent consensus
architecture, PVP greatly outperforms traditional primary-backup consensus
protocols such as PBFT (by up to 430%), Narwhal (by up to 296%), and HotStuff
(by up to 3803%). Due to its reduced message cost, PVP is even able to
outperform RCC, a state-of-the-art high-throughput concurrent consensus
protocol, by up to 23%. Furthermore, PVP is able to maintain a stable and low
latency and consistently high throughput even during failures.Comment: 16 pages, 14 figure
When is Spring coming? A Security Analysis of Avalanche Consensus
Avalanche is a blockchain consensus protocol with exceptionally low latency
and high throughput. This has swiftly established the corresponding token as a
top-tier cryptocurrency. Avalanche achieves such remarkable metrics by
substituting proof of work with a random sampling mechanism. The protocol also
differs from Bitcoin, Ethereum, and many others by forming a directed acyclic
graph (DAG) instead of a chain. It does not totally order all transactions,
establishes a partial order among them, and accepts transactions in the DAG
that satisfy specific properties. Such parallelism is widely regarded as a
technique that increases the efficiency of consensus.
Despite its success, Avalanche consensus lacks a complete abstract
specification and a matching formal analysis. To address this drawback, this
work provides first a detailed formulation of Avalanche through pseudocode.
This includes features that are omitted from the original whitepaper or are
only vaguely explained in the documentation. Second, the paper gives an
analysis of the formal properties fulfilled by Avalanche in the sense of a
generic broadcast protocol that only orders related transactions. Last but not
least, the analysis reveals a vulnerability that affects the liveness of the
protocol. A possible solution that addresses the problem is also proposed
- …