Fast TetraBFT: Optimizing Latency Where It Matters

2026-06-02

AI Summary

In partially synchronous networks, existing authentication-free Byzantine consensus protocols often struggle to simultaneously achieve low latency in the good case and design simplicity. This work proposes a lightweight fast-path wrapper applied to the TetraBFT protocol, reducing its decision latency in the good case from five rounds to the theoretically optimal three rounds—without increasing communication complexity or space overhead. The study demonstrates that optimal latency can be attained without resorting to intricate mechanisms, thereby significantly enhancing the protocol’s practical efficiency and deployability.

Abstract

Unauthenticated Byzantine consensus protocols achieve optimal failure resilience while relying only on authenticated point-to-point channels, not authenticated messages. They are an attractive building block for blockchains that do not mandate symmetric trust assumptions as well as for future post-quantum settings. We consider unauthenticated Byzantine consensus in partially synchronous networks and focus on optimizing its good-case latency - the worst-case time for correct processes to reach a decision under favorable conditions. A recently proposed ForgetIT protocol achieves an optimal good-case latency of 3 message delays but employs a highly complex design. We show that this complexity is unnecessary. To this end, we present Fast TetraBFT - an unauthenticated Byzantine consensus protocol that achieves optimal good-case latency by augmenting an existing TetraBFT protocol with a simple fast-path wrapper. Our solution lowers the good-case latency of TetraBFT from 5 to 3 message delays while preserving its bounded space requirements and low communication complexity.

Problem

• unauthenticated Byzantine consensus
• good-case latency
• partially synchronous networks
• message delays
• blockchain

Innovation

• unauthenticated Byzantine consensus
• good-case latency
• Fast TetraBFT
• partially synchronous networks
• message delay