Distributed Causal Memory: Modular Specification and Verification in Higher-Order Distributed Separation Logic - Coq Formalization

This is the documentation of the Coq formalization for the paper "Distributed Causal Memory: Modular Specification and Verification in Higher-Order Distributed Separation Logic", submitted to POPL'21.

Setup Instructions

There are two ways to build the development: using the provided Dockerfile (recommended), or manually.

Docker Setup

1. Install Docker

2. In order to build the development, you might have to increase the amount of memory allocated to a running Docker container. We suggest 4GB. For instructions, see here.

3. Build the Docker image (include the . at the end): docker build --pull -t ccddb .

4. Run the built Docker container: docker run -i -t ccddb

5. From within the container, build the development: make -jN , where N is the number of CPU cores in the Docker VM.

Manual Setup

1. Install opam

2. To install the dependencies, you have to add the following opam repositories:

   • opam repo add coq-released https://coq.inria.fr/opam/released
   • opam repo add iris-dev https://gitlab.mpi-sws.org/iris/opam.git

3. opam update

4. make build-dep

5. Run make -jN to build the full development, where N is the number of your CPU cores.

The concrete version of Iris and std++ libraries relied upon are specified in the opam file.

Theory of Aneris

Our formalization is built on top of the Aneris framework, which consists of a programming language for writing distributed programs, as well as bespoke logic to reason about the same.

• AnerisLang and its operational semantics are defined in aneris_lang/lang.v.
• All Iris resources for reasoning about the heap, sockets, messages, etc. are defined in aneris_lang/resources.v.
• All proof rules for the Aneris program logic are defined in aneris_lang/lifting.v.
• The adequacy theorem is stated and proved in aneris_lang/program_logic/aneris_adequacy.v.

Causally Consistent Distributed Database

• The AnerisLang implementation is found in CCDDB/code.v.
• The abstract specification of the CCDDB is found in CCDDB/spec/init.v.
• The abstract model is found in CCDDB/model/model_spec.v.
• The Iris resource definitions are found in CCDDB/resources/resources_gmem.v, CCDDB/resources/resources_lhst.v, CCDDB/resources/resources_local_inv.v, and CCDDB/resources/resources_global_inv.v.
• The proof that the implementation meets the abstract specification is found in CCDDB/proof/proof_of_read.v, CCDDB/proof/proof_of_write.v,proof_of_apply.v, CCDDB/proof/proof_of_network.v, and proof_of_init.v.
• The example of direct causal dependency is found in CCDDB/examples/message_passing/prog.v, CCDDB/examples/message_passing/proof_resources.v, CCDDB/examples/message_passing/proof_of_node0.v, CCDDB/examples/message_passing/proof_node1.v, CCDDB/examples/message_passing/proof_of_main.v, and CCDDB/examples/message_passing/proof_adequacy.v.
• The example of indirect causal dependency is found in CCDDB/examples/message_passing/message_passing_transitive.v
• The session manager implementation is given in CCDDB/examples/session_guarantees/sm_code.v and the proof in CCDDB/examples/session_guarantees/sm_proof.v.
• The session guarantees are shown in CCDDB/examples/session_guarantees/ryw.v, CCDDB/examples/session_guarantees/mr.v, CCDDB/examples/session_guarantees/mw.v, and CCDDB/examples/session_guarantees/wfr.v.

Mapping

The following list maps concepts, definitions, and results from the paper to the Coq development.

• The implementation of the distributed database from Fig. 2 is available in CCDDB/code.v; the init function as ccddb_init, the read function as store_read, the write function as store_write, the receive_thread function as recv_thread, the send_thread function as send_thread, the apply function as store_apply, and the check function as store_test.
• In Fig. 5,
  • Seen is defined as the abstract predicate Seen.
  • Snap is defined as the abstract predicate OwnMemSnapshot.
  • The harpoon notation 𝑘 ⇀𝑢 h is defined as the abstract predicate OwnMemUser.
