Fork Sequential Consistency is Blocking

We consider an untrusted server storing shared data on behalf of clients. We show that no storage access protocol can on the one hand preserve sequential consistency and wait-freedom when the server is correct, and on the other hand always preserve fork sequential consistency.

💡 Research Summary

The paper investigates the feasibility of building a storage service on an untrusted server that simultaneously offers strong guarantees when the server behaves correctly and weaker “fork” guarantees when it misbehaves. The authors focus on single‑writer multi‑reader (SWMR) registers and consider three properties: sequential consistency, wait‑freedom, and fork‑sequential consistency. Sequential consistency requires that the overall order of operations can be rearranged into a sequential permutation that respects each client’s real‑time order and the register’s sequential specification. Wait‑freedom demands that every operation invoked by a correct client eventually completes, regardless of other clients’ actions or failures. Fork‑sequential consistency, a relaxation of fork‑linearizability, allows each client to have its own view of the history, but enforces a “no‑join” condition: if two clients share an operation in their views, the prefixes leading up to that operation must be identical in both views.

The authors formalize a “wait‑free fork‑sequentially‑consistent Byzantine emulation” as a protocol that (1) guarantees sequential consistency and wait‑freedom when the server is correct, and (2) guarantees fork‑sequential consistency in every execution, even when the server is Byzantine. Their main result, Theorem 1, proves that no such protocol exists for two or more clients.

The impossibility proof constructs three executions (α, β, γ) involving two clients C₁ and C₂ and two registers X₁ and X₂. In execution α, with a correct server, C₂ repeatedly writes distinct values to X₂ and reads X₁ while C₁ attempts to write a value u to X₁; messages from C₁ are deliberately delayed. Eventually C₂ reads u from X₁ (the first non‑⊥ read). Execution β follows α up to a point just before the last two write‑read pairs of C₂, after which C₂ stops; C₁ then repeatedly reads X₂ until it sees the value written by C₂ just before the stop. Because the server is correct, both executions satisfy sequential consistency and wait‑freedom.

Execution γ introduces a Byzantine server that presents a hybrid view: to C₁ it mimics β (hiding the later writes of C₂), while to C₂ it mimics α (showing all of C₂’s writes and the eventual read of u). Consequently, each client observes a history that appears consistent from its own perspective. However, the “no‑join” property of fork‑sequential consistency forces the prefixes preceding the shared write w₁ (C₁’s write to X₁) to be identical in both clients’ views. This requirement forces w_{z‑1}₂ and w_{z‑2}₂ (two of C₂’s writes) to appear before w₁ in C₁’s view, yet C₁ later reads a value v_{z‑2} from X₂ that was written by w_{z‑2}₂, contradicting the sequential specification of X₂ (which would require w_{z‑1}₂ to be observed before v_{z‑2}). This contradiction shows that γ cannot be fork‑sequentially consistent, violating the assumed protocol’s guarantee.

Thus, any protocol that is wait‑free and sequentially consistent with a correct server cannot also guarantee fork‑sequential consistency under Byzantine faults. This result extends the earlier impossibility for fork‑linearizability, demonstrating that even the weaker fork‑sequential consistency suffers the same fundamental limitation.

The paper concludes that designers of collaborative systems cannot rely on fork‑based consistency models to achieve both high availability (wait‑freedom) and security against a malicious server. To obtain usable systems, one must either relax the liveness requirement, introduce additional trust mechanisms (e.g., multiple servers, cryptographic verification, client‑to‑client checks), or accept stronger consistency models that inherently preclude wait‑freedom under Byzantine conditions. The work clarifies the trade‑off landscape for secure distributed storage and points to future research directions involving alternative trust assumptions or hybrid protocols.