Jetpack: Consensus Made Generally Fast (OSDI '26)

Aleksey and I are back to reading papers live. This paper, Jetpack(OSDI '26), attempts building a universal 1-RTT fast-path framework that bolts onto existing leader-based consensus protocols with minimal modification.

Why would we want this? Classic consensus protocols like Raft, Paxos, or Zab require two round-trip times (2 RTT) to commit a command: one RTT from client to leader, and another to replicate across followers. The extra RTT matters a lot for WAN deployments, so fast-path protocols (such as Fast Paxos, EPaxos, or SwiftPaxos) reduce this to 1 RTT by bypassing leader serialization, but unfortunately they tightly couple the fast path to the core protocol design. Production systems cannot easily swap out their battle-tested bespoke consensus engines, but if there was an add on that helped with latency especially in WAN deployments, that would be useful.

The good news is that Jetpack is truly an add-on portable deal. It provides a shim layer that runs two execution paths in parallel: a 1-RTT fast path and the original 2-RTT consensus path. When a client issues a command, it broadcasts the request concurrently to both paths. The fast path checks for key conflicts, and if none exist and a supermajority quorum ($\sim 3/4$ of nodes) issues a promise, this enables the command to fast-commit in 1 RTT. To guarantee agreement, original path proposers promise not to propose conflicting commands ahead of fast-committed ones.

The bad news is that this design gets wasteful due to keeping two distinct logs (the fast-path log and the original-path log). The original consensus engine runs its full replication cycle in the background, ignoring the fast path replication of commands (because it is completely oblivious to the fast path replication in the name of bolt-on portability). So these commands travel in the network twice, and replicas process commands twice, introducing redundant work and extra CPU/network overhead.

This dual-log architecture also creates a bigger gap between commitment and execution. Jetpack fast-commits in 1 RTT, but actual state-machine execution is driven strictly by the underlying original 2RTT path log ordering. Then, what good is a fast commit in practice? If you are running write-heavy, asynchronous pipelines or "fire-and-forget" ingestion where a client issues a PUT(key, val) and immediately moves on to the next task, a 1-RTT durable commit confirmation is a win. However, the fast path only gives you a fast commit, but it does not accelerate state-machine execution. The moment you run an interactive workload, say a client that issues a PUT(key, val) and immediately follows up with a GET(key) expecting read-your-own-writes or linearizability, the fast-path illusion breaks down. Jetpack's shim detects the unexecuted PUT sitting in its in-flight conflict pool and immediately demotes the GET right back to the slow 2-RTT original path to preserve correctness. So, yes, Jetpack stays linearizable, but you pay the full 2-RTT latency tax and wait for the original consensus engine to catch up to answer the GET.

This connects directly to the principle of nil-externality formalized in Exploiting Nil-Externality for Fast Replicated Storage (SOSP '21). Because write commands like PUT return no system state back to the client (they have "nil externality"), Jetpack can safely grant a 1-RTT fast commit before state-machine execution. But, the moment an operation (like a GET) needs to externalize state, that nil-externality optimization breaks down and forces the system to wait for full state-machine execution.

Despite this execution lag and redundant message overhead, the evaluation section shows gains for write-heavy pipelines (I think due to nil-eternality optimization) by benchmarking Jetpack across six consensus systems deployed on 10 AWS datacenters using YCSB workloads and Facebook's Akkio production traces. Because cross-datacenter write requests (such as remote shard updates in Akkio) primarily wait on durable commit confirmation before responding, Jetpack slashes client-observed end-to-end latency by up to 60%.

The paper's biggest safety contribution is to show how the fast-path protocols may break during leader elections. As I noted in my 2020 blog post review of CURP, mixing witness state with backup replicas makes view changes inherently risky. Jetpack proves this by uncovering a concrete bug in CURP’s Raft extension (used in production by Xline), where a lagging witness ACKs a fast-path command, only for a delayed cleanup message from a new leader to erase it, causing permanent data loss (or reordering) after a crash. This happens because promises made in stable views live in local replica states that a new leader never saw. Jetpack fixes this "view change hazard" with two strict principles: keeping fast-path views independent so ACKs cannot straddle terms (Principle 1), and forcing new leaders to write a "stability marker" that recovers all prior fast-committed commands before accepting new proposals (Principle 2).

As Aleksey and I experienced live during our reading session, untangling Jetpack’s three-phase recovery procedure was the trickiest part of the paper. We struggled to follow why recovery requires only a standard majority rather than a superquorum. But refreshing our understanding of Fast Paxos later showed that Jetpack's recovery mechanism is similar to that of Fast Paxos. Fast Paxos explicitly requires a supermajority quorum ($Q_2 \approx 3/4$ of nodes) for fast-path commits precisely so that leader election and recovery ($Q_1$) can run on a simple majority. Because any supermajority $Q_2$ is mathematically guaranteed to overlap with any standard majority $Q_1$ by at least one node, a newly elected leader polling a simple majority during recovery will always discover any fast-committed command. Still, the quorum math aside, I'll be damned if anyone can call fast-path recovery simple (and dependable).