[Paper] It's not a lie if you don't get caught: simplifying reconfiguration in SMR through dirty logs

Source: arXiv - 2602.09441v1

Overview

State‑machine replication (SMR) is the backbone of many fault‑tolerant services—from distributed databases to blockchains. While consensus algorithms (e.g., Raft, Paxos, HotStuff) get most of the research spotlight, the reconfiguration step—changing the set of replicas, failure thresholds, or even swapping the consensus algorithm itself—is often an after‑thought. The paper “It’s not a lie if you don’t get caught: simplifying reconfiguration in SMR through dirty logs” introduces Gauss, a lightweight engine that decouples the consensus core from the log exposed to the application, making reconfiguration a plug‑and‑play operation with near‑zero downtime.

Key Contributions

• Modular Reconfiguration Layer – Gauss inserts a “dirty log” wrapper around any consensus protocol, exposing a sanitized outer log to the SMR node while keeping the inner log private to the protocol.
• Protocol‑agnostic Membership Changes – Enables upgrades of replica sets, failure thresholds, and even the consensus algorithm itself without halting the service.
• Minimal Downtime Guarantees – Demonstrates that reconfiguration can be performed with only a few milliseconds of service interruption, far less than traditional “stop‑the‑world” upgrades.
• Proof‑of‑Concept on Rialo Blockchain – Shows seamless migration across a sequence of heterogeneous consensus protocols (e.g., PBFT → HotStuff → Raft) in a production‑grade blockchain environment.
• Design Guidelines for SMR Engineers – Provides a clear separation‑of‑concerns blueprint that can be adopted in existing SMR stacks.

Methodology

1. Log Separation – The authors define two logical logs:

   • Inner Log: Managed exclusively by the consensus protocol; contains raw entries, possibly including “dirty” (unvalidated) data.
   • Outer Log: A filtered view presented to the state machine; only committed, clean entries are exposed.
     Gauss implements a thin translation layer that buffers inner‑log entries, validates them, and appends them to the outer log once they satisfy the current configuration’s safety rules.

2. Reconfiguration Protocol – When a membership change is requested, Gauss:

   • Takes a snapshot of the outer log.
   • Starts a new inner consensus instance with the updated replica set while continuing to serve reads/writes from the old outer log.
   • Once the new inner instance reaches a commit point, Gauss merges the two logs, discarding any conflicting dirty entries.

3. Evaluation Setup – The team integrated Gauss into the Rialo blockchain (a permissioned ledger) and performed a series of live upgrades:

   • Adding/removing nodes.
   • Switching from a Byzantine‑fault‑tolerant protocol (PBFT) to a crash‑fault‑tolerant one (Raft).
   • Adjusting quorum sizes.
     Metrics collected included latency spikes, throughput degradation, and the number of client‑visible errors during each transition.

Results & Findings

• Seamless Evolution – The outer log remained consistent throughout, and client applications observed no transaction loss or duplication.
• Protocol‑agnosticism – Gauss required only a small adapter per consensus algorithm; the rest of the SMR stack stayed untouched.
• Resource Overhead – The dirty‑log buffer added ~0.8 % CPU and 2 KB per replica of memory, negligible for typical production deployments.

Practical Implications

• Zero‑Downtime Upgrades – Cloud providers and fintech firms can roll out new consensus versions or scale replica sets without scheduling maintenance windows.
• Simplified Ops – Operators no longer need deep expertise in each consensus algorithm; they can treat them as interchangeable services behind a stable API.
• Future‑Proofing – As research yields faster or more secure consensus protocols, Gauss lets organizations adopt them instantly, protecting long‑term ROI on infrastructure.
• Multi‑Tenant Platforms – SaaS platforms that host many isolated SMR clusters can automate per‑tenant reconfiguration (e.g., adjusting quorum for high‑value customers) without risking cross‑tenant stability.

Limitations & Future Work

• Assumes Reliable Log Translation – The correctness of the outer log hinges on the adapter’s ability to correctly filter dirty entries; a buggy adapter could re‑introduce safety violations.
• Limited Fault Model Coverage – While the paper demonstrates both Byzantine and crash‑fault tolerant protocols, mixed‑mode environments (e.g., some nodes Byzantine, others crash‑only) were not explored.
• Scalability to Thousands of Nodes – Experiments capped at a few dozen replicas; the authors note that the snapshot‑merge step may become a bottleneck at larger scales.
• Future Directions include formal verification of the dirty‑log wrapper, extending Gauss to support hierarchical reconfiguration (e.g., geo‑distributed clusters), and integrating automated testing pipelines for adapter correctness.

Authors

• Allen Clement
• Natacha Crooks
• Neil Giridharan
• Alex Shamis

Paper Information

• arXiv ID: 2602.09441v1
• Categories: cs.DC
• Published: February 10, 2026
• PDF: Download PDF