TL;DR
Chronon (chr2) is a Rust implementation of a deterministic, crash-safe replicated log and consensus engine that aims to ensure side effects execute exactly once. It combines Viewstamped Replication (VSR) with a durable outbox, a fenced primary executor, and a separation of control and data planes, and is under active development with built-in chaos tests.
What happened
A new open-source project, Chronon (repo: abokhalill/chr2), presents a Rust-built replicated log and consensus stack focused on making side effects deterministic and crash-safe. The system pairs a VSR-based consensus layer with a durable outbox pattern so applications record side-effect intents in replicated state; a fenced primary executes them and an AcknowledgeEffect event is committed after execution. Chronon splits the control plane (heartbeats, elections, view changes) from the data plane (log writes and durability) to avoid disk I/O blocking leader liveness and to limit tail latency effects on cluster availability. The repository includes a storage engine with O_DSYNC log writes, optional io_uring support, lock-free readers, a single-threaded deterministic executor, and tools for chaos testing (network partitions, node kills, linearizability checkers). The project exposes an application trait for integrating state machines and provides a crash-test demo and build/test commands in its README.
Why it matters
- Addresses the hard problem of side effects in distributed systems by persisting intents and using a fenced primary to avoid duplicate executions.
- Separating control and data planes reduces the risk that disk stalls will trigger unnecessary leader elections or cluster instability.
- Explicit durability choices (O_DSYNC/fdatasync, hash chains) make corruption detectible and emphasize predictable persistence behavior.
- Deterministic single-threaded execution and replicated logs simplify reasoning about replica state convergence after recovery or failover.
Key facts
- Chronon claims durability: committed entries survive any single-node failure.
- Consistency: linearizable reads and writes are provided via quorum consensus.
- Exactly-once side effects: achieved by storing effect intents in a replicated outbox and acknowledging effects after execution.
- Architecture separates a VSR consensus layer, a Kernel/Executor, and application code via a ChrApplication trait.
- Storage engine features include an append-only LogWriter using O_DSYNC and an optional io_uring backend with O_DIRECT and DMA buffer pools.
- Consensus components include VsrNode, QuorumTracker, SessionMap, and manifest-based durable fencing to prevent zombie leaders.
- Kernel components include a single-threaded Executor, SideEffectManager, snapshots for compaction, and a DurabilityWorker for async durability.
- Chaos testing utilities (ChaosNetwork, Nemesis, Checker) are included for fault injection and linearizability verification.
- Design principles emphasize crash-only behavior, hash-chain integrity checks, explicit durability, and broad use of fencing.
What to watch next
- Whether Chronon moves from active development to a production-ready release with usage guidance and real-world benchmarks (not confirmed in the source).
- Broader ecosystem adoption and integration examples beyond the provided bank-style application trait (not confirmed in the source).
- Performance and operational characteristics of the optional io_uring backend in varied workloads (not confirmed in the source).
Quick glossary
- Viewstamped Replication (VSR): A consensus protocol family that coordinates a primary (leader) and backups to replicate a sequence of operations with view changes for leader replacement.
- Durable outbox: A pattern where an application records intended external side effects in durable local state so actual effect execution can be retried or coordinated safely.
- Linearizability: A consistency model where operations appear to occur atomically and in an order that respects real-time ordering.
- fdatasync / O_DSYNC: Filesystem calls or flags ensuring that data reaches durable storage before returning, used to make writes explicitly persistent.
- Fencing: Mechanisms (tokens, view numbers, manifests) that prevent a previously-leader process from acting as if it still holds leadership after a failover.
Reader FAQ
Does Chronon guarantee exactly-once side effects?
According to the repository, Chronon achieves exactly-once semantics by persisting effect intents in a replicated outbox, executing effects only on a fenced primary, and committing an acknowledgement after execution.
Is Chronon production-ready?
Not confirmed in the source. The README states the project is under active development and that core consensus and durability layers are functional with comprehensive test coverage.
Does Chronon support modern Linux async I/O?
Yes—an optional io_uring backend is provided and can be enabled via a feature flag; the README notes io_uring support requires Linux 5.1+.
How do I run the crash tests?
The repository includes a crash test harness with cargo run –release and several subcommands for clean, write, recover, and full test phases, per the README.
Chronon A deterministic, crash-safe distributed state machine with exactly-once side effects. Chronon is a Rust implementation of a replicated log and consensus engine designed for systems that cannot afford to…
Sources
Related posts
- Using FUSE to Give Agents Broad, Sandboxable Access via Filesystems
- iCloud Photos Downloader: Open-source CLI for exporting iCloud photos
- Hackers Report January 2026 Projects: Bitemporal DB and RISC‑V OS Work