• In Fig. 6, all the properties are stated in the DB_resources type class:
  • Snap union as OwnMemSnapshot_union,
  • Take Snap as User_Snapshot,
  • Snap inclusion as OwnMemSnapshot_included,
  • Snap extensionality as Snapshot_ext,
  • Seen union as Seen_union,
  • Seen global extensionality as Seen_ext,
  • Seen local extensionality as Seen_strong_sext,
  • Seen provenance as Seen_provenance,
  • Causality as Causality.
  The instance of the DB_resources type class derived from our implementation and verification is given as db_resources.
• In Fig 7., the specification for the read function is given as read_spec; the specification is proved in internal_read_spec. The specification for the write function is simplified and the actual specification is in HOCAP-style (c.f. Sect. 7). This specification is given as write_spec; the specification is proved in internal_write_spec
• In Fig 8., the specification for the init function is given as init_spec; the specification is proved in internal_init_spec_holds.
• In Sect. 4.4, the InitSetup rule is given as DB_init_setup; the specification is proved in init_setup.
• In Sect. 4.5, the implementation is found in CCDDB/examples/message_passing/prog.v and the invariants in CCDDB/examples/message_passing/proof_resources.v. The proof of node i is given as z0_spec and the proof of node j is given as z1_spec
• Section 5: Towards Session Guarantees for Client-Centric Consistency
  • The session manager implementation is sm_setup.
  • The proof that the session manager meets its spec is sm_setup_spec.
  • SM-init (in appendix C.2) is init_spec.
  • SM-read (in appendix C.2) is read_spec.
  • SM-write (in appendix C.2) is write_spec.
  • The server code is server.
  • The proof that the server meets its spec is server_spec.
  • SM-read-your-writes (in appendix C.3) is ryw_example_spec.
  • SM-monotonic-reads (in appendix C.3) is mr_example_spec.
  • SM-monotonic-writes (in Figure 13 and appendix C.3) is mw_example_spec.
  • SM-writes-follow-reads (in appendix C.3) is wfr_example_spec.
• Definition 6.1 is found as the combination of the two records DBM_lhst_valid and DBM_lsec_valid. The four properties are found as DBM_LHV_ext, DBM_LSV_comp, DBM_LSV_caus_refl, and DBM_LSV_caus, respectively. The remaining conditions in the two records constitute the well-formedness requirements mentioned in the footnote.
• In Theorem 6.2, the four properties are found as DBM_lsec_empty, DBM_lsec_causality_lemma, DBM_LSV_ext, and DBM_LSV_strongly_complete, respectively.
• Definition 6.3 corresponds to DBM_Lst_valid; the four properties are found as DBM_LSTV_vals_Some, DBM_LSTV_vals_None, DBM_LSTV_time, and DBM_LSTV_hst_valid, respectively.
• Definition 6.4 corresponds to DBM_Gst_valid.
• Theorem 6.5 corresponds to DBM_system_write_update_gst and DBM_system_apply_update_gst.
• In Fig. 15,
  • Snap corresponds to own_mem_snapshot.
  • The harpoon notation 𝑘 ⇀𝑢 h corresponds to own_mem_user.
  • GM(M) predicate corresponds loosely to own_mem_sys.
  • Seen corresponds to local_history_seen.
  • LHG(i, s) corresponds to local_history_Global_inv.
  • LHL(i, s) corresponds to local_history_Local_inv.
• In Fig. 16,
  • Snapshot inclusion is found as snapshot_lookup.
  • Seen inclusion is found as seen_lookup.
  • Local history agreement is found as global_local_history_agree.
  • Global memory update corresponds loosely to create_own_mem_sys_update.
  • Local history update is found as local_history_update.
• GlobalInv found at the end of Sect. 6.2 is found as Global_Inv.
• The lock invariant found in Sect. 6.3 is found as local_inv_def.

Verifying the Formalization

You can verify the development by

• Building it and checking that there are no compilation errors.

• Grepping for Admitted and admit: e.g. git grep Admitted

• n.b. both vim and emacs are installed in the container, but neither Proof General nor CoqIDE are installed.

Used Libraries

Our development relies on the following libraries:

• Amin Timany's monotone resource algebra.

• Tej Chajed's record update library.