Single round-trip optimization for Paxos with PaxosLease masters

Introduction In the previous article, Combining Paxos and PaxosLease, I combined the durable Paxos replicated log with PaxosLease-based master election. The result was a small master-based replicated state machine: Paxos still decided the log, but PaxosLease decided which node was currently allowed to drive the log. In that implementation, non-master nodes refused client writes, and clients had to discover and connect to the current master. That was a useful step, but it left one obvious inefficiency in place. Even though the system now had a master, every command still ran a full Paxos round: prepare -> propose -> learn The previous article ended exactly there: once you have a stable master, it is unnecessary for every new log slot to keep paying for both Paxos phases. The master is already the only node serving writes. In the steady state, for new Paxos rounds, we should be able to skip the prepare step and go directly to the propose step. This article makes that optimization, but…