Feature: Implement LeaseGuard leader lease protocol

[hadronzoo]

Add leader leases based on the LeaseGuard protocol (Davis et al., SIGMOD'26). This enables linearizable local reads without per-read network round trips by exploiting Raft's Leader Completeness guarantee.

Why

The current option for linearizable reads is expensive: the leader contacts a majority before each read, adding one RTT of latency to every read operation.

Leader leases allow the leader to serve reads locally while holding a valid lease. Prior lease protocols for Raft are poorly specified, entangle leases with elections, delay failover recovery, and have been buggy across implementations (etcd, HashiCorp Raft, Consul).

LeaseGuard solves these problems:

1. The log is the lease: Committing a log entry grants the leader a lease. No separate lease-extension messages. This also solves the "faux leader" problem where a leader with disk failure keeps renewing its lease but can't make progress.

2. Decoupled from elections: No changes to voting. A node bound by a lease can still become leader with a higher term.

3. Formally specified: TLA+ spec available and model-checked for Read Your Writes and other correctness properties.

4. Fast failover via two optimizations:

   • Deferred-commit writes: New leader accepts and replicates writes immediately, defers marking them committed until old lease expires. Prevents thundering herd.
   • Inherited lease reads: New leader identifies "limbo region" (entries that might not be committed) and serves reads immediately for keys unaffected by limbo entries. Requires synchronized clocks with known error bounds.

Changes

• Add lease_duration configuration option
• Track last_commit_time on leader (updated when entry commits)
• Add lease validity check before serving local reads
• On leader transition: infer prior leader's lease expiry from log, implement deferred-commit and inherited-lease-read logic
• Optional: require bounded clock error for inherited lease reads optimization

References

• Paper: https://arxiv.org/abs/2512.15659
• TLA+ spec: https://github.com/muratdem/RaftLeaderLeases/blob/main/TLA/leaseGuard.tla
• LogCabin implementation: https://github.com/mongodb-labs/logcabin/tree/leaseguard
• Python simulator: https://github.com/muratdem/RaftLeaderLeases/tree/main/Python

[github-actions]

👋 Thanks for opening this issue!

Get help or engage by:

• /help : to print help messages.
• /assignme : to assign this issue to you.

[ariesdevil]

It seems we've implemented lease read. Could you outline the current implementation's shortcomings?

[hadronzoo]

My mistake! I missed that entirely.

[drmingdrmer]

Thanks for this well-researched proposal with the academic paper and TLA+ specification.

The LeaseGuard approach is interesting, but it differs from the lease-based read linearization already implemented in openraft. Our current mechanism uses heartbeat quorum acknowledgment time to determine lease validity, while LeaseGuard bases leases on log commit time.

There's overlap between these two approaches, and allowing them to coexist in one framework presents some design challenges. I need time to think through how to unify or cleanly separate them.

Regarding the performance claims: the paper highlights reduced read unavailability during leader transitions (the "deferred-commit" and "inherited-lease" optimizations). However, I'm skeptical this provides significant benefit in heavily loaded systems. When load is high, log entries are being committed continuously, which means the commit-based lease is constantly being refreshed. In that scenario, the time window where a new leader lacks a valid lease should be similarly short to our current heartbeat-based approach.

The benefit seems most pronounced in low-load scenarios where commits are infrequent—but those are also scenarios where the occasional read latency spike during leader transition matters less.

I'd be curious to hear your thoughts on this, and whether you've observed the performance characteristics in practice.

Reopening this issue—it suggests an interesting approach and potentially a valuable improvement worth exploring further.