1. Efficient Fork-Linearizable Access to Untrusted Shared Memory Presented by: Alex Shraer (Technion) IBM Zurich Research Laboratory Christian Cachin IBM Zurich Abhi Shelat University of Virginia Joint work with:

2. Data in a storage system Users store data on remote storage Data integrity: Single user – hashing Single user – hashing Merkle hash trees for large data volume Merkle hash trees for large data volume Multi user – digital signatures Multi user – digital signatures Public key infrastructure is needed Public key infrastructure is needed Data consistency? What if the server is faulty? What if the server is faulty?

3. ServerModel Asynchronous system Clients C 1,…, C n correct communicate only with the server via reliable links have public/private key pair (stored data is signed) each client executes read/write operations sequentially Server S emulates n SWMR registers - client C i writes only to register i CANNOT BE TRUSTED - perhaps faulty

4. Consistency Model? Attempt 1: linearizable shared memory Requires a read to return the latest written value Requires a read to return the latest written value Impossible Impossible  σ is linearizable if exists a sequential permutation  that preserves 1. the real-time order of σ and 2. the sequential specification

5. Attempt 2: Sequential consistency Read does not have to return latest value For every process, the order in which its operations take effect must be preserved Example: time C1:C1: C2:C2: write (1, v)write (1, u) read (1) → u read (1) → v

6. Sequential consistency – Cont. Still impossible to implement ! Proof: write (1, u) read (2) → ┴ write (2, v) read (1) → ┴ time C1:C1: C2:C2:

7. Previously defined: (1) [Mazières, Shasha PODC 2002] (2) [Oprea, Reiter DISC 2006] The definition we use - similar to (2): A seq. of events  is fork-linearizable if for each client C i there exists a subsequence  i of  consisting only of completed operations and a sequential permutation  i of  i 1.All operations of client C i are in  i 2.  i preserves real-time order of  i 3.  I satisfies the sequential specification 4.If an operation op is in  I and  k then the sequence of operations that precede op in both groups is the same Fork-Linearizability Every client sees linearizable memory R1 W1 R2 W2R3 C2C2 C3C3 C1C1 By telling one lie to C 1 & C 2 and another to C 3, the server “forks” their views C 1 & C 2

8. Fork Linearizable Byzantine emulation (simplified) - every execution is fork-linearizable - every execution is fork-linearizable - if the server is correct - if the server is correct every operation completes every execution is linearizable Global Fork-Linearizability: a simpler and equivalent definition New on Fork-Linearizability

9. Some Motivation Guarantees a linearizable view for each client, and linearizable executions when the server is correct The server can hide operations from clients, but nothing worse! The server can hide operations from clients, but nothing worse! If the server forks the views of C 1 and C 2, their views are forked ever after (no join), i.e., they do not see each other’s further updates If the server forks the views of C 1 and C 2, their views are forked ever after (no join), i.e., they do not see each other’s further updates otherwise the run is not fork-linearizable, which can be detected by the clients (unlike in linearizability or sequential consistency) otherwise the run is not fork-linearizable, which can be detected by the clients (unlike in linearizability or sequential consistency) fork-linearizability is not a weak condition Linearizability is stronger Linearizability is stronger (New) Sequential consistency is not ! (New) Sequential consistency is not ! proof – in previous slides Linearizable Fork Linearizable Seq. Consistent Fork-Linearizability is the strongest known consistency that can be enforced with a possibly faulty server

10. Emulating fork-linearizable memory requires waiting Theorem: Every protocol has executions with a correct server where C i must wait for C j Formal proof in the paper. The idea: by contradiction, assume that no waiting is necessary r’(1) must return v since w’(1, v) might have completed The server can cause this run to be indistinguishable from Run 1 v cannot be returned r’(1) cannot return neither u nor v in Run 1 – it must wait… w(1, u)w’(1, v) r(1) → ur’(1) → ? C1C1 C2C2 w(1, u)w’(1, v) r(1) → ur’(1) → v C1C1 C2C2 Run 1: Correct server Run 2: Faulty server

11. Protocols Trivial method: Sign the complete history Server sends history with all signatures Client verifies all operations and signatures Client adds its operation and signs new history Message size proportional to system age [Mazières, Shasha PODC 2002] : Use n “version vectors” A blocking protocol and a concurrent protocol Communication complexity Ω(n 2 ) Message size ~400MB for 10’000 users Our results: A blocking protocol and a concurrent protocol Communication complexity O(n) Message size ~40KB for 10’000 users

12. Lock-Step with Correct Server (simplified) C1C1 000000 000000 000000 100100 100100 100100 Correct Server 000000 100100 (val,1) 100100 110110 C2C2 110110 100100 100100 110110 100100 110110 000000 000000

13. Lock-Step with Faulty Server (simplified) 000000, (┴,0) 000000 010010 010010 100100 010010 000000 000000 000000 100100 100100 Faulty Server 000000 100100 100100 000000 000000 C1C1 C2C2 100100

14. What happened? Example 1Example 2 write 1 (1, val) start read 2 (1) → val write 1 (1, val) start read 2 (1) → ┴ 000000 100100 110110 000000 100100 010010 The ≥ relation: V ≥ V’ if for all j, V[j] ≥ V’[j] B reads stale data of A B signs a version structure which cannot be ordered with what A signed Proof idea – based on “No-Join” property: no operation signs a version structure V s.t. V ≥ V A and V ≥ V B  i Subsequences  i can be constructed from the branch of C i in the fork-tree

15. Increasing concurrency Any protocol will sometimes block… Concurrent protocol – details in the paper Allow operations to complete concurrently A read must wait for a previously scheduled concurrent write to the same register to complete (at most one such operation) Message size: O(n)

16. Summary of Results On the notion of Fork-Linearizability Global Fork-Linearizability Fork-Linearizable Byzantine emulations Comparing Fork-Linearizability with seq. consistency Communication efficient protocols Lock-Step Lock-Step Concurrent Concurrent A proof that any Fork-Linearizable Byzantine emulation must sometime block As in and in our concurrent protocols As in [MS02] and in our concurrent protocolsQuestions?