Invariant Safety for Distributed Applications 1 Sreeja Nair1, Gustavo Petri2, Marc Shapiro1 1 LIP6, Sorbonne University & Inria 2 ARM Research Cambridge The 6th Workshop on Principles and Practice of Consistency for Distributed Data PaPoC’19 25-03-2019 

Distributed Applications • Modern day applications serve users in different geographical regions • Applications are replicated closer to users due to demands of low response time • CAP theorem depicts a tension between Consistency and Availability 2 

Replicated Online Auction 3 Alice Bob Charles 

Invariant Safety for Distributed Applications • Ideal world for developers = high availability + application safety • A modular proof rule to ensure this! • Reason about one operation at a time 4 

Auction application • State • Status • INVALID or ACTIVE or CLOSED • Winner • Set of bids, each bid comprising • BidId • Placed • Amount 5 • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Operations • Start auction • Place bid • Close auction 

Evolution of state 6 Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid Status Winner Bids Merge! ??? 100 105 1 100 105 100 1 Close auction 100 1 100 105 

Safety in sequential executions 7 Start auction Close auction Place Bid 100 Start auction Close auction Place Bid 100 100 105 100 105 100 105 100 105 100 105 105 100 

Safety in sequential executions 8 Close auction 100 100 105 Close auction 100 100 95 100 95 100 105 

Safety in sequential executions • Each operation and merge must satisfy the invariant • Ensured by preconditions 9 

Precondition for merge? • It must hold true since merge can happen at any time • Can be also called Concurrent Invariant • The weakest precondition to be upheld for the resulting state of merge to uphold the sequential invariant • Ensures all concurrent operations are still safe • Never block any merge!! 10 Invglobal = Invapp ∧ Invconcurrent 

Concurrency • A state in a replica evolves with • A local update by operation • Merge • Merge is the only point of observable concurrency 11 Alice/ Bob/ Charles Start Place Place 100 105 1 100 105 100 1 

Proof Rule for safety of distributed applications • Initial state must satisfy the application invariant and concurrent invariant • Each update and merge should preserve both the application invariant and concurrent invariant 12 

Proof Rule for safety of distributed applications • Intuition • Merge is the only point of external influence • Merge can happen any time • Modular • Each operation and merge reasoned in isolation 13 

Revisiting auction • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Concurrent Invariant • Winner in either state is the highest bid in both states 14 

Safety of Auction 15 Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid 100 105 1 100 105 100 1 Close auction 100 1 100 105 

Safety of Auction • Start auction 16 • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Concurrent Invariant • Winner in either state is the highest bid in both states • Place bid • If auction concurrently closed in other replica, precondition of merge violated! • Close auction • Similar to place bid 

Concurrency Control • Option 1: • Strong consistency of place bid and close auction operations • Issue: each place bid need synchronisation • Option 2: • Concurrency control similar to readers-writer lock • Place bids work without synchronisation • Closing auction needs synchronisation 17 

18 Evolution of state with Concurrency Control Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid Close auction 100 Release token 100 105 Release token 105 Release token 1 1 100 105 105 100 

Tool Support - Soteria • Implemented on top of Boogie • Input • Application state • Invariant • Partial Order function • Operations with preconditions • Merge operation with precondition 19 

Soteria checks • Sanity checks • Convergence checks • Each operation is monotonically non-decreasing • Merge is the least upper bound • Safety checks • Sequential safety -> each operation preserves the invariant • Concurrent safety -> each operation preserves the precondition of merge 20 

Semi-lattice • Set of state should form a monotonic semi-lattice • Equipped with a partial order function • Each update should inflate the state • Merge should be the Least Upper Bound 21 100 105 100 105 

Conclusion • A new proof rule for verification of distributed applications • For applications using state-based update propagation • A tool for design verification • Available at https://github.com/sreeja/soteria_tool 22