BlueBottle: Fast and Robust Blockchains through Subsystem Specialization

TL;DR

BlueBottle tackles the blockchain trilemma by layering a fast, low-latency core with a scalable guard layer that enforces accountability. BB-Core reduces fault-tolerance requirements to $n_c\ge 5f_c+1$ and commits in two rounds, achieving sub-second finality and high throughput, while BB-Guard synchronously detects misbehaviors, creates provable blamesets, and recovers to preserve safety and liveness. The system is analyzed rigorously for both safety and liveness under the stated fault and synchrony assumptions, with extensive evaluation showing a $20$-$25\%$ latency reduction over Mysticeti and robust performance under crash faults. An asynchronous variant BB-Core-Async extends the design to fully asynchronous networks using a threshold common coin, preserving safety and liveness and offering trade-offs between latency and fault tolerance. Collectively, BlueBottle demonstrates a practical approach to fast finality at scale, combining rigorous protocol design with empirical validation and a pathway to broader decentralization via BB-Guard.

Abstract

Blockchain consensus faces a trilemma of security, latency, and decentralization. High-throughput systems often require a reduction in decentralization or robustness against strong adversaries, while highly decentralized and secure systems tend to have lower performance. We present BlueBottle, a two-layer consensus architecture. The core layer, BB-Core, is an n=5f+1 protocol that trades some fault tolerance for a much lower finality latency with a medium-sized core validator set. Our experiments show that BB-Core reduces latency by 20-25% in comparison to Mysticeti. The guard layer, BB-Guard, provides decentralized timestamping, proactive misbehavior detection in BB-Core, and a synchronous recovery path. When it observes equivocations or liveness failures in the core -- while tolerating up to f<3n/5 faulty nodes in the primary layer -- guard validators disseminate evidence, agree on misbehaving parties for exclusion or slashing, and either restart the core protocol (for liveness violations) or select a canonical fork (for safety violations). Together, these layers enable optimistic sub-second finality at high throughput while maintaining strong safety and liveness under a mild synchrony assumption.

Figures (4)

• Figure 1: The structure of the BB-Core DAG. Left: A wave consisting of two rounds (Propose and Decision). Right: Wave patterns in the BB-Core protocol (each round initiates a new overlapping wave).
• Figure 2: Example with six validators and two leader slots per round.
• Figure 3: WAN throughput-latency performance comparison of BB-Core ($n=5f+1$) and Mysticeti ($n=3f+1$) with a $512$B transaction size. The y-axis starts at $300$ ms to zoom in on the latency difference between the systems.
• Figure 4: WAN throughput-latency performance comparison of BB-Core ($n=5f+1$), BB-Core-Async ($n=5f+1$), and Mysticeti ($n=3f+1$) with a $512$B transaction size. The y-axis starts at $300$ ms to zoom in on the latency difference between the systems.

Theorems & Definitions (90)

• Lemma 1
• Proof 1
• Lemma 2
• Proof 2
• Lemma 3
• Proof 3
• Corollary 1
• Lemma 4
• Proof 4
• Theorem 1