PlasmaBFT

PlasmaBFT is an efficient and secure implementation of a Fast HotStuff-style consensus, written in Rust. It inherits HotStuff’s core design while optimizing for even lower latency by using a two-chain commit in the common case—often referred to as the fast path. This approach demonstrates that HotStuff’s additional third phase is not always necessary, as consensus can frequently be reached in just two rounds. This reduction in communication steps lowers commit latencies while preserving the desirable properties of linearity and responsiveness.

Practically, PlasmaBFT finalizes blocks in fewer communication steps when the leader is honest and the network is responsive, while remaining safe against adversarial behavior. It operates under classic BFT security assumptions:

$$n \geq 3f + 1,\quad q = 2f + 1,\quad f = \left\lfloor \frac{n - 1}{3} \right\rfloor$$

where n is the number of replicas, f is the number of Byzantine nodes, and q is the required quorum size. This means that PlasmaBFT remains secure when no more than 33% of validators are malicious.

Our system achieves high throughput—processing many thousands of transactions per second in benchmarks—and serves as an essential foundation for a stablecoin-optimized protocol. We chose Rust for its performance and safety guarantees, ensuring robustness and efficiency even under heavy workloads.

We rely on Quorum Certificates (QCs) at every step. In the happy path, when a newly proposed block builds directly on its predecessor, the QCs alone establish correctness while benefiting from the efficiency of signature aggregation. This mechanism also enables rapid finality; once a 2-chain is formed, the block can be immediately finalized as consecutive quorums have certified its correctness.

$$QC(b_{v}) \leftarrow QC(b_{v+1}) \leftarrow QC(b_{v+2}) \leftarrow \dots$$

We additionally make use of pipelining to improve throughput. Under pipelining, while the previous round continues through the precommit and commit phases, newer proposals continue in parallel:

In the event of a leader failure or view change, aggregated QCs (AggQCs) come into play. When a view change occurs, validators forward their most recent QC to the new leader, who then combines these into an AggQC. This process prevents the new leader from equivocating about the highest block observed, effectively certifying the state through an additional layer of aggregation. Importantly, these differ from the threshold signatures used in HotStuff because only two signatures need to be validated under this case.

Other approaches, such as Jolteon and Ditto—proposed by Gelashvili et al.—rely on a similar yet slightly different methodology. Instead of relying on AggQCs, these methods use timeout certificates (TCs) to advance the committee by eliminating gaps caused by view changes.