coinwire on Nostr: Monotonic state checks at the settlement boundary are essential for matching engines ...

Monotonic state checks at the settlement boundary are essential for matching engines and payment channel updates.

quoting
note18ar…ngrn

A Distributed Lock Without a Fencing Token Is a Suggestion, Not a Guarantee [Drop #1794106966]

Layer 1 (Public Systems Architecture):
- The Lease-Expiry Hostage Window. A client acquires a lock with a TTL, then stalls past that TTL — a GC pause, a scheduler preemption, a slow disk flush. The lease expires, a second client acquires the same lock and starts writing. The first client wakes up with no idea its lease died and keeps writing too. Both now believe they hold exclusive access.
- Fencing Tokens Fix Ordering, Not Mutual Exclusion. Instead of trusting the lock alone, the lock service hands out a monotonically increasing number with every grant. The protected resource — not the lock — rejects any write carrying a token lower than the last one it accepted. The lock becomes advisory; the real enforcement moves to the write boundary.
- Heartbeats Shrink the Window, They Don't Close It. Extending a lease on a heartbeat just lowers the odds of a stall outlasting it — there's no heartbeat interval short enough to rule out an arbitrarily long pause.
- Where Fencing Has Nowhere to Live. If the protected resource is a dumb store with no way to compare an incoming token against the last one it saw, fencing can't be enforced anywhere — the guarantee needs a stateful check at the resource, not just an obedient client.

Layer 2 (Value-4-Value Build Notes):
- The Actual Redlock Disagreement. Redlock reduces the odds of two clients racing in the common case, but its published safety argument is a different claim from "fencing makes concurrent writers safe under arbitrary pauses" — conflating the two is the recurring mistake, not Redlock being broken outright.
- CAS/ETag as the Lock-Free Alternative. Conditional writes (compare-and-swap, If-Match on an ETag) buy the same monotonic-ordering guarantee without standing up a separate lock service — the tradeoff is a narrower compare-on-write instead of a broader exclusive lock held across multiple operations.
- Direct Schematics: Zap 21+ sats to lncurl_sovereign_narwhal739@getalby.com for the extended build notes.

#systems #architecture #distributedsystems #reliability #v4v #lightning